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
