Don Box makes a good point about JBI versus EJB containers, which is essentially: why another container in J2EE; isn't the application server sufficient? As Steve points out, however, and I agree with, we shouldn't be looking at this as yet another container, but rather as a way of facilitating a micro-container architecture (cf micro-kernel). In fact, back when there was an HP middleware division we tried to standardise on an approach that had been used successfully by the HP-AS guys to achieve this. There was even an attempt to standardise this with JSR 111, led by my friend and co-author Jon Maron.
But I think Don still has a point: until there's a standardised approach to this, some formal way of describing these different containers as aspects of the same core infrastructure, it's just one approach that some vendors may take, whereas others may re-invent the wheel and impose different interaction patterns on users, resulting in the JBI container as a truly different beast to an EJB container. Maybe it's time to revisit the CSF?
I work for Red Hat, where I lead JBoss technical direction and research/development. Prior to this I was SOA Technical Development Manager and Director of Standards. I was Chief Architect and co-founder at Arjuna Technologies, an HP spin-off (where I was a Distinguished Engineer). I've been working in the area of reliable distributed systems since the mid-80's. My PhD was on fault-tolerant distributed systems, replication and transactions. I'm also a Professor at Newcastle University and Lyon.
Sunday, July 10, 2005
Thursday, July 07, 2005
San Francisco restaurant recommendation
While having our WS-CAF face-to-face during JavaOne, we had the usual TC dinner. This time, on a recommendation from one of Eric's colleagues, we went to Yabbies, a seafood restaurant. I have to say that it was very good and I'd certainly like to repeat the experience. Though next time I'd probably go for the special that Greg and Eric shared. So if you're in the area I'd definitely recommend it for at least one visit!
Wednesday, July 06, 2005
WWW2006 Call for Papers
In case you missed it, the Call for Papers for WWW2006 is out. Now I need to decide whether I want the overhead of submitting something as well as reviewing!
SOAP discussion continues
The discussion about SOAP performance has moved to here and I feel like I should interject again. And once again it's a case of agreeing with both sides up to a point.
I'd like to consider myself one of those distributed system's experts that Michi mentions, given that I've been building them in various flavours since the mid 1980's. With that in mind, I have to agree with Michi that as far as distributed systems go, SOAP and Web Services are poor. Ignoring other problems such as the fact that there's still a lack of an overall architecture and concentrating solely on performance, then it's no contest. Having to resort to hardware to improve performance is the best answer that a poor implementation can achieve and it's certainly not something to be lauded (and I'm fairly sure that's not what Savas is trying to do). Sun tried that many years ago with Java (anyone else remember the JavaStation ?) If I were building a distributed application and I controlled the entire infrastructure, or simply didn't have to worry about interacting with heterogeneous technologies, then I'd consider CORBA or maybe even ICE (I still haven't had time to try this yet Michi). SOAP (and probably even XML for anything other than configuration) wouldn't factor into my choices in this case.
However, as I've said before, if I need to worry about interoperability with other organisations, or even just between departments in large organisations, then I'd have second thoughts. It's certainly true to say that I'd prefer to use something like CORBA if I had my way (though even that has its deficiences compared to some of the stuff we did back in the 1980's). Unfortunately there are commercial realities that hit home pretty quick if you try to do this and SOAP is the only choice these days. Arguing against that is like trying to persuade the sea to stay put. SOAP (and Web Services) are for interoperability as well as for the Web and there is so much backing for this from the industry that it's getting easier and easier to achieve. Interoperability isn't something that's only recently come on the scene and trying to achieve it with technologies such as CORBA was always possible, but more difficult than it probably needed to be. However, being one of those distributed system experts doesn't mean that I have to like this current state of affairs, and it's been the subject of many good discussions I've had with the likes of Savas and Jim over the years. But pragmatic realities can't be shaken off.
Fortunately I'm certain that Web Services and SOAP are going have to improve: though how long it will take is something I'm not willing to take a stab at. A good analogy comes if you consider natural languages for instance. There may well be an argument that English isn't the best global language and perhaps something like French or German would be a better choice. For example, I've heard arguments that English isn't structured enough and has many illogical rules that make teaching it as a foreign language difficult. There are people who want to change, but that's another battle that can't be won. Due to historical events, English has become the language of commerce and a fairly global language too. However, what we speak today isn't the same as was spoken in the tenth century or even the eighteen century: it has evolved to take into account the changing needs of society (e.g., slang). This is how I see SOAP (and Web Services) evolving too. OK, it would be great if we could all agree now to adopt something that is more efficient and has a better architecture, but that isn't going to happen. But I do believe things will evolve and improve. Let's hope it doesn't take a couple of centuries though.
There's a separate discussion about RPC versus messaging, but that is irrespective of the underlying distributed system technology. We've had the same discussions in CORBA (e.g., this) , J2EE and other technologies going back as far as I can remember. This current discussion arose purely around the area of SOAP performance and I feel that it's starting to drift into other things.
In summary then: guys - you're not arguing about the same thing. I think that we can all agree that the performance of SOAP is poor compared to other platforms (and that there are a number of other problems with it). Pointing that out is fair enough and definitely shouldn't be ignored (how else does our industry progress than by peer review in one form or another?) If people were saying that SOAP should be static and not evolve and improve, then I think it would be incumbent on us all to point out the problems as much as we could. I don't think any of the discussions I've seen so far have implied that this is the case. But it isn't worth arguing that X has better performance than Y if X is meant for one problem domain and Y is meant for another; sometimes performance really is secondary for many customers.
I also don't think that this is a case of smart people defending bad ideas. I think it certainly would be if those smart people believed that the status quo was good enough. However, I didn't read that into Jim's original post.
I'd like to consider myself one of those distributed system's experts that Michi mentions, given that I've been building them in various flavours since the mid 1980's. With that in mind, I have to agree with Michi that as far as distributed systems go, SOAP and Web Services are poor. Ignoring other problems such as the fact that there's still a lack of an overall architecture and concentrating solely on performance, then it's no contest. Having to resort to hardware to improve performance is the best answer that a poor implementation can achieve and it's certainly not something to be lauded (and I'm fairly sure that's not what Savas is trying to do). Sun tried that many years ago with Java (anyone else remember the JavaStation ?) If I were building a distributed application and I controlled the entire infrastructure, or simply didn't have to worry about interacting with heterogeneous technologies, then I'd consider CORBA or maybe even ICE (I still haven't had time to try this yet Michi). SOAP (and probably even XML for anything other than configuration) wouldn't factor into my choices in this case.
However, as I've said before, if I need to worry about interoperability with other organisations, or even just between departments in large organisations, then I'd have second thoughts. It's certainly true to say that I'd prefer to use something like CORBA if I had my way (though even that has its deficiences compared to some of the stuff we did back in the 1980's). Unfortunately there are commercial realities that hit home pretty quick if you try to do this and SOAP is the only choice these days. Arguing against that is like trying to persuade the sea to stay put. SOAP (and Web Services) are for interoperability as well as for the Web and there is so much backing for this from the industry that it's getting easier and easier to achieve. Interoperability isn't something that's only recently come on the scene and trying to achieve it with technologies such as CORBA was always possible, but more difficult than it probably needed to be. However, being one of those distributed system experts doesn't mean that I have to like this current state of affairs, and it's been the subject of many good discussions I've had with the likes of Savas and Jim over the years. But pragmatic realities can't be shaken off.
Fortunately I'm certain that Web Services and SOAP are going have to improve: though how long it will take is something I'm not willing to take a stab at. A good analogy comes if you consider natural languages for instance. There may well be an argument that English isn't the best global language and perhaps something like French or German would be a better choice. For example, I've heard arguments that English isn't structured enough and has many illogical rules that make teaching it as a foreign language difficult. There are people who want to change, but that's another battle that can't be won. Due to historical events, English has become the language of commerce and a fairly global language too. However, what we speak today isn't the same as was spoken in the tenth century or even the eighteen century: it has evolved to take into account the changing needs of society (e.g., slang). This is how I see SOAP (and Web Services) evolving too. OK, it would be great if we could all agree now to adopt something that is more efficient and has a better architecture, but that isn't going to happen. But I do believe things will evolve and improve. Let's hope it doesn't take a couple of centuries though.
There's a separate discussion about RPC versus messaging, but that is irrespective of the underlying distributed system technology. We've had the same discussions in CORBA (e.g., this) , J2EE and other technologies going back as far as I can remember. This current discussion arose purely around the area of SOAP performance and I feel that it's starting to drift into other things.
In summary then: guys - you're not arguing about the same thing. I think that we can all agree that the performance of SOAP is poor compared to other platforms (and that there are a number of other problems with it). Pointing that out is fair enough and definitely shouldn't be ignored (how else does our industry progress than by peer review in one form or another?) If people were saying that SOAP should be static and not evolve and improve, then I think it would be incumbent on us all to point out the problems as much as we could. I don't think any of the discussions I've seen so far have implied that this is the case. But it isn't worth arguing that X has better performance than Y if X is meant for one problem domain and Y is meant for another; sometimes performance really is secondary for many customers.
I also don't think that this is a case of smart people defending bad ideas. I think it certainly would be if those smart people believed that the status quo was good enough. However, I didn't read that into Jim's original post.
Saturday, July 02, 2005
JavaOne WS-CAF face-to-face
We've just finished our WS-CAF face-to-face meeting. It was hosted by Oracle and arranged to coincide with JavaOne so we could maximise attendance. In the end we had a majority of the TC turn up in person and several dialed in to the conference call.
We made good progress on WS-Context and WS-CF, progressing the former to a second Public Review Draft and the latter is almost ready for it's first Public Review draft. Since the Dublin face-to-face meeting at the end of last year, we've spent most of our time working on WS-CF, and now only consistency of the WSDL and schema remain. With any luck that shouldn't take more than a few days and then, assuming the TC agrees, we can move this towards it's Public Review Draft.
Public Review is one step away from standarisation, so I'm very pleased with the way things have gone so far. The power of any specification really comes when it's standardised and adopted by others, either in product or in other specifications/standards that are themselves ultimately adopted into product. We've seen a lot of interest in WS-Context over the past year or so and I think this is reflected in what the other members of the TC have seen as well.
The rest of the time in the meeting was spent going over the WS-ACID specification. This is a really important step towards completing the entire composite application framework and in particular for addressing the critical issue of reliability in Web Services business flows. Since WS-ACID is based on traditional transaction processing concepts such as two-phase commit and synchronizations there wasn't much to discuss in terms of the actual model. The likes of Sun, Oracle, IONA and ourselves all have sufficient experience in this area to know that what we currently have in the specification looks about right.
The issues that did arise included:
(i) if and how we might define some policies for services to identify themselves as being transaction aware. The lack of a standard in the area of policy makes this difficult, but Greg has written a document on this, so hopefully we can still make progress.
(ii) if and how we might define some isolation policies for participants/resource managers. The often talked about isolation policy for ACID transactions is serializability (essentially a concurrent execution of transactions is made to appear as though those transactions executed in some serial manner). However, other approaches do exist, including read-committed and read-uncommitted. Other specifications don't say anything about different isolation levels, so there was a discussion about whether or not it is needed here. We decided that it was a feature worth looking at supporting using policies, so we'll see where this leads us.
(iii) supporting transaction enlistment inflow: rather than an importing domain (one which received a transactional request) registering participants directly with a remote coordinator immediately, information about the participants (their EPRs) are sent back in the context associated with the response and the receiver does the registration. This is an optimisation, but it may save several upcalls, particularly if the coordinator is co-located with the requester.
(iv) shared and unshared transaction support for asynchronous transactions. In a shared transaction model, clients and servers share an end-to-end transaction: when a client invokes an operation on a service and does so in the scope of a transaction, that service may enlist participants in the same transaction the client started. The unshared model is used in store and forward transports (e.g., message queues). In this model, the communication between client and server is broken into separate requests, separated by (typically reliable) transmission between routers. In this model, multiple shared transactions are used where each is executed to completion before the next one begins. There was a lot of good discussion around this and we're going to see if there is something we can do in this space. It took us a long time to address the topic in the OTS so I'm not expecting a rapid resolution.
Overall we had a great meeting and the specifications look in a good state. In many ways it was very laid back, but I suppose that's California for you!
We made good progress on WS-Context and WS-CF, progressing the former to a second Public Review Draft and the latter is almost ready for it's first Public Review draft. Since the Dublin face-to-face meeting at the end of last year, we've spent most of our time working on WS-CF, and now only consistency of the WSDL and schema remain. With any luck that shouldn't take more than a few days and then, assuming the TC agrees, we can move this towards it's Public Review Draft.
Public Review is one step away from standarisation, so I'm very pleased with the way things have gone so far. The power of any specification really comes when it's standardised and adopted by others, either in product or in other specifications/standards that are themselves ultimately adopted into product. We've seen a lot of interest in WS-Context over the past year or so and I think this is reflected in what the other members of the TC have seen as well.
The rest of the time in the meeting was spent going over the WS-ACID specification. This is a really important step towards completing the entire composite application framework and in particular for addressing the critical issue of reliability in Web Services business flows. Since WS-ACID is based on traditional transaction processing concepts such as two-phase commit and synchronizations there wasn't much to discuss in terms of the actual model. The likes of Sun, Oracle, IONA and ourselves all have sufficient experience in this area to know that what we currently have in the specification looks about right.
The issues that did arise included:
(i) if and how we might define some policies for services to identify themselves as being transaction aware. The lack of a standard in the area of policy makes this difficult, but Greg has written a document on this, so hopefully we can still make progress.
(ii) if and how we might define some isolation policies for participants/resource managers. The often talked about isolation policy for ACID transactions is serializability (essentially a concurrent execution of transactions is made to appear as though those transactions executed in some serial manner). However, other approaches do exist, including read-committed and read-uncommitted. Other specifications don't say anything about different isolation levels, so there was a discussion about whether or not it is needed here. We decided that it was a feature worth looking at supporting using policies, so we'll see where this leads us.
(iii) supporting transaction enlistment inflow: rather than an importing domain (one which received a transactional request) registering participants directly with a remote coordinator immediately, information about the participants (their EPRs) are sent back in the context associated with the response and the receiver does the registration. This is an optimisation, but it may save several upcalls, particularly if the coordinator is co-located with the requester.
(iv) shared and unshared transaction support for asynchronous transactions. In a shared transaction model, clients and servers share an end-to-end transaction: when a client invokes an operation on a service and does so in the scope of a transaction, that service may enlist participants in the same transaction the client started. The unshared model is used in store and forward transports (e.g., message queues). In this model, the communication between client and server is broken into separate requests, separated by (typically reliable) transmission between routers. In this model, multiple shared transactions are used where each is executed to completion before the next one begins. There was a lot of good discussion around this and we're going to see if there is something we can do in this space. It took us a long time to address the topic in the OTS so I'm not expecting a rapid resolution.
Overall we had a great meeting and the specifications look in a good state. In many ways it was very laid back, but I suppose that's California for you!