Terminology and resources (was Re: Service Description & Discovery)

[Gerd Aschemann <as...@informatik.tu-darmstadt.de>]

Ara Kassabian wrote/schrieb:
> Those of us who worked with CORBA are seeing the writing on the wall with
> SOAP--we are just having trouble reading it because it is very fuzzy right
> now :-) I am sure some king of service description language (read IDL) and
> discovery algorithm (read CosNamingService and CosTradingService) will come
> in time. And I am REALLY looking forward to the debates when the issues of
> transaction and security come up!

Yes, you are very right. If one has a certain background in
distributed systems (I have also been working on CORBA for some years
now) even the terminology is hard to understand (maybe its easier for
an OLE/COM/DCOM/... veteran?), e.g., I do not understand the disputes
whether SOAP is RPC or not-RPC, which come up from time to time.

As far as I know (and I have been working in a university for some
years now, where a clear terminology rules), we can clearly
distinguish between four communication paradigms, which are themselves
a result of combining different approaches.

		    ||	synchronous		|  asynchronous
====================##==========================#===========================
task-oriented	    ||	Remote Procedure Call	|  Remote Service Invocation
--------------------++--------------------------+---------------------------
message-oriented    ||	Rendezvous		|  Datagram

So, I see now that SOAP 1.0 was a RPC paradigm, while SOAP 1.1 enables
both, synchronous calls as well as asynchronous ones: But its still
task-oriented communication.

(Bear with me, I am only working on SOAP for two weeks now, and have
not yet fought through all resources and specs etc.)

This leads me to another trouble: most resources on SOAP lack a
certain structure which should be more or less common to all technical
and scientific documents, like

- abstract
- purpose of document
- intended audience (if not clear from publication context)
- classification of document
- scope of document
- problem statement
- suggested solution(s)
- related work
- discussion
- references/further reading

Besides technical and formal specifications, in the future some sort
of tutorials are required to help understand SOAP. The documents I
have found so far give an overview on SOAP on the protocol level, but
it will be necessary to have comparable introductions from different
viewpoints and on different levels, e.g.,

- overall purpose of the protocol/technology,
- overall architecture,
- history,
- classification with respect to other (distributed systems)
  architectures,
- programming model, APIs
- related technologies (XML, HTTP, ...) and standards
- tools (BTW: Is there some sort of IDL compiler? Is there some sort
  of IDL? I suppose not ... at least not a standardised one, right?
  Are there static vs. dynamic interfaces? I found only dynamic
  examples, some sort of DII, and some magic behind the "static"
  interfaces in the xml-soap samples.)
- available and planned implementations (reference implementations)
- commited companies/institutions/standardisation bodies
- ...

(I would not say, other technologies or their proponents have done or
are doing a better job, a least in the beginning ... cf. OMG/CORBA ...
But there are also examples for a good start, e.g., Suns Jini ...
although: it's easier if a single company is the driving force).

Ok, the work on SOAP seems to be in the early stage in a fast market,
so maybe no one found the time to do so upto now. But I would ask even
the gurus and/or their companies who enforce SOAP (MS?, IBM, ...?) to
make such information available in a suitable way. In particular to
know the driving forces behind the technology is essential to a
company if they are to decide if the should start building products on
it.

Its not enough to set up many, many mailing lists/newsgroups
(soap-dev@apache, soap-user@apache, IBM-SOAP forum,
SOAP@discuss.develop.com, I am sure I missed some ...) and some link
collections, or, even worse, some news collections without
reference/access to the genuine resources (see http://www.soap-wrc.com
...)!!!

-- 
Gerd Aschemann --- Aschemann@Informatik.TU-Darmstadt.de
    Veröffentlichen heißt Verändern (Carmen Thomas)