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 > >> > > > >
