Hi Fraser,
You’re exactly right. Some things in
my envelope cross over to transport, however they’re at a level that a
Business Person would also understand.
There’s a manifest, which contains
details about the message at a relatively simplistic & high level.
Remember that it’s also used outside
of solutions that use SOAP. Eg. Plain old FTP-aware systems that don’t
support SOAP. Sure, SOAP is transport agnostic, but the other end MUST be able
to process a SOAP message to process it. Much older systems cannot do this –
although the numbers are decreasing, you’d still need to do some work to
get a SOAP compliant system in some areas.
Coupled with SOAP versioning and associate
logistical problems, of keeping stuff stable over a long period of time (say 5
years or more) whilst SOAP envelopes & parsers etc. change to meet other
requirements & compatibility issues, none of which are related to the
business domain it is I’m working with, relying on SOAP to do this is not
a good strategy. It’s sort of like saying I’ll use SOAP to Walk,
when SOAP is more targeted at doing the work of Aeroplanes, Trains, Cars etc. My
Envelope sort of does the final few steps, which are best done by foot.
Here’s maybe a sort of example/comparison
(lost for words now…just need to get out of here & get to work…J )
Eg. Move a parcel from US to Australia…
- (My Envelope)
Person constructs a message containing Business Level Data and then Packages
it up & puts a meaningful address to him/herself on it…
- (SOAP
equivalent)Courier picks it up & may make more specific requirements
of the address, add a return address in case it can’t be delivered, with
Insurance etc…
- (SOAP
equivalent, inc. transport level details) Plane ships it to Australia…with
associated routing info
- (SOAP
equivalent, inc. transport level details) Gets received in Australia
put in a Van/courier to move it to a closer place to it’s ultimate
home (which is logically some place in a Business Person’t mind…)
who ships it to a particular address
- (My
Envelope) Business Person opens up the Package and looks at the Contents of
the message (Manifest etc.) at a level that’s sensible &
directly meaningful to the business. They then proceed to process it.
Note the emphasis on the Business Person. They’re
the only thing that matters to this message.
There’s address info in both SOAP
(as well as lower level representations… MacAddress etc.) but they’re
not very meaningful to the Business Person. Sometimes though, it gets a little
grey. At that point, always put the Business Perspective forward, and handle
the grungy stuff at the lower (Technical) layers. Important thing is that
Business View is not obscured, as that’s the ultimate purpose of the
software being built – the business.
In this case, having Business People’s
data mixed in with SOAP tags & treated as extensions of SOAP doesn’t
work too well. Things aren’t separated very well. That’s my view.
Having thought it through yourself, you
can see it’s not something to be taken too lightly. I’m glad this
user base is growing. Just came across someone in another small co. the other
day with the similar dilemma & solution. Key thing to note is that
development tools aren’t addressing this area at the moment, which is a
little unfortunate.
I view it as something WS-BPEL should look
at doing. It should be split into 2 layers. Abstract the WSDL & SOAP stuff
away at the bottom level, and do something more high level like this when
associating to the Business Process being built. I’m not holding my
breath though…
Here’s my Envelope schema (attached).
Also, see how it correlates to the service
definition at:
http://www.esb.net.au/MINAsBlog/tabid/59/EntryID/7/Default.aspx
(contains description of important fields
etc.).
As you mention, there’ll be
duplicated effort, but the essence of it is to separate away the Business View…and
somehow get the technical stuff done from this info.
It’s both simple
& complex depending upon your viewpoint…
From: Fraser Goffin
[mailto:goffinf@googlemail.com]
Sent: Monday, 24 July 2006 1:00 AM
To: Minas Casiou
Subject: Re: [xml-dev] XML
Envelopes...
thats quite interesting. Recently we've also been having some internal
discussions about where meta-data related to the business payload could/should
be located. On the one hand one might argue that if the data is concerned with
the business process then it should be in the payload part of the message. We
also recognise though that sometimes the same data is required BOTH for
business processing and for [say] message delivery. For example, many of our
messages contain an agent reference. This is used for determining business
terms at the process level but also may be used to route the message ( i.e. it
could be used as a QoS signal). In these cases it seems legitimate for it to be
in both areas.
Incidentally I don't view SOAP as merely a transport layer, and SOAP
headers are designed to contain meta -data for a number of purposes routing and
delivery are just two, but business intent/semantics may also be there. SOAP
headers also aren't the sole preserve of WS-* although these do provide some
useful (and largely interoperable) standards. And MTOM / SwA are just packaging
protocols. ebXML MS is different though in the sense that its vocabulary
allows for multi-part messages to be described by a manifest (I wasn't
especially referring to its capabilities for reliable messaging) which I
thought was part of your original post problem space.
Anyway, it was perhaps the use of the term 'envelope' which threw me
slightly from your original post. Tell me then, since the structure of your
'business' envelope is similar to SOAPs and pretty much any message model
that describes a 'container' which includes a place for meta-data and a place
for business payload, are you using your header and body sections in this way
? What sort of data exists in headers ?
I would have thought you would define some common/standard meta-data
which applies across many services, some which apply specifically to a single
service, together with transaction/service level schemata for the payload
(which may in themselves utilise common data types and aggregates from your
underlaying data model - you do have one of these don't you ?).
On 23/07/06, Minas
Casiou <minas@optusnet.com.au>
wrote:
Hi Fraser,
The reason boils down to "Separation of concerns…"
I don't want to use the SOAP Headers.
My Envelope contains Business Related Information, not
implementation details.
I'll leave the SOAP headers to the WS-* people. As an example,
ebXML and WS-RM have both worked in the area of Reliable Messaging. If I'd
picked the ebXML SOAP extensions, I'd have issues converting my stuff to
WS-RM…
Whilst the SOAP headers are effectively treated as another layer
in the Network Stack, and stripped off before being passed into apps, my
Envelope sits on top of that, and only gets pulled apart by the relevant
business components that work with it. Kind of like the layer on the Network Stack
that sits atop SOAP, but squarely in Business Layer land, not transport.
Also, it works whether or not SOAP is used. Not everything
supports SOAP cleanly. At the end of the day, the business doesn't care how the
message gets there, as long as it's all legible. My Envelope is the Business
Message. Contains nothing related to transports & what have u…
I had a long design session years ago (late 1999), when I decided
how this would work. I only started using the SOAP stuff a couple years later,
but that same model is still working for me today.
Only difference is that the technologies these days are making my
life easier.
For example, XSD include…woohoo. None of that in 1999 with
XDR…
SOAP, attachments/DIME, then MTOM… made life easier for me.
My architecture has not changed yet. And why would it? It's just messaging,
with XML as the data format. A simple header to describe the message &
we're set – can pretty much handle any request. It hasn't failed me yet,
and I haven't even conceived any situation in the Enterprise that I may encounter that it won't
work for. Don't get me wrong – I'm not saying it can do anything &
replace everything else out there etc. It's got its drawbacks –
relatively heavyweight, learning curve & hence slow adoption etc., but in
complex integration scenarios, this model works very well, as it provides a
nice way to abstract many common issues away from business specific logic,
application layers etc.
Main reason for this is that it focuses on the Business data &
services required, and ensures the implementation does not need to re-define
data etc. etc.
The apps that process the message can add their own junk all over
the shop, without corrupting the boundary between business data & technical
data. It sounds simple, and it is…as long as you get it… J
Thanks
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) ?
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.
|
