Yang, Gang CTR US USA wrote:
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.
Yes, it is an art, and email definitely isn't the best medium for
artists to communicate with each other and reach a creative meeting
of minds :-( We are both trying our best, but it would be much
easier face-to-face over a suitable beverage :-)
My other comments are inline below.
Simon
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.
That's fine, and we will probably end up using the term "context",
but for the present discussion I was concerned that the word "context"
could be creating different expectations because of implicit parallels
with other kinds of context, for example the contexts defined by Axis2
and JAX-WS.
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.
OK, then we have the same expectation about 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.
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.
The runtime already has what it needs in the form of the current
inbound message and the current outbound message. It doesn't
retain a previous outbound message after the invocation has finished,
and I don't see any reason or use case for adding this.
> 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 "data transfer/context" objects would be developed and created by
handlers and used by component implementations. There's no need for
any injection extensions as the Tuscany runtime would take care of that.
One problem with Map<String, Object> is that different handlers could
collide with each other if they happen to use the same String keys
for entries in the Map. Also this type definition isn't sufficiently
unique to allow the type-driven Tuscany injection mechanism to function
correctly.
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.
I think this supports my reservations about a shared context. By
requiring each handler to define specifically what state it makes
available to the application, it is always clear what information
will be available, based on the combination of handlers (policy sets)
attached to a service or reference. If something else needs to be
provided, one of the existing handlers must be extended or a new handler
must be added.
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.
Your opinions are very much appreciated. Thanks for taking the time and
trouble to engage in these discussions and explain your perspective.
I think if we add some new mechanism then it should be available in
both Tuscany 1.x and 2.x. I'm personally more familiar with 1.x in
terms of the implementation considerations, but others following this
discussion will be able to comment on the 2.x implications.
Simon
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
