On Mon, Feb 7, 2011 at 4:47 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> 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. > > 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.
Sounds like the right sort of mental model to me. > > 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. Well we would have to rely on the context object to do the thread stuff under the covers. I think this was the thrust of the other Simon's comment on this point. > > 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:simonsl...@googlemail.com] >> Sent: Monday, February 07, 2011 8:33 AM >> To: dev@tuscany.apache.org >> 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 > > > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
