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