Re: The Two Way Web

Hi Stefano,

Stefano Pogliani wrote:
> 1.      It is important to access "high-level" functionalities on remote
>         systems. By "high-level" I have in mind a "service level" model,
>         where I invoke a "functionality" which is provided remotely
>         by something.
> 
>         There are many ways to do this : RPC, Corba, Java, DCOM etc.

HTTP, etc..

> 
>         Each of these technologies make it "difficult" to manage some
>         aspect of the whole problem (security, platform dependency etc...)
> 
> 2.      RPC or OO ?
>         I have been discussing this issue in other situations and, again, I
>         hope not to mis-target the problem.
> 
>         The RPC approach assumes that you know the "entry point" of a given
>         library, in some way. The library can be statically linked,
>         dynamically linked or remotely accessed.
> 
>         The OO approach assumes you execute an action on a given object. The
>         object can be local or brokered somewhere else, doesn't matter.

I would say "execute an action".  I'd simply say "send a message".

>         A part from the obvious advantages of an OO approach, at the end,
>         we are talking about executing "function calls" (do not misunderstand
>         me here, I am talking about the advantages of OO...)

No, we are not.  A function call in no way resembles the sending
of a message, unless you're looking at the level of bits moving
from sender to receiver.

> 3.      Now, the game is to make different systems (software systems) which do not
>         know each other talking together. These systems are different because of
>         platforms, of languages and technologies.
> 
>         What I need is to establish a communication among them in the less invasive
>         way I could imagine and in the quickest way I can.
>                 - less invasive : I cannot sometimes change the installed products
>                   nor I can add some additional layers because the target machine
>                   will never support it..
>                 - quickest : the business requires integration as a differentiating
>                   factor. I need to serve my users (jnternal or external) "now"
> 
>         So, a "unified" way of talking is required.

Now *that*, I'd agree with.

> 
> 4.      IMHO, the most simple way to provide this "unified way of talking" is
>         by exposing "ENTRY POINTS" corresponding to the "FUNCTIONALITIES" I need
>         to access on a different system.
>         I do not care, here, of Set/Get in the OO way. Maybe the functionality I want

Set/Get is most definitely not OO.  It completely breaks rules of
data-hiding, and almost always (in practice) breaks rules of
encapsulation.

>         to expose (and, on the other side, I want to use) is just Set/Get of an
>         object property...or maybe is starting a CICS Transactions.
> 
>         Here we are talking BUSINESS. When I say this, I say that the granularity
>         is defined by the business and not by us technical people.
> 
>         If I expose "Entry Points", the most natural way of doing is, IMHO,
>         by exposing "method signatures" since the "context information" is made
>         clear to the interface and not assumed to be in some particular state.
>         One of the constraint is, in fact, to be LESS INVASIVE AS POSSIBLE on the
>         system where you are executing the service; it should be seen AS MUCH AS
>         POSSIBLE as a BLACK BOX.

I don't see how you came to that conclusion based on your very
reasonable assumptions.

Exposing functionality with method signatures builds a system that
is brittle.  If the server changes, the client must too for that
functionality too be successfully deployed (assuming it requires
a change in the interface, as many changes can).

On the other hand, using messaging, there is only one "method
signature" (eg. the standard HTTP method set).  Functionality is
extended by both ends agreeing on the changed semantics of the message
itself, not the protocol on which it is delivered.  This shifts the
"interface migration problem" to the application, and away from the
protocol - where it should be.

With RPC, the application never gets notified of an invalid invocation.
With messaging, the application is the sole arbiter of deciding what's
valid, what isn't, and what gets done with the invalid stuff (maybe it's
partially valid?  :doesNotUnderstand anybody?)

>         The "Technical Oriented Way" is the approach followed by XML-RPC and SOAP.
>         I consider this approach MORE TACTICAL (opposed to the previous one which is
>         more STRATEGICAL since involves some BPR) but is very suited to "include" in the
>         integrated solution things that you KNOW BY ENTRY POINT (so, virtually, everything).

Using XML-RPC or SOAP, your software will be as brittle as any piece
of software written in CORBA or DCOM or any other RPC based mechanism.
If that's what you want - perhaps you control both ends of the wire,
or there's a legacy system that can't afford to change - then go ahead
and use it.  But please don't claim it's the best solution for loosely
coupled distributed systems development; it isn't.  In fact, it's
probably the worst thing you could do.

> 7.      HTTP is, according to me, a different side of the coin.
>         It is an answer to the question : Once I have the "serialization", what is the
>         transport ?

It's very unfortunate that so many people think so little of HTTP.

>         HTTP is "AN" answer, NOT "THE" answer to the question.
>         The answer depends not only on the question BUT also on the context where you operate.

Sure.  Messaging is *the* answer, and HTTP is a well understood
and pervasively deployed message transfer protocol - not perfect, but
not just a transport protocol either.

MB

Received on Tuesday, 14 March 2000 10:16:23 UTC