[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.