On Mar 15, 2006, at 3:37 PM, Jeremy Boynes wrote:
A couple of us had an offline chat about what the format of data would
be exchanged on the wire during an interaction between a client and a
provider. The spur for this was the JSON binding Ant was working on
which has no obvious affinity to XML.
Another issue related to this has been about supporting streaming
types
for interactions where data flows through a system rather than
terminating there. This is related to Axiom and its use for precisely
this purpose in Axis2.
I wanted to capture thoughts whilst still current and open the
discussion.
As I see it there is no single answer to this, well apart from "it
depends." :-) I think it is necessary for us to support the flow of
any
data type that is supported by both the client and the provider. With
the ability to attach data transformation mediations to wires, this
actually becomes a requirement to support any data type that can be
mapped from client to provider and back again.
In any interchange there are just two things that are defined: the
format of data that will be supplied by the client and the format of
data that will be consumed (delivered to) the provider. Neither client
or provider needs to be aware of the format of data on the other
end or
of what gyrations the fabric went though in order to make the
connection. As part of making the connection, it is the fabric's
job to
make the connection as efficient as possible, factoring in the
semantic
meaning of the data, the policies that need to be applied, and what
the
different containers support.
All this flexibility just about requires we use the most generic type
possible to hold the data being exchanged: a java.lang.Object or a
(void*) depending on the runtime. The actual instance used would
depend
on the actual wire, some examples from Java land being:
* POJO (for local pass by reference)
* SDO (when supplied by the application)
* Axiom OMElement (for the Axis2 binding)
* StAX XMLStreamReader (for streamed access to a XML infoset)
* ObjectInputStream (for cross-classloader serialization)
and so forth.
Each container and transport binding just needs to declare which data
formats it can support for each endpoint it manages. The wiring
framework need to know about these formats and about what
transformations can be engaged in the wire pipeline.
For example, the Axis2 transport may declare that it can support Axiom
and StAX for a certain port and the Java container may declare that it
can only handle SDOs for an implementation that expects to be passed a
DataObject. The wiring framework can resolve this by adding a StAX-
>SDO
transform into the pipeline.
The limitation here is whether a transformation can be constructed to
match the formats on either end. If one exists then great, but as the
number increases then developing n-squared transforms becomes
impractical. A better approach would be to pick the most common
formats
and require bindings and containers to support those at a minimum,
with
other point-to-point transforms being added as warranted.
This seems kind of like JBI. A question here is whether a normalized
form is really practical and whether it is the easiest thing to do.
Also, is mediation even the concern of the runtime? Should the
runtime just make it possible to do mediation and delegate to a
mediator "interceptor/handler" or create an implementation type that
is a mediation component? Also, what about local invoke? I assume a
container would have to declare support of primitives and Object? I
think it may just be easier to settle on Object as the common form.
Given the flow issue descibed above and the XML nature of many our
interactions I would suggest that a StAX XMLStreamReader may be the
most
apporpriate common format (at least for now). It's native to Axis2 and
Raymond has posted patches already to support it in SDO.
Again, what about local invocations or things that just require
simple serialization over a socket?
Alternatively, we don't need all of StAX for this to work so it may be
simpler to provide a basic API that is essentially the same as an
XMLStreamReader but without all the other stuff.
Thanks for reading this far. The idea was to capture thinking and all
input is welcome.
--
Jeremy
