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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [regrep] Direct Data Exchange vs. SOA




Joseph Chiusano writes:

"I have an inquiry that is not directly related to our mission here, but
I hope to get some good insight in response please:
Let's say we have a purchase order process between trading partners (PO
sent, Invoice received). There are (for the purposes of this inquiry) 2
possible ways to handle this process:

(1) Direct Data Exchange (create XML documents based on a common schema,
and exchange them between trading partners)

(2) SOA (have a purchase order/invoice shared service that is discovered
in a registry, etc.)

My inquiry is: What would drive an organization to use one approach or
the other, from both a business and technical standpoint? For instance,
would "critical mass of services and/or trading partners" be a driver
for SOA vs. direct data exchange?"

Dale> I don't know whether this is either good or insightful but...

One Business/Technical Consideration: 

Suppose the Service defines a WSDL for receiving a PO and for responding
with an Invoice (which I guess is how you are setting this up). Then the
Service gets to define both the data elements and structure of both the
Request and Response. The burden is put on the client side to be able to
get the data into that form and receive it in the other announced form.
For buyers (senders of P0s), if they had to consult the wsdl of each of
their 10,000 suppliers, I could see it getting to be a burden on them
for doing business with possibly 10000 variant wsdls.  While is
logically possible all the services would be the same, wsdl/SOA is
inherently unconstrained in how services are set up. Usually a service
makes it easy on itself as far as how the input and output messages are
defined. There is nothing to force all the suppliers to set up their
wsdls the same way, and because wsdl allows them all to be different, an
immense number of one-off solutions is in the wings. Pretty good
situation for SI organizations though.

On the other hand, a standard PO that a community agrees to exchange
sets different constraints in practice. First, the buyer usually has a
big say in what standard is used in the PO, and the seller has to "make
the data right" (translate) for their side of things. Second, although
in principle the buyer could select 10000 different formats, in practice
that would never happen. Similarly for invoices.

Technical Consideration:

SOA is usually seen as using a RequestResponse MEP, which over HTTP,
means that the Request and the Response flow over the same connection.
For the Direct Data Exchange perspective, a pair of One-Way MEPs or a
RequestResponse MEP are just implementation details,  and can be chosen
based on whether a Response will always be ready in a timely way or
whether significant delays may occur. SOA still does not have a good
"asynchronous" MEP, and usually you will find it discussed under the
idea of a "callback," which reveals how much the remote function call
perspective still animates their design patterns. Maybe ws-eventing or
ws-notification will move things toward partial parity, but that is
still a ways out IMO.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]