Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED
Caveats: NONE
To make it more readable, some text is cut.
... cut ...
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 key collision can be remedied by using hierarchically qualified key
names, such as "org.apache.tuscany.axis2-binding.XXX", which makes
collision unlikely. In my scheme, the entire application context object
(a single one of type say ApplicationContext), which is implemented
using Map<String, Object>, is injected into the component implementation
and let the component implementation to get what it wants and ignore
those it doesn't care. I don't see how it would cause injection
difficulty.
To me this naming convention adds complexity and the possibility
for problems if the convention isn't followed. If a new type is
defined rather than using Map<String, Object> directly, this solves
the injection type problem, but it means that all application code
that uses this capability must add a dependency on a Tuscany-specific
class, which means that the component can't be run (or even loaded)
on other SCA implementations.
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.
I think my original comment was a positive one - sharing and reuse are
good and sometimes it is even necessary. Making each handler to define
its proprietary "context" prevents sharing and reuse, which is
undesirable. As I mentioned earlier, if the isolation is required, the
proprietary contexts can still be defined to achieve that. But I think
most cases, we simply want to have an existing generic context to be
provided and use it.
Thanks for the clarification. If handlers want to share information,
they can create shared context (not the same as the "application context")
to do this. I think it's undesirable to overload the purpose of the
"application context" by also using it to share state between handlers.
This exposes things to the application that are intended for handler use
rather than for application use, which isn't desirable IMO.
Simon
--- cut ---
Gang
Classification: UNCLASSIFIED
Caveats: NONE
