ApachCon Europe06 - Apache Tuscany
So I went to ApacheCon in Dublin this week (I'll put a proper write-up soon). But one of the talks I went to was Apache Tuscany: which is a runtime implementation of the Service Component Architecture SCA spec. The SCA spec (currently 0.9) is a specification of how to assemble together a number of components Java, Web Services, C++ into an overall service. Now there are things I like about the SCA specification:
- It's provides an Inversion-of-control pattern for the creation of services in languages such as Java using annotations. OK if this was it, we don't need it, we have Spring.
- It's language-neutral.
- It provides a mechanism of assembling components and these components can be Web Services. We need this at the moment we have a standard way of describing single web services (WSDL), but in integration projects you never see just one Web Service (that would be the integration part). So from a tooling perspective, being able to describe collections of web-services, wire them together and get the tooling to sort out the endpoints dependencies and parameterization is a good idea.
- It mandates that all remote connections between components must be defined in WSDL.
- It's just an XML vocabulary. It doesn't mandate runtimes or specific constraints.
- You can specify WS-I and WS-Security Basic Profile nicely.
- It allows components to be wired together from any language - directly. Is this going to work very well? Well okay maybe for scripting languages running on a VM and for the exchange of simple structures and types it's okay. We already have an language for interchanging information between languages/platforms and systems. It's called XML. But if the components are going to be wired together then each of these components operations and parameters must be describable in each of the components languages. We have a standard for this too - it's called WSDL. But SCA doesn't define it like this. There's some sort of magic language-to-language binding to be done for wiring components together. I say magic, cos the spec doesn't say anything about it - presumably Apache Tuscany is working this out.
- It has nothing to say about deployment. For a language which is being aimed at tools (see STP project in Eclipse) this is a bit weird. I may want to design a new SOA system as an assembly of connected Web Services at design time and then deploy them to one server, or multiple servers. But SCA has nothing to say about this - yet.
- The SCA specification is not open. You cannot see the current draft and meeting minutes are not open. But Apache is implementing it and presumably getting some kind of priority access given that some of it's contributors companies are members of the specification body.
Once you have such an assembly description things like monitoring, management and reporting also become much more coherent.
So what was the Apache Tuscany talk like. Well given that I, on balance, like the SCA spec, the talk was a bit of a let down. It provided no real information apart from a status report. Okay, fair enough, a lot of the talk was about SCA (cos most people haven't heard of SCA and it requires quite a bit of explanation). But there was no real information about how the runtime was constructed, how the interlanguage mapping is happening, or whether there are issues in the protocol bindings.
Also Apache Tuscany is not the reference implementation of SCA. Let me just say that again. It is not the reference implementation. There is no reference implementation. Haven't we learnt yet. No spec without at least one reference implementation and preferably 3 or 4. Because there's no reference implementation there's no plans for a verification kit. Worrying. Well not to me, I'm not interested in a runtime, I'm interested in using it as an assembly format for web services; but if I was a vendor planning a runtime I would be.
posted by Fergal @ 10:50 PM
4 comments
4 Comments:
Fergal,
Thanks for a thoughtful piece on Tuscany and on SCA. I'm one of the guys working on the SCA spec, so I'm mostly going to talk about that.
First some words about how the SCA spec is being evolved. The SCA spec is currently being evolved by a group of collaborating companies. It's being done this way now in order that we can make rapid progress on evolving the spec, ahead of submitting an initial "1.0" version of the spec to a standards body.
We in the SCA collaboration are concerned about the current lack of visibility of drafts of the specifications - since we want to get feedback from right across the community. We are working towards a more open way of working - watch from some developments in this area in the near future.
You're right in saying that the current spec says little about deployment. This is an acknowledged hole in the 0.9 spec - and work is going on in the collaboration to address this. The challenge is that SCA describes a distributed system, where components can run in different kinds of environment - we need a deployment scheme that is simple yet flexible enough to deal with different component kinds and different runtime environments. We also need to handle systems that at one end of the spectrum use a simple filesystem to hold artifacts but in more complex cases use some form of repository.
Regarding one of your dislikes of SCA - its ability to describe the "direct wiring" of components. This is one of the areas of flexibility within SCA. First, I should point out that any remotable interface in SCA (one that could be called from some other system other than the one where the service implementation lives) must be "translatable" into WSDL (the rules for this depend on the interface language chosen) - SCA does not force the use of WSDL as an interface definition language, but it does use WSDL as the touchstone for services that can be accessed remotely.
This, for example, allows Java programmers to still use Java interfaces - which is a natural thing to do for Java programmers. However, it does impose discipline in that Java-isms in interfaces are discouraged.
On the other hand, where two components are written using the same technology and run on the same system, SCA does not force the conversion of the service invocation into XML - and it allows the use of "native" interface definitions such as Java interfaces - reducing the burden on programmers.
Where components of different technologies are linked - the interfaces can be matched via mutual conversion to WSDL. If the service involved is remotable, then compatibility is guaranteed since they must both be convertible to WSDL. Where the services are local, then this is not necessarily going to result in compatibility - but then again, local interfaces imply that the client and implementation must be running in the same runtime.
Either way, the SCA spec is formulated in a way that gives the runtime(s) the flexibility to optimise service interactions, while describing them at a sufficiently abstract level to accommodate many different forms of interaction. SCA is good for Web services, but is not tied to SOAP, or to HTTP or even to XML for the message formats - other formats can be modelled by SCA where useful.
For SCA, integration is the key - and integration works best when it can deal with existing implementations as well as new ones.
Yours, Mike Edwards.
Hi Mike,
It's good that SCA is going to emerge into a more open process. I think this will really help.
I like the mandating of WSDL (okay translatable to WSDL) for remote interfaces. I also don't have a problem with WSDL-Java or Java-Java "direct-connections". WSDL-Java we have many examples, eg. JAX-B/JAX-WS. Java-Java connections we have Spring. Having one assembly language that spans these is great.
What I am concerned/confused about is the Java-Javascript, Java-Perl, Javascript-Perl interlanguage direct connections. This is something which isn't explained in the 0.9 spec. My point was that, to avoid an explosion in conversion rules between languages, it may be that you need to define such components in WSDL as well. You mention that interfaces between such components must be "translatable" to WSDL. Perhaps this is the same thing and will be clarified in the 1.0 specification.
Fergal,
Regarding interfaces between components of different kinds, there is as usual a conflict going on.
It is certainly true that for any components in any language, that if they are going to offer remotable services the interface offered must map to WSDL.
That should not mean that the interface must be written down in WSDL - frankly, for the average programmer, WSDL is about as friendly as a cornered rat (a comment that no doubt will cause a few rocks to be thrown at me!). Far better to have the programmer working with an interface definition with which they are familiar and comfortable.
The interesting question arises for local interfaces. SCA does not require that local interfaces be mappable to WSDL - this originates with the idea that you may have components within one runtime process communicating via an interface that is "in their own language" - like 2 Java classes with a Java interface defining their communication. SCA doesn't want to prevent this way of structuring things.
Once you allow this, then allowing local interfaces between 2 components written in different technologies (eg Javascript & Java...) is a natural extension. Clearly this requires that there is a runtime which can deal with both technologies in one process (otherwise it ain't "local"!). In this case, there is probably some existing description of how one technology calls the other technology - not defined by SCA but defined by the runtime involved. SCA does not want to prevent this kind of structure - but neither can it guarantee any kind of portability, since the function depends heavily on the capabilities of the runtime.
It's a case where if you want to provide some flexibility and encompass a wide range of technologies, you have to sacrifice some rigor. The SCA spec probably requires some additional words to help explain this better.
Yours, Mike.
a question of priorities
I cant see why it is a priority for SCA to address an assembly model for fine-grained components like this.
In an ideal world we would have one assembly model to rule them all - but since there are plenty of assembly models at a fine-grained component level I would have thought that the SCA implementation should focus on delivering a usable assembly model for coarse-grained services. As Fergal has said this is where we have a need today. It is entirely possible for us to address this need first and then to address the assembly of components.
As software vendors we practise incremental development - can we not apply this to standards development?
Post a Comment
<< Home