[
Lists Home |
Date Index |
Thread Index
]
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
|
