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. 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 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. 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. 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. 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. Thanks, Gang > -----Original Message----- > From: Simon Laws [mailto:[email protected]] > Sent: Monday, February 07, 2011 8:33 AM > To: [email protected] > Subject: Re: Can application code and interceptor/handler code in > Tuscany communicate with each other via some context? (UNCLASSIFIED) > > >> > >> > > The difference as I understand it is that only very selected parts > > of the invocation context would be exposed to application code > > (i.e., what's available via the SCA API plus whatever the handlers > > choose to make available), but the entire contents of the > > Tuscany-defined generic context (all message headers for example) > > would be exposed. > > > > Simon > > > > > > I agree that a component implementation should get at only that data > that is allowed access to by the SCA API. > > I would argue that interceptors on the message chain should have > access to any context that they require to do their processing. I > would be very happy if an API were used to provide that to them. > Currently the API is provided by the Message object. However we are > finding that this is not good enough as we need to, for example, get > at the service context in reference processing. > > If there were a context that allowed interceptors to add information > that other interceptors could later retrieve on a thread by thread > basis I think that would do the job. I think you are arguing that the > Thread storage/manipulation should be hidden behind and API which is > OK by me. This API may be different from the API used to expose > context to implementation implementers. > > What I'm not clear on from your comment is what context you would hide > from down-stream interceptors. It seems unnecessary to populate a > context with information that subsequent processing can't read. > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
