See comments inline below. Simon
Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED Caveats: NONE Some very good discussions here. I think I agree with Simon N.'s point that the component implementation should be restricted to only certain "application" level information. But I definitely agree with Simon L. that passing only disconnected Message (the reason I said disconnected is because the service interceptors/handlers are provided with different Message object than that the reference interceptors/handlers, same is true for before and after invoke) is not enough. There's no need to restrict the interceptors in general. The "general context" only promotes reuse and collaboration.
> With the change to "switching" that I am proposing, the reference interceptors/ handlers would see both the inbound message to the service and the outbound message (under construction) for the reference invocation. They would also see the application's "data transfer" object. I think that's sufficient.
How does this sound, which has been modeled by some other frameworks, such as JAX-WS, and the discussion seems to have hinted. Instead of having a single context, we can have multiple, which are classified and can be hierarchical. One for system level, which would includes all message contexts involved in a invocation including service and possible references, inbound and outbound.
> This one is only accessible by interceptors and handlers.
A multi-level hierarchy would only be available if all invocations were local. For the normal remote case, the only context available would be the inbound message for a service dispatch and the outbound message for the current reference invocation. I don't think we need more than this. For example, if method A invokes method B and then method C, I don't see any reason for the interceptors/handlers for C's invocation to see information relating to the earlier invocation of B. > A second one for application level, which can be a sub-context of the > system context and can also be accessed by the component implementation > as well as by interceptors of course. > By this I presume you mean a generic application context. I think it's better to require handlers/interceptors to create the specific "data transfer" object that they need to exchange information with the application. There could be multiple independently developed handlers/interceptors involved in an invocation and I think this approach is simpler and cleaner than having all the handlers/interceptors reading from and writing to the same application context object. This approach also avoids the need to invent any new Tuscany APIs to provide access to a generic Tuscany application context.
Both system and application context should be invocation bound. By this
> I mean they include only contexts (Messages, sub-context) that are related > to a single component method invocation and accessed only by those > interceptors, handlers and the component implementation (application context > only) associated with the invocation of that component method at the time > of invocation. This is due to the consideration of multi-threading.
Agreed.
Because the application context is injected to the component implementation prior to the execution of any method invocation, the framework should make sure that the content of the application context is made available to the component implementation only during the execution of the component method. This can be tricky because of the multi-threading. Synchronization may be necessary.
I'm concerned by the complexity involved in this. My suggested approach using "data transfer" objects avoids this issue because these are just regular objects and it wouldn't matter if the application passed them around.
Another comment on the user-defined context. I have no objection to
> allowing users to define their contexts and even to extend the injection. > But with a generic application context to allow reuse, that extension > is probably for specialized scenarios.
See my comments above on this. Simon
