Paul, Great to hear from you! Some thoughts inline.
Paul Fremantle wrote:
I recently read Dan's blog entry on the SCA assembly model: http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ That and some other discussions I've had made me think about maybe offering the SCA assembly model to configure Synapse. So it seems to me that you can draw a direct correlation between: Synapse Proxy and SCA Service Synapse Endpoint and SCA reference Synapse Mediator - a specific type of SCA Component Synapse Property - SCA Property
It certainly looks like a reasonable mapping.
If we were to make the XMLConfigurationBuilder pluggable then we could just use this as an alternative configuration language. We did talk about this in the beginning of Synapse [we discussed having a LEX/YACC style config language - which I would still LOVE if someone wants to do that - it would make a great Computer Science project] Anyway back to SCA, it seems to me that this would be a pretty nice alternative config model, using an independent third party language. I'm guessing that there is plenty of Tuscany code could help us implement this. Maybe we might do it jointly? So I'm imagining the existing runtime being *exactly* the same as today, but being able to use a subset of the SCA Assembly model to configure it. Maybe some of the SCA wizards on tusc-dev can jump in and let me know if this is feasible?
SCA makes no assumption about the runtime at all - and the spec teams have always viewed the SCA model as being mappable to a whole range of runtimes, so this way of thinking about things is fine. Indeed, some of the work in the Eclipse tools project is done this way, where an SCA model is used to describe the solution in the tools and is then mapped to the configuration file format of a particular runtime. The runtime never sees the SCA metadata directly.
Your idea is to do this mapping at runtime - I happen to prefer that way of doing things.
One BIG question to ask is whether you want to support implementation artifacts with SCA annotations. SCA supports, for example, Java classes with annotations which configure them with a range of features - this is an alternative to providing the information in the SCA XML format. Doing this requires appropriate introspector code in the runtime. This can certainly come from Tuscany.
Paul PS If someone is looking at http://www.infoq.com/news/2007/07/scaproblem and wondering where this is coming from I offer a few thoughts. Firstly, I'm always open to being proved wrong! Secondly, this would not be adding any layers of indirection... I'm mapping directly from SCA concepts into the Synapse runtime with this idea. Finally, I see nothing wrong with holding several inconsistent viewpoints at the same time :)
This direct mapping of SCA metadata into runtime entities is behind my contention that SCA does not add any layering. SCA is not about indirection, rather it is about having a consistent way of describing SOA configuration, which is mapped to the specifics of given component and runtime technologies. Only where it is the intention to extend the runtime(s) involved (eg with support for new bindings) would there need to be any consideration of layering - but then it is a question of how the runtime itself is written - the ideal is no layering, but a simple addition of function.
As for holding multiple inconsistent viewpoints at once - politicians seem to manage that as a way of life ;-)
Yours, Mike. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
