Wednesday, August 03, 2005
Blog vacation
I'm off to Canada tomorrow for a holiday. No blogging allowed I'm afraid. Back in 2 weeks.
Sunday, July 10, 2005
Yet another container architecture?
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?
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?
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!
Wednesday, June 29, 2005
Video game character
I tried What Video Game Character Are You? and here's the result:
Not sure I'd agree with all of that - I can't remember the last time I got lost inside a building ;-)
 I am a Gauntlet Adventurer.I strive to improve my living conditions by hoarding gold, food, and sometimes keys and potions. I love adventure, fighting, and particularly winning - especially when there's a prize at stake. I occasionally get lost inside buildings and can't find the exit. I need food badly. |
Not sure I'd agree with all of that - I can't remember the last time I got lost inside a building ;-)
Tuesday, June 28, 2005
Grid BOF at JavaOne
I'm here at JavaOne sitting on a panel for a BOF on the Grid; Building Tomorrow's Grid. Well that was last night (9:30pm, but it was surprisingly well attended, with standing room only) and I think it went very well. There was a lot of audience participation and it definitely seemed like there was a lot of interest in grid (small 'g') computing. Overall the panel pretty much agreed with one another; the main exception was when it came to the subject of Java's role in the grid (small 'g' again): the panel split down the middle, with Richard Nicholson and Dan Hushon saying the JINI is the way forward, whilst Greg and I disagreeing. As Greg pointed out, it's unrealistic to assume that the world will be purely Java, and the bridging/wrapping approach to embedding non-Java services into Jini seems like a hack if the real answer is to simply use the right tool (aka language) for the right job.
During our individual presentations at the start of the session, we were asked to answer the following questions and I think my answers were similar to those of the rest of the panel:
(i) What is grid computing? I made the distinction between grid (small 'g') and Grid/GRID computing. I think grid has been around for many years and people simply haven't collected all of these massively parallel and distributed applications under a single categorisation. Take a look at SETI@home for example. I remember installing this when it first came out back in the early 1990's. The statistics for it today are astonishing: 3 million computers, 14 Teraflops average, 500000 years of processing power in 18 months - the equivalent of several supercomputers. It's got to be one of the most successful grids around. GRID on the other hand, is IMO an effort to try to standardise on practices, patterns and infrastructure in building grids: a great idea when you consider the number of grid toolkits that are around.
(ii) What problem does it solve? Pretty simple - not many organisations can afford supercomputers, but there are a lot of massively parallel applications out there and many computers that simply aren't used most of the time. (One member of the audience came up to me afterwards and said that his company is thinking about building a grid to use the power of 14000 machines that they've got, which are idle 40% of the time.) Using someone elses resources to do your work seems like a good idea - it's cost effective for a start!
(iii) Where is it on the hype scale? grid (small 'g') has been around for many years and most certainly isn't hype. Compared to that, GRID is more hype than reality but that's just a timing thing.
Overall I think it was a great BOF and I was pleasantly surprised to see how many people turned out. Now it's off for a book signing and definitely some session tracks.
During our individual presentations at the start of the session, we were asked to answer the following questions and I think my answers were similar to those of the rest of the panel:
(i) What is grid computing? I made the distinction between grid (small 'g') and Grid/GRID computing. I think grid has been around for many years and people simply haven't collected all of these massively parallel and distributed applications under a single categorisation. Take a look at SETI@home for example. I remember installing this when it first came out back in the early 1990's. The statistics for it today are astonishing: 3 million computers, 14 Teraflops average, 500000 years of processing power in 18 months - the equivalent of several supercomputers. It's got to be one of the most successful grids around. GRID on the other hand, is IMO an effort to try to standardise on practices, patterns and infrastructure in building grids: a great idea when you consider the number of grid toolkits that are around.
(ii) What problem does it solve? Pretty simple - not many organisations can afford supercomputers, but there are a lot of massively parallel applications out there and many computers that simply aren't used most of the time. (One member of the audience came up to me afterwards and said that his company is thinking about building a grid to use the power of 14000 machines that they've got, which are idle 40% of the time.) Using someone elses resources to do your work seems like a good idea - it's cost effective for a start!
(iii) Where is it on the hype scale? grid (small 'g') has been around for many years and most certainly isn't hype. Compared to that, GRID is more hype than reality but that's just a timing thing.
Overall I think it was a great BOF and I was pleasantly surprised to see how many people turned out. Now it's off for a book signing and definitely some session tracks.
Friday, June 24, 2005
SOAP: slow or fast?
There's an interesting discussion going on here between Michi and Jim about the performance of SOAP. I wasn't going to get involved in what could easily become a "PC verus Mac, Unix versus Windows" debate, but I'll add my 2 cents worth.
I agree with them both, to a point.
I'm sure ICE is fast (I too haven't used it). I do know that CORBA implementations these days are very fast too and message service implementations (for example) like AMS are built for speed. When I started out doing my PhD back in the mid 1980's, my first task was to help write and improve Rajdoot, one of the first RPC mechanisms around. Even then, when a fast network was 10 mbps (if you were lucky) and we used Whitechapels or Sun 360's, we could regularly get round trips on 5ms for messages up to 1K in size (packet fragmentation/re-assembly happens above this, so this was the maximum critical packet size). Not fast by today's standards, but fast back then. Having been working with SOAP and Web Services for 5 years now, I know it's slow compared to what we had in 1986, so it simply doesn't compare to what's possible these days. So, I agree with Michi's point that on that (yes, we have tried compression over the years too, and got the same results as Michi - it works, but you've got to use it carefully.)
However, and this is where I also agree with Jim, SOAP performance can be improved. The sorts of things that go on under the covers today in terms of XML parsing, for example, are pretty inefficient. Next time you want to see, just pop up something like OptimizeIt and watch what happens. I'm pretty confident that developers can and will improve on this. As an analogy, back when IONA released the first version of Orbix it was the market leader but its performance was terrible compared to later revisions. (Opcodes were shipped as strings, for a start!) I'm not singling out IONA - this is a pattern that many other ORB providers followed. So, I agree with Jim: SOAP doesn't have to be this slow - it can be improved.
But this is where I stop agreeing and come back to the fact that it's beginning to sound like the "PC verus Mac, Unix versus Windows" debates of old. You're not comparing like with like.
This is definitely a case of using the right tool for the right job, combined with some unfortunate commercial realities. If you want interoperablity with other vendors (eventually pretty much any other vendor on the planet), then you'd go the SOAP route: there is no logical argument to the contrary. CORBA didn't get mass adoption, DCE failed before it, and despite Microsoft's power, so did DCOM. Eric has some interesting things to say on the subject here, but the reason SOAP works well is because of XML, HTTP (IMO) and pretty much universal adoption. I can't see that changing. In the forseeable future, I can't see the likes of Microsoft, IBM, Oracle, BEA etc. agreeing on a single protocol and infrastructure as they have with SOAP. To be honest, I think they were forced into the current situation because of the mass take-up of the original Web: they like vendor lock-in and had managed to maintain it for decades prior to Tim's arrival on the scene.
But you pay a heavy price for this kind of interoperability. There are inherent performance problems in SOAP that I just can't see going away. We may be able to chip at the surface and perhaps even make bit dents, but fundamentally I'm confident that SOAP performance versus something like ICE (or CORBA) will always be a one-sided contest. However, a contest of interoperability will be just as one-sided, with SOAP winning. From the moment I got into Web Services, I've said that I can't see it (and SOAP) replacing distributed environments like CORBA everywhere. It frustrates me at times when I see clients trying to do just that though and then complaining that the results aren't fast enough! If I want to go off-road, I'll buy a Land Rover; but if I want speed, give me a Ferrari any day! Distributed systems such as CORBA have been heavily optimised over the years and use binary encodings as much as possible - with the resultant impact on interoperability and performance. But that is fine. That's what they're intended for. Certainly if I was interested in high performance, I wouldn't be looking at SOAP or Web Services, but at CORBA (or something similar).
So in summary: of course there will be performance improvements for the SOAP infrastructure. There may even be a slow evolution to a pure binary, extremely efficient distributed invocation mechanism that looks similar to those systems that have gone before. But it's not strictly necessary and I don't see it happening as a priority. Use SOAP for interoperability. It lowers the integration barrier. But if you are really interested in performance and/or can impose a single solution on your corporate infrastructure, you may be better off looking elsewhere, to something like CORBA, or maybe even ICE.
I agree with them both, to a point.
I'm sure ICE is fast (I too haven't used it). I do know that CORBA implementations these days are very fast too and message service implementations (for example) like AMS are built for speed. When I started out doing my PhD back in the mid 1980's, my first task was to help write and improve Rajdoot, one of the first RPC mechanisms around. Even then, when a fast network was 10 mbps (if you were lucky) and we used Whitechapels or Sun 360's, we could regularly get round trips on 5ms for messages up to 1K in size (packet fragmentation/re-assembly happens above this, so this was the maximum critical packet size). Not fast by today's standards, but fast back then. Having been working with SOAP and Web Services for 5 years now, I know it's slow compared to what we had in 1986, so it simply doesn't compare to what's possible these days. So, I agree with Michi's point that on that (yes, we have tried compression over the years too, and got the same results as Michi - it works, but you've got to use it carefully.)
However, and this is where I also agree with Jim, SOAP performance can be improved. The sorts of things that go on under the covers today in terms of XML parsing, for example, are pretty inefficient. Next time you want to see, just pop up something like OptimizeIt and watch what happens. I'm pretty confident that developers can and will improve on this. As an analogy, back when IONA released the first version of Orbix it was the market leader but its performance was terrible compared to later revisions. (Opcodes were shipped as strings, for a start!) I'm not singling out IONA - this is a pattern that many other ORB providers followed. So, I agree with Jim: SOAP doesn't have to be this slow - it can be improved.
But this is where I stop agreeing and come back to the fact that it's beginning to sound like the "PC verus Mac, Unix versus Windows" debates of old. You're not comparing like with like.
This is definitely a case of using the right tool for the right job, combined with some unfortunate commercial realities. If you want interoperablity with other vendors (eventually pretty much any other vendor on the planet), then you'd go the SOAP route: there is no logical argument to the contrary. CORBA didn't get mass adoption, DCE failed before it, and despite Microsoft's power, so did DCOM. Eric has some interesting things to say on the subject here, but the reason SOAP works well is because of XML, HTTP (IMO) and pretty much universal adoption. I can't see that changing. In the forseeable future, I can't see the likes of Microsoft, IBM, Oracle, BEA etc. agreeing on a single protocol and infrastructure as they have with SOAP. To be honest, I think they were forced into the current situation because of the mass take-up of the original Web: they like vendor lock-in and had managed to maintain it for decades prior to Tim's arrival on the scene.
But you pay a heavy price for this kind of interoperability. There are inherent performance problems in SOAP that I just can't see going away. We may be able to chip at the surface and perhaps even make bit dents, but fundamentally I'm confident that SOAP performance versus something like ICE (or CORBA) will always be a one-sided contest. However, a contest of interoperability will be just as one-sided, with SOAP winning. From the moment I got into Web Services, I've said that I can't see it (and SOAP) replacing distributed environments like CORBA everywhere. It frustrates me at times when I see clients trying to do just that though and then complaining that the results aren't fast enough! If I want to go off-road, I'll buy a Land Rover; but if I want speed, give me a Ferrari any day! Distributed systems such as CORBA have been heavily optimised over the years and use binary encodings as much as possible - with the resultant impact on interoperability and performance. But that is fine. That's what they're intended for. Certainly if I was interested in high performance, I wouldn't be looking at SOAP or Web Services, but at CORBA (or something similar).
So in summary: of course there will be performance improvements for the SOAP infrastructure. There may even be a slow evolution to a pure binary, extremely efficient distributed invocation mechanism that looks similar to those systems that have gone before. But it's not strictly necessary and I don't see it happening as a priority. Use SOAP for interoperability. It lowers the integration barrier. But if you are really interested in performance and/or can impose a single solution on your corporate infrastructure, you may be better off looking elsewhere, to something like CORBA, or maybe even ICE.
Savas on the move
It's official now: Savas is on the move to Microsoft and Don Box's team. Savas and I have talked about his moving from Paul's group for quite a while, so it's fair to say that it's not a surprise. I'm doubly happy for him and sad - where do I find a coffee buddy now!
Savas and I have known each other for many years as friends and colleagues: while at HP, he was in my transactions team and was a star! I'm absolutely sure that Savas will make the most of this opportunity, and it's a good move for him and Microsoft. Though I still think the other job was just as good Savas ;-)
Anyway, good luck my friend and at the very least we'll be able to catch up at HPTS.
Savas and I have known each other for many years as friends and colleagues: while at HP, he was in my transactions team and was a star! I'm absolutely sure that Savas will make the most of this opportunity, and it's a good move for him and Microsoft. Though I still think the other job was just as good Savas ;-)
Anyway, good luck my friend and at the very least we'll be able to catch up at HPTS.
Wednesday, June 22, 2005
EPR rules of engagement
William, an ex-HP colleague, has some interesting things to say about EPRs and how people tackle them. I'm broadly in agreement with what he has to say; he even references our paper, which is nice. Unfortunately there are a couple of places where he's wrong:
(i) on the implication that WS-Coordination is the same as WS-Context. However, I think Greg has responded to that here (though since his blog seems down I can't check).
(ii) on the implication that this formal objection we've raised is somehow against EPRs and ReferenceParameters. It isn't (though that's not to say I don't believe the latter is inherently wrong, but that is a completely different issue). As I say here this is about keeping EPRs symmetrical. To summarise, the current state of affairs is that EPRs are encapsulated entities until you need to use them, and in what case their constituent elements (e.g., the endpoint URI, ReferenceParameters etc.) appear as first-class elements in the SOAP header). As the objection describes, this can lead to a number of problems and we believe it's worth fixing now rather than try to retro-fit something later.
Hopefully given the pitfalls that William's original blog entry describes, he'll agree that this change we're after only makes things better.
(i) on the implication that WS-Coordination is the same as WS-Context. However, I think Greg has responded to that here (though since his blog seems down I can't check).
(ii) on the implication that this formal objection we've raised is somehow against EPRs and ReferenceParameters. It isn't (though that's not to say I don't believe the latter is inherently wrong, but that is a completely different issue). As I say here this is about keeping EPRs symmetrical. To summarise, the current state of affairs is that EPRs are encapsulated entities until you need to use them, and in what case their constituent elements (e.g., the endpoint URI, ReferenceParameters etc.) appear as first-class elements in the SOAP header). As the objection describes, this can lead to a number of problems and we believe it's worth fixing now rather than try to retro-fit something later.
Hopefully given the pitfalls that William's original blog entry describes, he'll agree that this change we're after only makes things better.
Sunday, June 19, 2005
HPTS 2005
I submitted 3 papers to this year's High Performance Transaction Systems workshop and have been invited to attend. The bi-annual HPTS workshop is probably my favourite workshop/conference, so I'm pleased to be accepted for the fifth successive time. The papers aren't up on the web site yet, but in summary:
(i) a paper on WS-CAF that I co-authored with Eric and Greg.
(ii) a paper on ArjunaCore that I co-authored with Santosh.
(iii) a paper on the different conceptual models of Web Services transactions: does the one-size fits all approach really work and if not, why not.
Once the papers are on some web site, I'll update the blog.
(i) a paper on WS-CAF that I co-authored with Eric and Greg.
(ii) a paper on ArjunaCore that I co-authored with Santosh.
(iii) a paper on the different conceptual models of Web Services transactions: does the one-size fits all approach really work and if not, why not.
Once the papers are on some web site, I'll update the blog.
Tuesday, June 14, 2005
A musical interlude
At last year's WS-CAF f2f in New Orleans, Eric started to tell me about Professor Longhair and even gave me a few tracks to listen to. Wonderful music and it brings back good memories of New Orleans.
Thursday, June 02, 2005
End of the Grid TX road?
There's been an effort going on at the GGF for a while now into transaction management for Grid applications. The initial idea was to clearly define the requirements space for transactions in Grid (are they different from Web Services, for example), then to take an objective look at efforts that have been going on elsewhere (e.g., Web Services) and finally to say whether or not those efforts are suitable. Ultimately, if the existing work wasn't deemed suitable for Grid transactions, the group would define a/some new transaction protocol(s); I think this last bit was always potentially the work on something that would come after us, rather than for this group.
Well, we're finally coming to the end of the road on this phase of the work. It looks like in the next few weeks we'll have a good report on everything up to, and including, recommendations for any future effort in this space by the GGF. It doesn't look like we'll be defining any new protocol(s) afterall, but if the GGF decide that some are needed after reading the report, hopefully it will be useful input to the next phase.
Well, we're finally coming to the end of the road on this phase of the work. It looks like in the next few weeks we'll have a good report on everything up to, and including, recommendations for any future effort in this space by the GGF. It doesn't look like we'll be defining any new protocol(s) afterall, but if the GGF decide that some are needed after reading the report, hopefully it will be useful input to the next phase.
Chapter in MIT book on SOC
About 2 years ago I wrote a paper for a special issue of the CACM on Web Services and transactions. A little later, I was asked by the guest editors to write an extended version for an MIT Press book on service-oriented computing. It's taken a little longer than the editors or I expected, but finally it looks like the book is coming to fruition. I got some good feedback on the chapter (which tried to cover all of the efforts in this space in an objective manner) a few weeks ago and now need to finalise the work by the end of the month.
One thing this did bring to mind is precisely how long I've been working in this area (and transactions in general). Not sure if that's a good thing or a bad thing.
One thing this did bring to mind is precisely how long I've been working in this area (and transactions in general). Not sure if that's a good thing or a bad thing.
Sunday, May 29, 2005
XTECH 2005
I did a day trip to XTECH 2005, where I was presenting on WS-CAF. A very long, but interesting day.
I wasn't presenting until later in the day, so Edd asked me to chair one of the earlier sessions of the day. The presentations I chaired were "Adoption of UBL in Denmark - business cases and experiences" and "Implementing Web Services for Healthcare - Lessons & Pitfalls", which were both very interesting for similar reasons. Firstly, they both talked about the use of ebXML in the public sector (ebXML is a big effort, so if you want to know which aspects of it they're using, I'd encourage you to read the papers), and secondly, the key to their success was pretty much the same: legislation! In one case, any Netherlands company wanting to send invoices to the government has to do it electronically and were given 8 weeks to implement the necessary support within their organisation. I forget the actual figures at the moment, but the government did a "time and motion" study of invoicing and reckoned they could say $100 million annually by doing this. And it all seems to be working!
They were both extremely interesting presentations and the audience asked some good questions that helped to pull more information from the presenters. Overall, I think this time I probably found the chairing experience more interesting than presenting!
I wasn't presenting until later in the day, so Edd asked me to chair one of the earlier sessions of the day. The presentations I chaired were "Adoption of UBL in Denmark - business cases and experiences" and "Implementing Web Services for Healthcare - Lessons & Pitfalls", which were both very interesting for similar reasons. Firstly, they both talked about the use of ebXML in the public sector (ebXML is a big effort, so if you want to know which aspects of it they're using, I'd encourage you to read the papers), and secondly, the key to their success was pretty much the same: legislation! In one case, any Netherlands company wanting to send invoices to the government has to do it electronically and were given 8 weeks to implement the necessary support within their organisation. I forget the actual figures at the moment, but the government did a "time and motion" study of invoicing and reckoned they could say $100 million annually by doing this. And it all seems to be working!
They were both extremely interesting presentations and the audience asked some good questions that helped to pull more information from the presenters. Overall, I think this time I probably found the chairing experience more interesting than presenting!
Monday, May 16, 2005
WWW2006 update
We're in the process of finalising the PC for the XML & Web Services track of WWW2006. It's shaping up to be a good PC and I hope the quality of papers we get is good too. So, get your thinking hats on and start to write. Although the CFP hasn't gone out yet, and we'll be accepting papers on a wide range of XML & Web Service related topics, this year I'd like to see some papers on fault tolerance and reliability. That topic tends to get overlooked a lot in the early days of any distributed architecture "wave", but I think we're reaching the crest of this wave and things need to change.
Friday, May 13, 2005
Asymmetrical WS-Addressing
I have to admit that I like symmetry for a number of reasons. Nature prefers symmetry in a wide range of areas and it shows up all around us. So, symmetry is good. I know it's not a hard-and-fast rule, but we've followed nature before and I reckon it still has a lot to teach us. And more pragmatically, symmetry just makes sense. To paraphrase Occam's Razor: the simplest solution is probably the right one. So, why make things more complex than they need to be?
So how does this relate to WS-Addressing? Well ever since I started to use it when the Web Services Coordination and Transaction specifications, I've been annoyed by the fact that not everything is a WS-Addr End Point Reference (EPR). Basically in WS-Addr, an EPR is a delivery address for your message and contains the URI of the service as well as other information needed to ultimately deliver that message.
When sending a message, you can define wsa:ReplyTo, wsa:FaultTo and wsa:From all as EPRs. But the actual destination address isn't an EPR! Or more accurately, it's a broken apart EPR: as a receiver, you may have got it in a wsa:ReplyTo, but if you then want to us it to send a response, you have to do some work with it first.
For example, here's a valid wsa header for an input message:
Now in a symmetrical world, I should simply be able to take the wsa:ReplyTo EPR and put it (renamed as wsa:To of course) into the SOAP header of the response message like so:
But no, I can't do that. I have to take everything out of the wsa:ReplyTo and essentially promote the contents to the root, like so:
And as you can see, it's not actually as simple as that - I've got to break apart the ReferenceParameters (which could be arbitrary in size). Why can't I just use the EPR I received as an EPR? It can't be because of deficiencies in the SOAP processing model and I don't see how it adds anything to the architecture/model (if anything it detracts from it).
In short: It does not make sense!
So how does this relate to WS-Addressing? Well ever since I started to use it when the Web Services Coordination and Transaction specifications, I've been annoyed by the fact that not everything is a WS-Addr End Point Reference (EPR). Basically in WS-Addr, an EPR is a delivery address for your message and contains the URI of the service as well as other information needed to ultimately deliver that message.
When sending a message, you can define wsa:ReplyTo, wsa:FaultTo and wsa:From all as EPRs. But the actual destination address isn't an EPR! Or more accurately, it's a broken apart EPR: as a receiver, you may have got it in a wsa:ReplyTo, but if you then want to us it to send a response, you have to do some work with it first.
For example, here's a valid wsa header for an input message:
<S:Header>
<wsa:MessageID>http://example.com/someuniquestring
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
<wsa:ReferenceParameters>
<foo:dest objid=urn:1234:5678/>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
<wsa:To S:mustUnderstand="1">
mailto:fabrikam@example.com</wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/Delete
</wsa:Action>
</S:Header>
Now in a symmetrical world, I should simply be able to take the wsa:ReplyTo EPR and put it (renamed as wsa:To of course) into the SOAP header of the response message like so:
<S:Header>
<wsa:To>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
<wsa:ReferenceParameters>
<foo:dest objid=urn:1234:5678/>
</wsa:ReferenceParameters>
</wsa:To>
</S:Header>
But no, I can't do that. I have to take everything out of the wsa:ReplyTo and essentially promote the contents to the root, like so:
<S:Header>
<wsa:To>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
</wsa:To>
<foo:dest objid=urn:1234:5678/>
</S:Header>
And as you can see, it's not actually as simple as that - I've got to break apart the ReferenceParameters (which could be arbitrary in size). Why can't I just use the EPR I received as an EPR? It can't be because of deficiencies in the SOAP processing model and I don't see how it adds anything to the architecture/model (if anything it detracts from it).
In short: It does not make sense!
Saturday, May 07, 2005
java.net blog
I've had a blog on java.net for a while, but have found very little time to put something together for a first post. A conversation I had with Greg the other day around the importance of WS-RX and WS-Context got me thinking and I thought I'd write something about WS-Context for the readers of java.net.
Thursday, May 05, 2005
Some more history
Just a couple of links to some things of historial interest to other ex-HP/Bluestoners out there.
Subscribe to:
Posts (Atom)