On Sep 12, 2006, at 3:18 PM, Raymond Feng wrote:
Hi, Peter.
Thank you for bringing this requirement to the table even though we
don't have this feature in Tuscany yet.
First of all, I think it's a valid requirement to support context
propagation for service invocations, especially for remote service
over a protocol such as SOAP or JMS.
By my experience, we need to have the following pieces:
a) The invocation message should be able to convey context (as
headers) in addtion to the business data (body) accross wirings
b) Binding extensions will be responsible to exchange context
between the binding-specific protocol and the SCA component
infrastructure.
c) Context can be produced and consumed by interceptors and binding/
component extensions.
d) Need some API to allow applications to produce/consume context
in certain scopes.
Any contributions are welcome.
What concerns me is leaking wiring information to the component
implementations. That basically violates the entire goal of SCA
assembly as it puts wiring and infrastructure back into application
code.
What Peter is describing sounds more like an "infrastructure"
component (tied to the IT structure) rather than true
"business" (application) function. One could say that the application
here is an IT one and wants the entire JMS/SOAP/XML/RMI message - and
that the "application" in this case is wiring-aware (e.g. an RMI
mediator may not work well with a SOAP message).
I think this can be done using normal SCA components whose service
interfaces have parameters that are "IT data objects" - for example,
Peter's router could be passed a SDO DataObject containing the full
message (with headers) or an alternative implementation could be
passed a JAXB object. It could flow that on by invoking the
appropriate target reference passing the same or a mutated object.
There is a separate issue about flow-through context that transfers
from a inbound request to an outbound one. However, this is state
managed totally by the framework and would never need to be exposed
in the application programming model.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
