ebxml-jc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: update on Versatile B2B gateway
- From: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>
- To: <ebxml-jc@lists.oasis-open.org>
- Date: Tue, 24 Jan 2006 10:12:51 +0100
Title: update on Versatile B2B gateway
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.
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.
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.
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.
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?).
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
...
I hope
you find these comments useful.
Best
regards,
Pim
van der Eijk
Since
there will be quite some time until ebMS
I
would suggest you mention In figure
An update of the previous "Versatile B2B gateway" SOA design
pattern draft, that was submitted to ebSOA TC.
- The
"synchronous WS request-response" case was added as one of the cases for Fig
2.
- Fig 3 was remodeled to show the document exchanges
and its back-end binding to be appropriate in case of business
processes.
Jacques
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]