On Sep 13, 2006, at 4:48 AM, Peter Cousins wrote:
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
[[ rolling in the audit use case as well ]]
Yes - I see a lot of similarity to aspects in the AOP sense, the
important thing is how we define the pointcuts in the global sense
and how the information from the activation is passed into the
advice. I think programming an aspect this close to the join tends to
involve a different set of skills from programming a normal
application component and so the programming model should be
different. The trick is to be able to map the "advise" programming
model back into a normal "component" programming model so that it
becomes easier for people to write their own implementations of the
things you mention above. I think this is where things like framework
interceptors, message handlers etc. break down - their information
model is based on the interaction rather than on the data in the
interaction that the programmer is actually trying to use.
So far we have focused on the programming model for traditional
application components - the things providing the business
application logic - with the goal of abstracting away from them the
details of the lower-level infrastructure. We've wanted to let people
write applications in the language/programming model/data format of
their choice (Java, Spring, JavaScript, Ruby, and eventually XSLT,
BPEL etc.; SDO, JAXB, JSON, AXIOM etc.) based on suitability for the
business problem they are trying to solve. We have tried to maintain
an isolation between this kind of application code and lower-level
infrastructure concerns that will enable us to reuse/migrate/rewire
these components as part of assembly.
This programming model is based on IoC principles, a key one being
that components clearly declare their dependencies. For application
code we want to express those dependencies in terms of "business"
level artifacts - orders, customers and the services that act on them
rather than plumbing. But that's just one domain. If you move down
the stack, I believe the same programming model can work with
"infrastructure" domain artifacts such as messages, principals, xids
and so forth.
I also think there's a level between these for "business application
infrastructure" - things like audit (compliance), authorization, QoS,
chargebacks and so on. A programmer there is aware of business
concerns and wants to deal in those terms rather than the real low-
level things. For example, routing based on customer rather than
source IP address. The IoC principles still apply, just the data
types are different.
My hope therefore is that we can reuse the SCA programming models for
implementing these "aspects" - the same models, just with the service
contract and data types mapped to the appropriate constructs. For
this to work we would need to extend the SCA assembly model to
support a pointcut language that allowed users to specify the rules
for attaching these behaviours to the wires.
With that in place it becomes the runtime's job to attach the
appropriate hooks to the wiring and convert the raw data on the wire
(from as low a level as necessary) into the data expected by the
aspect implementation (in a similar way to how we convert data to the
format expected by an application component). Perhaps not an easy
job, but an interesting one :-) At least, that's one of the things
that interests me (he says, going back to being build monkey).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
