Classification: UNCLASSIFIED Caveats: NONE A general comment I would put here is that software design is an art and it will reflect different approaches depends on where your emphasizes are. My philosophy that lead to what I described is simplicity, abstraction and reuse. But I'm fine with and would appreciate any design that would allow me to do the WS-Security. My specific comments follow.
Thanks, Gang > -----Original Message----- > From: Simon Nash [mailto:n...@apache.org] > Sent: Monday, February 07, 2011 1:09 PM > To: dev@tuscany.apache.org > Subject: Re: Can application code and interceptor/handler code in > Tuscany communicate with each other via some context? (UNCLASSIFIED) > > 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. I prefer the term "context" over "data transfer". We are not overloading this term, in the context of our discussion, which is to share states among various codes during a specific invocation and message processing, it is referred to as "context" in other frameworks and specs. > > > 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. I don't think I was suggesting remote cases although Tuscany is claimed to be a distributed framework. I qualified the "context" to be bound by a single component method invocation. This means the inbound service and the possible outbound references, not including the targeted services of the references. > 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. The philosophy here is to take what you need and ignore what you don't. Don't forget, runtime itself is also operating in the same context and could make use of this context object, too. > > > 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. The drawback of this approach is that it does not abstract and promote reuse. Each handler and/or component implementation is required to develop its own context object and injection extension while an abstraction, such as a map<String, Object>, could satisfy most demands and be reused. The shared general context also promote sharing. For example, in JAX-WS framework, certain WS-* related properties that are put in by the underlying JAX-WS framework provider or other handlers can and are used in our WS-Security implementation. It promotes reuse. In some case the information that are put in the context by the framework or other handlers is not obtainable by our WS-security handlers because of the phrases and layers differences. The proprietary extension mechanism is useful an could be used if isolation is required. > > > 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. Agree that we always need to consider the effort and if it makes sense, especially if we are talking about Tuscany 1.x. You guys are exports here and I'm only providing my opinion and would appreciate your help. > > > 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 Classification: UNCLASSIFIED Caveats: NONE
