SOAP and OO: Dynamic Services

I am struggling with how to apply my understanding of object-oriented
architecture to SOAP. SOAP seems to me a useful widely-supported alternative
to COM and CORBA. Some articles I have read seem to reflect this, others
seem to suggest SOAP utilises a new service-based architecture, rather than
the familiar object-oriented one used by COM and CORBA. (But if it is
service-based, why is it not called SSAP?)

SOAP seems to divide the object world into static objects that have
operations and are referenced as services at URIs, and dynamic objects that
have no operations and are passed by value. (By static I mean effectively
created once and never destroyed, and by dynamic I mean created and
destroyed on demand.) There seems to be no standard way in SOAP of
representing and referring to dynamic objects as services. The ability to
create objects with operations dynamically is a fundamental aspect of
object-oriented architecture.

For example, if I am writing a simple sales service, I might define a couple
of interfaces:

interface PointOfSale {
	Transaction createTransaction();
}

interface Transaction {
	void addItem( Item );
	void purchase( Payment );
}

where Item and Payment are pass-by-value types. PointOfSale is a static
object that is always available and clients are told where to find it: this
is easily represented using SOAP. However the dynamically created
Transaction cannot be represented in a standard way using SOAP. The SOAP
specification intentionally excludes objects-by-reference, I presume due to
maintaining simplicity and not specifying a garbage collection model.
However by specifically excluding them it at least gives them credit as a
concept.

One easy solution is to merge the two interfaces:

interface PointOfSale2 {
	TransactionReference createTransaction();
	void addItem( TransactionReference, Item );
	void purchase( TransactionReference, Payment );
}

But this is very non-object-oriented and thus will not scale and is not
easily extensible.

Some HTTP implementations of SOAP add information to SOAPAction or SOAP
message header defining the object being targeted by a message. However,
these are all completely different and are not compatible with each other.

Static SOAP objects are referred to by URIs, which seems a reasonable (and
consistent) solution for dynamic objects. This also means that clients need
not be aware whether an object is static or dynamic, which is great. So
createTransaction() could return a URI which clients can send messages to,
perhaps http://me.com/Transaction123 or http://me.com/Transaction?id=123 (it
would be helpful to have a convention for dynamic URIs). Now, a client may
want to know exactly what it has a reference to, which could be an object of
any subclass of Transaction, so the returned URI needs to be dynamically
typed (probably with reference to a WSDL port type), and there is no
standard way of representing this.

I am not sure if SOAP itself should be enhanced with a dynamic object
reference type, because this is against its stated design goals. However,
without any standard way of representing dynamic objects I am sure that many
different ways will (and have already been) invented of achieving this, none
of which will interoperate. Surely it would be better for W3C to define a
SOAP extension for representing dynamic objects? I would suggest doing this
by adopting WSDL as the W3C standard for describing SOAP services, and
enhancing WSDL so that it can be used to describe both static and dynamic
objects by providing a way of defining dynamic references (URIs) for
services.

I cannot find any articles really addressing this issue. Even articles
comparing CORBA and SOAP do not mention that CORBA represents dynamic
objects in standard way and SOAP does not, which seems a fundamental problem
for the CORBA-SOAP bridges that are appearing. So am I missing something?
Are we all meant to move away from object-oriented architecture (which when
properly applied works ten times better than anything else I have seen), to
some new service-based architecture? If so, what is this new architecture
and why is it better?

Does anyone have any insight on this?

Ben

Received on Wednesday, 11 July 2001 12:49:42 UTC