I think business components that are totally agnostic to the mechanisms
of the underlying framework shouldn't have any context information from
the binding. However, we could have an optional callable interface that
can be implemented as a component if one needs contextual information
from the underlying infrastructure.
For example something like
public interface Callable {
public Object onCall(CallContext callContext);
}
If the target component is implemented as a Callable instead of a normal
POJO the runtime could create a CallContext information with the payload
and header information and route it to the component.
Ta
Meeraj
-----Original Message-----
From: Peter Cousins [mailto:[EMAIL PROTECTED]
Sent: 13 September 2006 12:49
To: [email protected]
Subject: Re: Binding Context?
Jeremy Boynes wrote:
> 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.
>
I agree that business application logic should not use this context
information. Ideally, there would support for users to write simple
plugins that could run inside the call context as aspects (in the AOP
sense). Only the aspects would access the context, and these would
cross cut but supplement the application code. This is useful not only
for routing but for security, version management, compression, context
propagation, HA and load balancing strategies, pay per use billing, and
so on.
This would allow a middle ground between applications components that
shouldn't use this, and "being managed totally by the framework", which
is a less flexible way to manage such information...PC
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
