RE: [xml-dev] Didier's lab report

Paul asked some questions which I have answered below.

-----Original Message-----
From: Paul Prescod [mailto:] 
Sent: Sunday, April 28, 2002 5:08 PM
To: ; 
Subject: Re: [xml-dev] Didier's lab report

John F Schlesinger wrote:
> 
>...
> 
> In case you need any more support, I couldn't agree more and for
exactly
> the reasons you give (loose coupling). The worst thing you can do when
> communicating between two applications is to boil the interface of one
> into the object model of the other. That never works (which is
probably
> why DSOM, CORBA, RMI, DCOM and all the other distributed object models
> have failed to help at all in application integration).

The "common wisdom" in the industry is that DSOM/CORBA/RMI/DCOM have
failed because they were not standardized across the industry. I agree
with you, however.
[John F Schlesinger] Thanks.

> The second worst thing you can do is create a statefull protocol
between
> the two applications. That boils the behavior of one into the object
> model of the other.

Agreed. But we must be subtle here: no real world application can be
built without dealing with state. The way I deal with this is with the
rule that any state that should be persistently shared between client
and server should be owned by one or the other (usually the server) and
given a Web address for later addressing.
[John F Schlesinger] The problem again, is that you are now building a
new application instead of integrating two independent ones. For
example, if I execute a trade for a security and the rule is that the
trade should be hedged, what could happen is that I write an order for a
hedge and pass it to the derivatives desk. This is slow and error-prone.
It is better to integrate the two applications. When I execute the
trade, the trade execution message (representing a business event) goes
to the risk application, the GL and to the derivatives application where
it looks like a hedging trade. There is no state shared between the two
applications.

> For these reasons I advise my clients never to use request/reply when
> the other end is going to make a state change that is visible to the
> client. This has to be a one way message.

Could you go into a little bit more detail? When you say one-way-message
you of course mean that there is no meaningful response. But do you also
mean that the client SHOULD NOT expect that the state change has taken
effect by the time the connection (if any) is closed? If the latter, do
you have a back-route for the client to know when the state change has
taken effect?
[John F Schlesinger] When an application completes a transaction the
message it emits is a business event to the effect that that transaction
has just taken place. The emitter has (or should have) no idea what
other applications will react to that event. In the example above, the
trade execution application didn't know that the GL, the risk system and
a derivatives system were all going to react to its message. So the
answer to your question is that the client certainly does not expect any
or all of these applications to reply - there is no request to which
then can reply. This is crucial for a value chain, which is what
application integration creates. If the first application held state
until the second reacted and so on, then the whole chain would have to
complete while the client was waiting. This, in general, won't work.
There is no back route at the middleware layer. There may be
confirmations at the application layer (as when Amazon emails me to say
the book has been shipped). 

In general, if you have time I'd be curious if you could back these
rules up with descriptions of the consequences for disobeying them. I'd
like to add them to my collection of guidelines and patterns.

[John F Schlesinger] If you disobey the one-way transaction rule then
you end up with everything happening at once. David Hume summed this up
in his Treatise: "For if one cause were co-temporary with its effect,
and this effect with its effect, and so on, 'tis plain there would be no
such thing as succession and objects must be coexistent." It takes an
18th century Scottish philosopher to tell us how to use web services!
There is also a problem of transactional integrity. If I request a
service to change something and nest that within a transaction where I
change something, then I have just created a distributed two-phase
commit. Trust me, this doesn't scale.

> ... If the client has to wait for
> the other end to say it did something, there is a very fundamental
> problem with the interaction (you accidentally wrote a new application
> instead of integrating two existing ones). 

Interesting distinction. I think that "web services" needs to address
both integration and new application building. But your sense is that
they are very different disciplines?

[John F Schlesinger] Absolutely. Application integration is all about
loosely coupling business objects that share no state. Building an
application is all about moving state from the user interface to the
database through the business objects. 

> ... Similarly, request/reply must
> be stateless.
>
> There are, as you can imagine, some deep implications for
orchestrating
> services. If the message emitted by an activity is going to create a
> state change, then that activity cannot wait for a reply. Instead it
> must complete and a new activity must wait to be kicked off by a
message
> saying that the change occurred. This too is fundamental.

My primary concern about this rule is that making bidirectional
cross-organization applications is "twice as hard" from a security and
deployment point of view.
[John F Schlesinger] You're right, but the alternative is worse.

 Paul Prescod