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.
  

Now here are the things I don't particularly like:

• 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.
  

That all said. If they dropped (or clarified) the component-to-component integration model maybe things would look clearer. From my point of view I'm not really interested in direct component-to-component integration. The starting point for me of integration is web services and this means WSDL and XML. So when I read the SCA spec, I tend to ignore the running Javascript and Java whizzbang nature of the beast and think of it as an assembly language for Web Services described by WSDL. One which provides an inversion-of-control configuration capability for implementation (Java, BPEL etc) of Web Services. Now this I not only like. I need.
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.

Futurama's Back

Yippee! The rumours have finally been confirmed.
13 new episodes on bittorrent Comedy Central - no date yet. Leela's human-actor confirmed it on some show I've never heard of.

Stop the SOA 2.0 Madness

Thankfully someone has stood-up and decided it's time to call a halt to the "SOA 2.0" terminology with a petition. This noxious marketing term which was dreamed up by Oracle should not be tolerated. SOA is guilty of a lot of hype and hot air and this isn't helping.

You know what you should do.

Rise and Fall of CORBA

Saw this on Justin's links. I agree with pretty much all of it. It solved a technical problem early-on (basic connectivity between heterogeneous systems) and then did two things:

• Morphed into this appalling beast with numerous vertical committees and pointless horizontal specifications.
• Failed to address it's technical short-comings (IIOP, Firewalls, IDL).
  

Michi Henning goes on to layout some lessons:

• Have reference implementations.
• Have proven usage of reference implementations before standardisation in non-trivial problem domains.
  
• Have strong committees that don't allow frivolous specifications / features.
• Use open-source for reference implementations - it's a survival of the fittest arena for spec. features. It also provides transparency for the process.
  

The industry is kinda going this way anyway, to some degree in Javaland. There's room for improvement.
Is the same true of Web Services? There are certainly some uncomfortable parallels.

SOAP and WSDL solves a basic problem namely basic connectivity between heterogeneous system, but this time, it's firewall friendly (SMTP, HTTP as transport protocols), language neutral, not opaque (you can view XML on the wire) and extensible.

Then we have a raft of new specifications either already here or quickly will be:

• WS-Reliable Messaging - guaranteeing delivery over unreliable protocols (HTTP, SMTP, etc), sort of turning them into a JMS.
  
• WS-Security - encryption and signing of messages
• WS-AtomicTransaction - allowing multiple web-services to enroll in distributed transactions.
• WS-Context - allowing mulitple web-services to share context (conversation identifiers).
• WS-Trust - built on WS-Security, allowing exchange of credentials/security tokens from different domains.
• WS-BPEL - coordination of web-services for business processes.

All of these have been developed by a selection of companies coming together to agree a standard, most have then been donated to an organisation for standardisation, e.g. oasis-open. While most will have reference implementations being put forward by one or more of the owning organisations along with the first release of the specification, they have not been developed in an open-source manner (though they may be donated to an open-source project at some point), nor have they been proven in real-world domains.

Quite rightly people have criticised this whole WS-* effort as being overly-complex and part of the reason for this is the lack of community developer involvement in the creation and evolution of these specifications.