axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HG" <>
Subject Re: Best Practice
Date Tue, 16 Nov 2004 14:06:16 GMT
Hi again Anne.

Nope. No need for these WSDL imports..I was mixing things up...posts are done on a pure "brain
dump" basis..

  ----- Original Message ----- 
  From: Anne Thomas Manes 
  Sent: Tuesday, November 16, 2004 2:58 PM
  Subject: RE: Best Practice

  I was a little confused by your import structure - I wouldn't expect to use <wsdl:import>
at all. My suggestion is as follows:


  Define standalone element schema (what you call type-schema).


  Define standalone input/output message schema (what you call message-schema).

    <xsd:import> the element schema.


  Define standalone fault message schema.

    <xsd:import> the element schema.


  Define a schema within the WSDL types section.

    <xsd:import> the input/output message schema.

    <xsd:import> the fault message schema.


  (You don't need to import the element schema because your WSDL document doesn't reference
anything within the element schema directly.)


  Alternatively, you can do it this way:


  Define standalone element schema (what you call type-schema).


  Define standalone fault message schema.

    <xsd:import> the element schema.


  Define a schema within the WSDL types section.

    <xsd:import> the element schema.

    <xsd:import> the fault message schema.

    Define input/output message elements. 







  From: HG [] 
  Sent: Tuesday, November 16, 2004 8:10 AM
  Subject: Re: Best Practice


  Alright..I'll keep going :-)


  You nearly answered your question yourself.


  The different between 1) and 2) is that it is defined in two separate schemas (files).

  That way SOAPscope doesn't "throw up" (guess not, haven't tried it), because your are importing
from a schema to a schema


  You have this structure:


  message-schema->type-schema (message-schema refers to type-schema, aka schema import)

  wsdl->message-schema (wsdl refers to message-schema, aka WSDL import)


  These might be your files:





  One reason to create a separate Order.xsd could be to apply "type-reuse" between messages.


  VS.NET 2005 will support this kind of import. It is a confirmed bug, that it doesn't right

  It is a matter of not generating the Order class (from Order.xsd) again if it is already
there and to maintain namespace compatibility (eg. generate to the same namspace each time)


  Hope it helps and clears things up..







  ----- Original Message ----- 



    Sent: Tuesday, November 16, 2004 1:45 PM

    Subject: Re: Best Practice


    Thanks, Henrik. 

    That's the sort of thing I'm after. 

    I couldn't quite work out the difference between 1 and 2, though. In 1, you are defining
the messages for the service methods and this naturally includes the parameters of the methods.
In 2, it seems you're doing the same thing again (except for the message elements themselves).

    When importing, are you referring to WSDL imports or XML schema imports? We have some
services that define a schema in the <types> element and import another schema, in the
<types> element also. The latest SOAPscope doesn't like this, unless the imported schema
is imported within the schema which references its types. Just thought I'd mention it (XMLSpy,
doesn't mind). 

    Keep it coming! 


    Hi Tony 
    I have a few...Some on this list might disagree, but it is always nice with a discussion.

    I have done this, on several projects, and it works very well, especially for interop.

    The main point is: Use Schemas 
    Define a schema for each message you want your webservice to process. 
    Lets call these schemas for message-schemas. 
    1 a) 
    Typically a "call" to a webservice consists of some input message and maybe some output
message. Define a schema for both. 
    1 b) 
    When you define the schema for the messages, the "value objects" will logically appear
to you. Value objects in this context is types (defined in schemas) for parameters you pass
in the message and return values of the message. 
    Outcome of 1: 
    You have a schema for each webservice that exactly defines request/response messages for
each web service method. 
    As pointed out in 1 b) schemas for the parameter/return types can/must also be defined.
This might be an Order type, Customer type, etc. 
    Lets call these schemas for type-schemas. 
    2 a) 
    Define these parameter/return types in a schema, too. 
    Outcome of 2: 
    You have a schema (or all in one schema) for each parameter/return type that each webservice
method must be able to process. 
    Over time you'll have a "domain model" of types/classes described in schemas. 
    Use imports between schemas (both type-schemas and message-schemas) to construct your
WSDL document. 
    a) Import type-schemas in your message-schemas as needed by parameter/return types. 
    b) Import message-schemas in your WSDL document as needed. 
    Outcome of all three: 
    - You have a clean separation and description (in terms of schemas) of the services a
webservice provides and the "types of data" these service operates on. 
    - Your WSDL doesn't get cluttered with types 
    Anyone... comments on these steps are welcome... 

View raw message