So, the WS-DM TC are happy with their Committee Draft document and are now trying to get it adopted as an OASIS specification. STOP. DON'T DO IT! MOVE SLOWLY AWAY FROM THAT DOCUMENT!
As I've just explained in our vote to OASIS, we're happy with TC CD status, but the unfortunately the specification has dependencies on non-finalised and proprietary specifications, including WS-N and WS-Addressing. What's worse is that WS-N uses a different version of WS-Addressing than the WSDM specs do!
It's premature to elevate the spec. to the level of OASIS international specification. In particular WS-Addressing is currently being worked on and looks like the final version when it finally emerges will be significantly different from its various antecedent proprietary versions and won't be available until after July 2005. In particular, already we've seen that ReferenceProperties has been removed from the current draft of WS-Addressing in W3C, so this will have an immediate affect on WSDM. So you'd download the specification to implement it and find that it's pretty much broken!
I think to adopt this as a standard will set a dangerous precedent for OASIS. Specifications that attain the OASIS international specification level ought to be stable and have a certain amount of rigor and interop testing.
Let's hope the voting members see sense and send this back to the TC to correct.
Monday, February 28, 2005
Wednesday, February 23, 2005
The shape of things to come
Several years ago REM released a great song called It's the end of the world as we know it. That song seems quite appropriate in some ways at the moment, because we're about to release a GA version of the Arjuna Transaction Service 4.0. As I've said before, I've been working on Arjuna since 1987 and have seen it morph quite a bit over the years. As this paper shows, its seen a lot of changes and most of those have reflected changes in middleware architectures. So it's appropriate and in line with previous changes, that ArjunaTS 4.0 merges our formerly stand-alone Web Services transactions product ArjunaXTS with what has always been called the Arjuna Transaction Service and included JTA and OTS functionality.
There are several reasons why we took the approach back in 2002 to have two separate products and I'll mention a couple. When we were working as part of HP Middleware on the world's first Web Services transactions product it was a separate entity from what was then known as the HP Transaction Service; it also seemed unlikely that people would want Web Services transactions bundles with a transaction manager that required a CORBA ORB, despite the fact that you wouldn't use the ORB if you were working purely in the Web Services arena.
That last point has, with the benefit of hindsight, proven wrong. Back in 2002, just before the finalisation of the end of the HP-Compaq merger, I wrote an internal document about what I called End-to-end Transactions. (Apparently Gartner calls them Multimodal Transactions these days.) It was a way of describing how Web Services transactions (and specifically the product we'd been working on for HP) could be used to glue together other transaction domains, from mobile phones to laptops to mainframes, and incorporating potentially different transaction models. Some of this went on to become the Business Process transaction model in WS-Transaction Management, but most of it got filed in the dark corners of my brain when we span out of HP. But the main concept was that Web Services transactions don't just start in the Web Services ether: they'll typically begin in some corporate intranet and span to other corporate internets, with Web Services as the glue.
Funnily enough, over the past couple of years we've seen precisely this kind of use case from the early adopters of ArjunaXTS. Many of them have been asking for this kind of capability: bridging between J2EE transactions and Web Services transactions and vice versa. As a result, because we had two separate products (and the glue to stick them together), these early adopters ended up taking them both, with the added maintenance, setup, management etc. costs that that implies. So, one product seemed like an obvious improvement. I see the bridging capability a little like Sauron's ring: "and in the darkness bind them".
There are several reasons why we took the approach back in 2002 to have two separate products and I'll mention a couple. When we were working as part of HP Middleware on the world's first Web Services transactions product it was a separate entity from what was then known as the HP Transaction Service; it also seemed unlikely that people would want Web Services transactions bundles with a transaction manager that required a CORBA ORB, despite the fact that you wouldn't use the ORB if you were working purely in the Web Services arena.
That last point has, with the benefit of hindsight, proven wrong. Back in 2002, just before the finalisation of the end of the HP-Compaq merger, I wrote an internal document about what I called End-to-end Transactions. (Apparently Gartner calls them Multimodal Transactions these days.) It was a way of describing how Web Services transactions (and specifically the product we'd been working on for HP) could be used to glue together other transaction domains, from mobile phones to laptops to mainframes, and incorporating potentially different transaction models. Some of this went on to become the Business Process transaction model in WS-Transaction Management, but most of it got filed in the dark corners of my brain when we span out of HP. But the main concept was that Web Services transactions don't just start in the Web Services ether: they'll typically begin in some corporate intranet and span to other corporate internets, with Web Services as the glue.
Funnily enough, over the past couple of years we've seen precisely this kind of use case from the early adopters of ArjunaXTS. Many of them have been asking for this kind of capability: bridging between J2EE transactions and Web Services transactions and vice versa. As a result, because we had two separate products (and the glue to stick them together), these early adopters ended up taking them both, with the added maintenance, setup, management etc. costs that that implies. So, one product seemed like an obvious improvement. I see the bridging capability a little like Sauron's ring: "and in the darkness bind them".
Time to learn a new language
It's been a while since I learnt a new progamming language. The last one was C#, but that was 3 years ago. I've been looking around for a while and the one that's grabbed my interest is Ruby. There've been some interesting things said about it over the past year or so and it seems to have become fairly stable now. Time to take a dive into it, I think.
Sunday, February 13, 2005
Web Services Coordination Framework on its way
Last week we had the second face-to-face WS-CAF meeting to concentrate pretty much soley on the Web Services Coordination Framework (WS-CF). The first was in Dublin last November, where we made some fairly significant modifications to the specification and in this meeting we went through the 76 issues, closing many of them down. Because WS-CF builds on WS-Context the core concept that we've developed is the activity group: such a group is created when a context of a specific type (e.g., a coordination context) is begun via the Context Service. Participants can then register with that group via the endpoint reference (EPR) that is embedded in the WS-CF augmented WS-Context structure.
Because WS-CF is meant to be a low-level, generic coordination infrastructure, there's not a lot we can do at this level in terms of specific coordination protocol, i.e., coordinator-to-participant and participant-to-coordinator interactions. (Actually, we did a lot more in our initial submission to OASIS than we do now, but the TC has decided to remove some of that stuff and punt it to the higher level users/specifications.) So, apart from adding and removing participants, and handling recovery (yes, believe it or not, things do fail in the Web) of both coordinator and participants, that's pretty much WS-CF in a nutshell.
You might ask what's the difference between WS-CF and the IBM, Microsoft, BEA WS-Coordination specification? If you'd asked that question a couple of years ago (when we first released them) as many analysts did, the answer would have taken a couple of pages to describe. Now it's a lot simpler, but would still take a page, so I'll mention only two differences: WS-CF builds on WS-Context, so in our opinion fits into the Web Services architecture more naturally; it also handles basic endpoint recovery at the level that makes sense rather than making everything a users responsibility to figure out.
Anyway, I think that everyone who attended the meeting thought it went very well. Certainly I came away from it last week happy that we'd made a lot more progress than I'd hoped for. With any luck we should have WS-CF finished and almost at Committee Draft by April (we have to produce a Primer, which is probably the most work between now and then) and then we can move on to transactions, which is something I'm looking forward to.
Before I forget though, thanks go to CodeWorks for sponsoring the meeting. We've been working with these guys for a couple of months on helping to educate companies in our region on the benefits of Web Services and their remit is to publicise Web Services and the region as widely as possible. I think this was a good opportunity for them (and us) to get that point across to companies who attended the face-to-face and I'm confident that there'll be some tangible benefit to CodeWorks and the region as a result.
Because WS-CF is meant to be a low-level, generic coordination infrastructure, there's not a lot we can do at this level in terms of specific coordination protocol, i.e., coordinator-to-participant and participant-to-coordinator interactions. (Actually, we did a lot more in our initial submission to OASIS than we do now, but the TC has decided to remove some of that stuff and punt it to the higher level users/specifications.) So, apart from adding and removing participants, and handling recovery (yes, believe it or not, things do fail in the Web) of both coordinator and participants, that's pretty much WS-CF in a nutshell.
You might ask what's the difference between WS-CF and the IBM, Microsoft, BEA WS-Coordination specification? If you'd asked that question a couple of years ago (when we first released them) as many analysts did, the answer would have taken a couple of pages to describe. Now it's a lot simpler, but would still take a page, so I'll mention only two differences: WS-CF builds on WS-Context, so in our opinion fits into the Web Services architecture more naturally; it also handles basic endpoint recovery at the level that makes sense rather than making everything a users responsibility to figure out.
Anyway, I think that everyone who attended the meeting thought it went very well. Certainly I came away from it last week happy that we'd made a lot more progress than I'd hoped for. With any luck we should have WS-CF finished and almost at Committee Draft by April (we have to produce a Primer, which is probably the most work between now and then) and then we can move on to transactions, which is something I'm looking forward to.
Before I forget though, thanks go to CodeWorks for sponsoring the meeting. We've been working with these guys for a couple of months on helping to educate companies in our region on the benefits of Web Services and their remit is to publicise Web Services and the region as widely as possible. I think this was a good opportunity for them (and us) to get that point across to companies who attended the face-to-face and I'm confident that there'll be some tangible benefit to CodeWorks and the region as a result.
Tuesday, February 08, 2005
Groundhog Day
On the trip over to New York the other week I watched GroundHog Day, which is still a great film. I have to admit that I always thought it was just a movie and that such an even didn't really happen (at least not in this day and age). So it was a bit of a surprise to overhear a couple of people on the 2nd of February discussing the events of the latest Day in all seriousness. You live and learn I suppose!
Friday, February 04, 2005
Flights are bad for your health
Time for a rant. Pretty much everytime I travel on a plane I end up
with a cold of one severity or another. So, I'm back from the Web
Services on Wall Street conference and guess what: I'm hold up in bed
with a flu. Without going into any of the gorey details, suffice it to
say that I'm sure there are tiny creatures in my head playing with
pneumatic drills.
I've been travelling for more years than I care to remember, but it
wasn't until Twelve Monkeys came out that I really thought about
this. (BTW, it's a great movie IMO.) What a fantastic way for viruses
to spread around the globe! Now is it just me or does this not seem
like an opportunity waiting to be exploited? You can take your
missile-shields, missile-detectors, early warning systems etc. Where's
the equivalent for a viral attack? I've never been asked to prove that
my aerosol contains deoderant and not some virulent strain of
botulinum bacteria. As the film shows, the perpetrators don't even need to be
on the same continent!
BTW, this isn't something I'm going to worry about any more than I do
other threats. It's just that I'm lying here in bed and the mind tends
to wander.
with a cold of one severity or another. So, I'm back from the Web
Services on Wall Street conference and guess what: I'm hold up in bed
with a flu. Without going into any of the gorey details, suffice it to
say that I'm sure there are tiny creatures in my head playing with
pneumatic drills.
I've been travelling for more years than I care to remember, but it
wasn't until Twelve Monkeys came out that I really thought about
this. (BTW, it's a great movie IMO.) What a fantastic way for viruses
to spread around the globe! Now is it just me or does this not seem
like an opportunity waiting to be exploited? You can take your
missile-shields, missile-detectors, early warning systems etc. Where's
the equivalent for a viral attack? I've never been asked to prove that
my aerosol contains deoderant and not some virulent strain of
botulinum bacteria. As the film shows, the perpetrators don't even need to be
on the same continent!
BTW, this isn't something I'm going to worry about any more than I do
other threats. It's just that I'm lying here in bed and the mind tends
to wander.
Wednesday, February 02, 2005
J2SE 5.0
I've just finished the first day at the Web Services on Wall Street conference. It's been interesting and strangely enough, probably the most interesting presentation was on J2SE 5.0 (Tiger). I have to admit that I haven't had time to look at this stuff since the previews I saw at last year's JavaOne. So it was good to get an overview of what Sun think are the most important changes to the language since the first version.
Generics (templates to you and me) have been coming for a while and not before time. I've used templates in C++ a lot and although I've always found them useful, they were probably one of the most un-portable features of the language I ever came across. Things have probably changed now though.
Autoboxing seems like a nice-to-have though not critical; keeps the language tidy (although maybe it's one step closer to allowing us to have operator overloading ;-). Same for the enhanced for loop and static imports.
Now type safe enums are cool. I've put up with integers in code since the first time I used Java and it really annoyed me that there was no natural way to do enumeration types. But what they've done in J2SE 5.0 with enums does seem to go one better than C++ and allow me to add functionality within an enum. This looks very interesting.
Ah varargs :-). What more can I say? At last!
Metadata looks like it could be very useful too. Certainly the presenter indicated that Sun intend to use this feature more and more as the language evolves.
Then they've added other things like printf/scanf. Nice and useful. However, as a whole, not good enough IMO. Java has always fallen short of C++ on I/O routines. You just have to look at the things you can do with cout and cin to see what I mean.
Anyway, all in all J2SE 5.0 looks like it could be a good addition to the Java family. Sun reckon that you could get 20% performance improvement just by running old code on it. I'll wait and see on that one. But I do wish I spent more of my time programming so I could find out. Oh well. Maybe next vacation!
Generics (templates to you and me) have been coming for a while and not before time. I've used templates in C++ a lot and although I've always found them useful, they were probably one of the most un-portable features of the language I ever came across. Things have probably changed now though.
Autoboxing seems like a nice-to-have though not critical; keeps the language tidy (although maybe it's one step closer to allowing us to have operator overloading ;-). Same for the enhanced for loop and static imports.
Now type safe enums are cool. I've put up with integers in code since the first time I used Java and it really annoyed me that there was no natural way to do enumeration types. But what they've done in J2SE 5.0 with enums does seem to go one better than C++ and allow me to add functionality within an enum. This looks very interesting.
Ah varargs :-). What more can I say? At last!
Metadata looks like it could be very useful too. Certainly the presenter indicated that Sun intend to use this feature more and more as the language evolves.
Then they've added other things like printf/scanf. Nice and useful. However, as a whole, not good enough IMO. Java has always fallen short of C++ on I/O routines. You just have to look at the things you can do with cout and cin to see what I mean.
Anyway, all in all J2SE 5.0 looks like it could be a good addition to the Java family. Sun reckon that you could get 20% performance improvement just by running old code on it. I'll wait and see on that one. But I do wish I spent more of my time programming so I could find out. Oh well. Maybe next vacation!
Tuesday, February 01, 2005
Cool trains
Subscribe to:
Posts (Atom)