A couple of us have started to discuss this as well in relation to
Celtix...My main concerns, which there appears to be agreement, are:
1. We are not instituting a "canonical" form model similar to JBI in
the runtime. I think Jeremy stated this is not the case
2. Local invokes - i.e. where semantics are "pass-by-reference" -
honor that and do not have *parameters* mediated. This appears non-
controversial.
3. Mediation is done using handlers and intereceptors. I think we are
also in agreement here.
I still have questions around how the "container" and "bindings"
declare support for certain data binding formats. We need to come up
with a design here. For example, would the following be a valid
approach in your opinion (I haven't thought too much about it so it
is kind of vague)?
1. Implementation types declare whether they support pass-by-ref.
Since this is a Java runtime, pass-by-ref means object references in
the VM.
2. Bindings register themselves can be queried for what formats they
support. They may delegate to some data binding service.
3. Tuscany may want to "declare" some common formats such as Java--
>SDO, SDO-->, StaX stream-->Java, Java-->Stax, SDO-->StaX, JAXB--
>Java etc. and have interceptors or handlers perform those
transformations. These handlers could be registered with a wire
builder and inserted into an invocation chain
4. Implementation types and bindings declare what pass-by-value
formats they support in order of preference.
Dan, I know you have a bunch of thoughts on this, so it would be
interesting to discuss them in this thread.
Jim
On Mar 22, 2006, at 1:36 AM, ant elder wrote:
This thead has gone very quiet, can we resurrect it.
One of the reasons for looking at this is I'd like to make WS
interactions
really fast. For example, making a WS gateway by wiring up an
entryPoint
with a WS binding to an externalService with a WS binding, perhaps
with
different QOS attributes on the WS bindings when we support that.
Right now
as the wire format is Java objects it means a data binding must
convert the
SOAP message to Java objects and back again which is unnecessary
and quite
slow. That scenario is quite simple but could also be extended by
inserting
non-Java components into the path, eg, XSLT or JavaScript/E4X
components.
Doing that there should still be no need to convert a message to
Java object
representation.
So, I quite like the sound of what Jeremy was suggesting.
...ant
On 3/16/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Jim Marino wrote:
On Mar 15, 2006, at 3:37 PM, Jeremy Boynes wrote:
<snip/>
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.
As I understand JBI there is one canonical message format. That is
not
what I intended to propose here. What I was trying to capture is
that we
will need to deal with components at either end of a wire that are
expecting different data types and that we have to have a way to deal
with it. This will start to become important when we have different
implementation types that need to interact.
I believe that the ability to attach mediations is one of the
responsibilities of the runtime. That is why we built in an
interceptor/handler chain to provide the attach points for
mediations,
policies, serializers etc., things that are not an explict part of
the
component provider's programming model.
What was your question about local invoke? There is nothing to
prevent
the wiring framework from optimizing out the entire pipeline and
using a
direct reference *when it determines that is a valid optimization.*
Why would a container need to declare support for Java types such as
primitives and Object? A user programming a C++ or BPEL component
would
have no expection of such foreign types. I would expect a call
from C to
C to be optimized to a direct C call. However, any call between a
Java
component and C++ is likely to need some form of conversion and I
would
propose that doing that is the responsibility of the runtime not
the user.
I agree that Object is the appropriate type for the payload of the
message (assuming the runtime is implemented in Java :-) ) as it
is the
most flexible type. However, client and provider may expect different
specializations of Object to be passed out/in so, except for the
direct
transfer case, some data transform will be required.
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?
See above. There is nothing to prevent different data types being
passed
provided client and provider containers support them. I don't think
providing N^2 mappings is realistic; I think we need to provide a few
common generalized forms that all containers speak and a few direct
mappings that are in common use. Note I specifically said "a few"
forms
and not one.
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
