[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-jc] RE: update on Versatile B2B gateway
Here is an update based on Pim's
comments. Mostly: - not making the gateway appear as only
possible with ebMS V3. - reduce emphasis on WS-Addressing (not
critical to its function, though a natural enabler with ebMS3) - reminding that SOAP and WS on the
back-end are just use cases... Jacques From: Pim: From: Pim van der Eijk
[mailto:pim.vandereijk@oasis-open.org] Hello Jacques, This document was mentioned on the call yesterday,
and I remembered I hadn't provided feedback to it yet. First of all, I think it is a really good document,
which I think should be posted, when final, on the ebXML.org site (I'll
check with my colleagues). There is a recently updated OASIS
template for white papers you could use for it. http://docs.oasis-open.org/templates/ Some other comments: Page 2, when a message is not a service invocation. Implicit in the first bullet where you mention BPM,
the message may be just a way to transport e.g. documents intended for human
consumption. There may be a mapping from ebMS header fields
RefToMessageId and ConversationId to workflow processes or to route the
document to the responsible employee. There are actual projects using
ebXML for this, e.g. in eGovernment to reduce paper-based processing. <JD> right, the mapping of the
message to the process instance is likely to involve content semantics, i.e.
some value in a field. If a service were to do this, its job would be to
dispatch the doc to the right service instance after looking at this content
(say a conversationId). Rather contrived... Plus, as a doc may be expected
at different places in the process instance, and again the "type"
of the document is not necessarily 1-to-1 with the workstep in the process,
then the service would not have this intelligence. It would be a rather lame
publisher to a queue. Page 4 and Figure 1 on page 5, these mention
ebMSv3. The current OASIS/ISO 15000-2 Standard offers many of
the same benefits, and its security and reliability features (while
further updated in some WS specifications) are quite stable and
reliable. It is good to mention the added features of
ebMSv3, but I would suggest you talk about ebMS (without
version number) in the general text. I am a bit concerned that people may
interpret this as saying there is no (longer any) value in ebMS2 today, which
isn't true and may upset some people that actually use it today. This
comment applies to other figures. <JD> Right, Fig 1 should have just
ebMS. Now, every other fig involves message "pulling" which is only
supported by V3. Also, Fig 2 shows a "SOAP intermediary" usage of
the MSH that was not possible in ebMS2. However, Fig 3 could be made ebMS too:
the pulling is not essential to Fig 3. I agree that the doc should also apply
to ebMS2 even if V3 provides additional support for the SOA pattern. Will
modify. Perhaps this and other diagrams should also
explicitly indicate that within the enterprise SOAP requests are just one
way of connecting to backend systems (JMS, MQ, Tib/Rendezvous etc.). This
is implicit in later references to integration brokers. <JD> yes. Although Fig 2 and 4 are
focusing on the SOAP request case (using the MSH for routing WS invocations). Page 5, this suggests WS-Addressing is effectively a
prerequisite to support this pattern, which seems too strong (it is useful, but
couldn't the functionality described be achieved using more convential
methods?). <JD> good point: WS-A is mostly of
interest when forwarding to WS on the back-end. Will make this requirement more
relative to this. As a more general comment, the document is mainly
focussed on the connectivity and decoupling features of the B2B gateway. It does
not discuss trading configuration, partner management, activity monitoring and
business process (choreography) support. But perhaps those deserve
separate white papers ... <JD> Right. The doc just addresses
one function (connectivity) in the SOA architecture, and this
"integration pattern" does not exclude these other functions
- it only involves messaging. Clearly there should be other integration
patterns involving other ebXML specs - it is just we expect them to be
separately described. I should make that clearer. I hope you find these comments useful. <JD> definitely - thanks! Best regards, Pim van der Eijk Since there will be quite some time until ebMS I would suggest you mention In figure From: An update
of the previous "Versatile B2B gateway" SOA design pattern draft,
that was submitted to ebSOA TC. Jacques
|
VersatileGateway-SOA-Intg-Pattern-5.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]