OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XML Envelopes...

[ Lists Home | Date Index | Thread Index ]

Why can't you just use SOAP for the generic Envelope / header structure and consider something along the lines of the ebXML messaging standard for the payload (i.e. the payload of the first part of a multi-part message contains a manifest which points to each of the business payloads in other parts) ?
 
Fraser.

 
On 21/07/06, Minas Casiou <casi1min@police.nsw.gov.au> wrote:

Got a bit of a tough one (for me anyway...).

Got an XSD Envelope that we wish to use for all messages. It's generic.
At the body node though, we wish to specialise that node & add the specific schemas for that particular service.

Now, there's a couple of ways to do this:
Option 1) The way I've done it in the past (ESB.NET) - pure but not very friendly/descriptive.
==>Define the actual details of the payload in a service definition only, not as part of the envelope.
This makes it easy for the framework in a way, but makes it a bit of a pain to develop with as you effectively have no document schema (only the envelope schema). The envelope manifest then tells you what's in the body & you take it from there. Note very WSDL tools friendly!
One advantage is that the schemas are completely Envelope Agnostic.

Option 2) Somehow come up with a new schema for each service, that's a specialization of the Envelope
This option involves either the schemas having knowledge of the envelope (which is very limited - eg. a particular request can have many different schema documents included), or the creation of a specialization of the Envelope which contains the details of all the documents possible for that request. For example, the WfXml can be viewed as such a specialization, where the specialization of the body node is an enumeration of the possible schemas available for WfXml. This is an effective way of reducing the number of specialized schemas.
Note, however, that it's a WfXml specific Envelope Schema, and we need a generic Envelope Schema that can be used for building any service.

With Option 2 then...I have a bit of a problem...
If I've got: ( Generic Envelope...)
<nsEnv::ESBEnvelope>
        <nsEnv:header>...blah...complex type in here...</nsEnv:header>
        <nsEnv:body>
                <!-- documentBody is an xsd:any ...-->
                < nsEnv:documentBody></nsEnv:documentBody>
                <nsEnv:documentBody></nsEnv:documentBody>
                <nsEnv:documentBody></nsEnv:documentBody>
                ...
        </ nsEnv:body>

</nsEnv:ESBEnvelope>

documentBody above is defined like this:
        <xsd:element name=" documentBody">
                <xsd:complexType >
                        <xsd:sequence>
                                <xsd:any namespace="##any " processContents="skip"/>
                        </xsd:sequence>
                </ xsd:complexType>
        </xsd:element>

Ideally, I wanted an Envelope Specialization...for Spec1...
<nsEnv::ESBEnvelope>
        <nsEnv:header>...blah...complex type in here...</nsEnv:header>
        <nsEnv:body>
                <!-- documentBody is an xsd:any ...-->
                <nsEnv:documentBody>
                        <nsEnvSpec1:SomeSpecializedBody>        (with a bunch of stuff under here...)
                        </nsEnvSpec1: SomeSpecializedBody>        
                </nsEnv:documentBody>


                < nsEnv:documentBody></nsEnv:documentBody>
                <nsEnv:documentBody></nsEnv:documentBody>
                ...
        </nsEnv:body>

</nsEnv:ESBEnvelope>


How exactly do you do this?
Inheritance (derived by extension or restriction) falls short (unless I stuffed it...) in that I need to not only specialize documentBody , but also ESBEnvelope and body which has the ugly side-effect of duplication, and worse, a new namespace for the node!

Remember that you can have multiple documents in the Body, from completely unrelated Schemas. As such, the coupling of Envelope and Document needs to be done on a "Per Service" Basis or something, not on a "Per Schema" basis.

Other options?


Thanks

 
Cheers
 
Minas Casiou |  ESB Technical Architect I&I | MRP -  Mainframe Replacement Program    |  BTS  |   New  South  Wales  Police
Phone: 02 9689 7610 |  Eaglenet: 79610  |  Mobile: 0431 103 925  |   email: casi1min@police.nsw.gov.au
This message and any attachment is confidential and may
be privileged or otherwise protected from disclosure. If you
have received it by mistake, please let us know by reply
and then delete it from your system; you should not copy
the message or disclose its contents to anyone.








 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS