OSGi for the Enterprise – update

One of the great things about co-chairing the OSGi EEG is getting to work with guys like Adrian Colyer, who was interviewed on InfoQ recently about Spring-OSGi. This is a very interesting interview, especially if you are, like me, interested in understanding the proposed Spring-OSGi marriage better.
Adrian is a great guy and really sharp, and he is also a great contributor to the EEG – and he is by no means alone in that category by the way. We are really lucky to have a great EG, and fortunate to have Adrian’s help editing the Spring-OSGi Request for Proposal (RFP).
I do have a small issue with Adrian’s portrayal of Spring and OSGi, however, and I would guess he’s probably familiar with it from some of the things I’ve said during the meetings. Basically Adrian makes it sound like Spring and OSGi can (or will) do everything anyone needs.
As my colleague David Bosschaert says, this is a bit like saying you can do everything in Java, since it basically amounts to being about to develop a new application to do anything you want in any given programming language. Sure, the combination of Spring and OSGi is very powerful, and great stuff, but I hope it’s clear by now that we are all living in a heterogeneous world, and one in which interworking is essential.
Spring and OSGi is an important part, but just one part of the overall picture. One of the really big benefits of OSGi is that it’s capable of supporting multiple programming models.
I am sure that Adrian did not intend to imply otherwise, but I just wanted to highlight it, in no small part because the RFP I’m editing includes the requirements for interworking with existing and non-OSGi systems (which may of course also be non-Spring systems).
If you want to find out more about OSGi overall check the Website and consider attending the upcoming OSGi Community Event in Munich. Hope to see you there!
The next EEG meeting actually takes place the day after the community event (June 28), where I hope my co-chair Tim Diekmann and I will be able to send off for approval the majority of the RFPs we’ve all been working on.
In OSGi the Expert Groups first create requirements documents, then move to the design phase, then to the specification phase, and finally to the reference implementation and conformance test kit phase. So I am hoping we can close out the requirements phase soon, and start on the really fun design discussions!
We have recieved about 15 RFPs so far (some have been combined), including the Spring-OSGi RFP that Adrian edited and the external systems RFP David and I edited, and RFPs for mapping various parts of JEE to OSGi (such as naming, database access, RMI, etc.), SCA to OSGi mapping (mostly to be done by the SCA community we hope), a distributed registry, database access, how to run system developed components (i.e. parts of JEE) alongside application developed components. marshaling and classloading, Web application support for the enterprise, management, and “universal” or multilanguage OSGi.
Stay tuned!

Report on Workshop on Web of Services for Enterprise Computing

The report is finally out for the Workshop on Web of Services for Enterprise Computing.
First, my apologies for the delay in getting this out. I think it still probably could use some work, but hopefully it includes most of the good stuff that can out in the Workshop.
I’d also really like to thank, once again, everyone who participated. Speaking for myself, the Workshop was a really great experience and I learned a lot. It was a privilege to be in the same room with the folks who attended.
Now I’m going to go out on a bit of a limb here and say that there’s been a bit of a detente recently in the REST vs SOAP debates, because I’d like to think that the Workshop has played a role in that.
I am seeing a lot of former WS-* advocates starting to give REST its due, and a good number of the “RESTafarians” starting to acknowledge the fact that people are getting value out of WS-*.
Whether the Workshop has really had a hand in that or not, I am pleased to see the debate being conducted on a more reasonable and rational basis.
Of course someone can always prove me wrong about that But I truly think it’s important that the industry as a whole understands the pros and cons of each approach.

Response to Gregor on transactions

Update June 7: I realized after I published this that I forgot to thank Gregor for his kind words about IONA. As long as I’m at it I should also have added that it strikes me that Gregor is a “right tool for the job” kind of guy, too.
Gregor has posted a very interesting reply to part of my entry about his presentation on InfoQ.
I don’t see a place to post a comment on his blog so I will answer here.
I did read through the Starbucks piece before, probably a year or so ago, and it is a nice explanation of why transactions aren’t needed in some situations. I also realize it is just an analogy to illustrate a good point (i.e. don’t automatically think you need transactions, use them appropriately etc.). I am a “right tool for the job” type person so I completely agree with him on that.
But I started thinking about it again after watching the presentation and it struck me that it was a bit like suggesting that you would consider using transactions to run a crane or something. Transactions are designed to capture data about something in the real world, not to interact with the real world directly. So of course you wouldn’t use transactions to serve coffee.
Anyway, I think one of the reasons I reacted to it a bit differently when he brought it up in the presentation (which I still absolutely recommend watching) is that there’s been a lot of negative stuff about transactions lately – and this just as I’ve been finishing up about 5 years of work on the specifications for Web services transactions. I think transactions are being misrepresented as something evil for an SOA environment, which they are not.
I really hope I am not guilty of being too religious about this stuff just because I’ve been working on it for a long time But I really think that transactions should not be dismissed as inappropriate for SOA without first evaluating whether or not you need them, or would benefit from them. And to do that it’s necessary to understand what transactions were designed for, and how they should be used appropriately.
It is definitely interesting to see some of the alternatives being proposed. Mark Little and I proposed one ourselves in the WS-CAF work – one that supports the federation of different transation models, and is designed to support long running asynchronous environments like those in loosely coupled SOA and BPM types of deployments. As far as we could tell though no one seemed very interested in it, and we’ve just sort of let the spec sit there.
I find it hard to believe (in following one of the links Gregor posted) that eBay doesn’t use any transactions at all, but I haven’t had time to really read through everything yet. I can certainly believe they don’t use distributed transactions, but database transactions are pretty fast. Anyway, I will finish reading up on those things – thanks for the pointers. This comes at a good time because Phil and I are trying to finish up the second edition of Principles of Transaction Processing…
ps Gregor – the reason I didn’t meet you at this year’s Microsoft MVP Summit is that I could only attend the first day and a half…maybe next time!