axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glyn Normington" <>
Subject Subsystem responsibilities: SOAP
Date Tue, 08 Jan 2002 16:42:24 GMT
This note is intended to achieve consensus on three points: the principle
of splitting Axis cleanly into subsystems, the principle of separating out
SOAP-specific responsibilities, and the details of separating out the
SOAP-specific responsibilities. We should try to reach consensus on the
points in that order. I've mentioned the later ones to motivate the earlier
ones and give some indication of the direction I would like Axis to take.
As someone pointed out, this kind of architectural work should be completed
prior to beta to avoid disrupting users.

Splitting Axis Cleanly into Subsystems

The Axis architecture could be split more cleanly into the subsystems
described in [1]. I'd like to get a consensus of opinion on how various
responsibilities should be distributed between the subsystems and then
embark on a series of correctness-preserving transformations to partition
the Axis implementation into the agreed subsystems (ideally with each Java
package belonging to a particular subsystem).

The motivation behind this is that, with proper layering of these
subsystems, it will then be easier to replace some of the higher level
subsystems in order to reuse the more basic Axis functional layers. Also,
this layering should make Axis easier to understand and enhance.

I'm assuming there will be a consensus on the above aim, but if not, now is
the time to object.

Separating out SOAP-Specific Responsibilities

The first set of responsibilities I'd like to discuss is the support for
the SOAP protocol. By concentrating the SOAP responsibilities into one or
more SOAP-specific subsystems, it will then be possible to support other
protocols such as XML-RPC.

If anyone believes SOAP should be hard-wired throughout Axis, now is the
time to say so!


Let's go through the candidate subsystems in [1] in turn and see which
should have SOAP specific responsibilities.

Firstly, consider subsystems that could be made independent of SOAP....

I would hope that the message flow subsystem could be made independent of
SOAP, although this is not currently the case. The Message class is tied to
SOAPEnvelope, for instance.

Presumably the admin. subsystems could be made independent of SOAP so long
as the administered artefacts are generalised sufficiently.

The (generic) service subsystem and the non-SOAP service subsystems should,
of course, not be SOAP-specific.

Similarly, I would hope that the transport subsystems could be made
independent of SOAP. Again this is not currently the case. For instance,
"SOAPAction" crops up in HTPConstants. I would prefer the HTTP transport to
simply extract all HTTP headers and store them in a transport-neutral form
in the Message Context. Then some Handler outside the HTTP subsystem could
look for SOAPAction.

I'm not sure about which of the other subsystems need SOAP-specific

How service-specific are providers intended to be?

Should there be a generic encoding subsystem and a specific subsystem for
SOAP encoding?

How about the message model? Glen suggested this as a subsystem and I'm not
sure how well understood this is as a concept.



View raw message