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.
> 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.
> 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?
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.
> ... 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?
> ... 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.
Paul Prescod
