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:
Order.xsd
OrderMessages.xsd
OrderService.wsdl
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 now.
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..
/Henrik
----- 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!
Tony
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 1. 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. 2. 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. 3. 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... Regards Henrik
|