Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP and the Web
 Hi John, John said: First, what I recommend SOAP for. Every company I work with has a huge problem of application integration and is spending a lot of money on it. The reality of integration is that it is a massive problem of managing semantics and needs to be attacked with a simple strong architecture. The key is loose coupling because it must never be the case that a change to one interface causes knock-on changes to other interfaces (there could easily be 50,000 of them). This is the 'syntax problem' - how to keep adapters stable. We also have to make the output of one application the input of another. There is almost no chance that this can be done without transformation (thank heavens for XSLT). This is the semantic problem. We have to centralize the semantic transformations in order to keep the adapters stable. This means we have to send the message to a destination which will decide what to do with it: transform it here; send it elsewhere for transformation; or both; enrich the message; route it based on content or (better) the envelope (like the postal service). Didier replies: Confirmed, I just finished a mandate involving several applications to be integrated. As requirements we had to keep a journal of all transactions (i.e. function calls between apps), and to make sure that if one side's function call definition change over time that we can adapt to it without having to change both side. For instance, connecting an ERP module (A) to a CRM module (B). Before using SOAP as a glue between the two applications, when (A) changed, (B) had to be modified or the middleware performing the operation had to be modified (i.e the business object). The previous impedance mismatch resolver was written with a procedural language (java) and required a code modification/re-compilation every times one side or the other changed, moreover, certain systems using DCOM as middleware where difficult to adapt to the middleware!! result: increased costs. Now this middleware has been replaced with an XSLT engine sitting between both parties and acting as an impedance mismatch resolver. We've been able to either get a SOAP interface from the manufacturer or implement them since several languages now include automatic SOAP RPC marshaling (result: a less expensive operation). The good points: a) we used XSLT as a function impedance mismatch. We also used XSLT to render the function calls for monitoring and debugging purpose. Since the client wasn't confident about Windows reliability we used a Solaris server as impedance mismatch resolver. The good point here is that it was relatively easy to perform the transformations with XSLT. b) The XML function call serialization is easy to include in a log and quite easy to decode. However, since we got spare cycles on the impedance mismatch resolver, we used XSLT to transform the different SOAP messages into a single message format to be stored in the log file. c) The impedance mismatch resolver can also behaves as a message hub by replying immediately to the callers, keeping the function call in a message queue end sending it later on. Again, an XSLT transformation allowed us to easily transform the content of a queue into a single rendering format for display. In contrast to other systems, we can see the function call content in addition to the meta data associated to them. d) Since the impedance mismatch resolver is an HTTP server, it is easy to connect to it and manage, render the queues content, monitor the transactions from a web browser. In case we didn't developed an XSLT template for a particular SOAP function call we are still able to view it as plain XML. My whole experience with SOAP is that when used as an RPC, you have several advantages when compared to the other marshaler types (IIOP, RMI, etc..). If used to simply do what a REST like architecture does well (i.e. GET documents) then obviously SOAP does not shine for that type of application. On the other hand try to retrofit function calls in a REST like architecture is feasible but more costly to implement. Moreover, the CRM and ERP manufacturers where able to provide us with either a relased or "beta" test SOAP interface to their module. Impact: reduced cost since we didn't had to re-write that ourselves. The choices are obvious then. cheers Didier PH Martin 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
