FWIW, "oriented" (in "object-oriented" etc.) was unknown in British English 15 years ago. My impression is that it is still pretty much confined to "object-oriented" here, and when travelling about people will still "try to orientate" themselves.
WebLogic only replicates state between pairs, never between three or more.
It's not necessary to understand the details of this as it happens automatically - essentially WL picks a secondary server that it knows is on a different physical machine.
If your BEA consultant has only ever set up a cluster once, and that for a version of the product dating from four years ago (I assume you mean WL 5.1) it sounds like he was an impostor.
Apart from these little criticisms, I have some sympathy with your "load balance only" approach. One thing you can do when not using clustering is upgrade servers in rotation, which is admittedly pretty handy.
Real competitive advantage revolves around integration and portability, not dumb little language tricks.
Most people will appreciate JDBC drivers for their local database, flexible security, true cross-platform working etc. Conversely,, we can probably get by without "attribute annotations" for a while.
Java standardization occurs through the JCP. Regardless of this process, people are free to implement anything they want.
The fact that you chose Gnome bindings as an illustration of what is impossible would be very amusing to the SWT team at IBM who have already implemented them (as open source).
Sun retains rights to the Java trademark and associated frameworks such as J2SE and J2EE. You can't do a Microsoft and pass an incompatible version of these off as Java, but you can call it anything else you want.
Your discovery that there are Sun patents prohibiting fully compatible implementations will doubtless come as a bit of a shock to IBM, BEA and the several dozen other companies implementing fully-compatible platforms. I trust you've taken steps to inform them?
The penetrating observation that Java is a platform may well cause Linux C API fans some concern. Though not as much concern, I think, as the thought of having no high quality VM on the OS at all, thereby leaving it at a severe disadvantage compared to other mainstream OSes.
they have been known on occasion to get very mad about people making versions of Java without their support.
Yes, they don't like having their platform polluted. This helps my applications stay portable. I sincerely hope they continue to keep implementors in line. Don't you?
Ah yes, it's 19:29 Groundhog Standard Time and the "C Sharp is a standard platform" post makes its due appearance. And we in turn recite the standard rebuttal, viz:
1. C Sharp the language is a standard, but this counts for little since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.
2. Shared source is not open source, in fact, I doubt if many people here would be willing to accept the terms for looking at Rotor, let alone using it.
3. "Not stood in the way of" (yet) other implementations is a little different from actually supporting them. With the Java Platform, not only are there already multiple vendors and dozens of separate implementations, but the legal permission for their development has been set forth in the JSPA. No equivalent exists for Dotnet whatsoever.
(Yawn. Hope I'm not missing anything good on TV...)
Java - there are too many releases and java applications seem to be too tightly tied to specific point releases. This causes huge support problems.
Really? That's not my experience at all - I can run all old Java apps on the latest VMs, backward compatibility is very good. Perhaps they seem to be tied to a particular release because they ship with that release included, like WebLogic or Oracle do?
Compare this to the situation with VB programs, for example.
Re:Why can't I get Java working on my RH8 box?
on
Sun's Last Stand
·
· Score: 1
Why can't I just simply get an RPM that WORKS!
Try looking here? Mozilla + Java has worked out-of-the-box in all releases I've tried, I think since 6.4 three or four years ago.
Nonsense. C# and Java semantics are so close that if it wasn't for different capitalization approaches it would be hard to tell the difference. The CLR bytecode is somewhat different, but the Java innovations such as code verification and signing (which Smalltalk never had) are all present and correct, whereas Smalltalk' syntax, lack of static typing and persistent image are all missing.
If anything, Java is more like Simula. And the Dotnet architects usually identified, such as Anders Heljsberg, did not come from a Smalltalk background.
You can't be tied to MS standards if MS isn't providing any of the code here. So what if MS takes their.NET framework and breaks Mono compatiblity in a future release? They hang onto the old framework and go to work re-coding it and branch it off from there.
I find this a very revealing line of argument. It seems that Dotnet compatibility is something that Mono proponents are very keen to tout as a major advantage of the platform, but when the real-world difficulties of achieving it are pointed out it suddenly becomes minor and optional.
If the only possible benefit is so much at risk, why subject yourself to all the constraints?
It's rather as if one were advertising an expensive French language school which guarantees that you'll benefit greatly from the course, whether or not French people can understand you.
A "nice platform to work with"? I see. This sounds about as convincing as the Mono Rationale document, which reduces to the same kind of vacuous assertion.
I would be very interested in studies comparing Dotnet against Java for large developments. Given the undeniable similarity of the basic technology, the existence of VS.NET-like tools for Java and not forgetting of course the minor detail that Dotnet is useless for anything not running on Windows, it's pretty hard to see what great advantage Dotnet is going to offer a typical enterprise.
I've no idea what we're supposed to make of the bald assertion of "compatability". Compatible with what? And necessary for whom? Your method and reasoning, never mind motivation, remain very far from being clear.
I trust it will not come as too much of a surprise to learn that, outside the world of Mono hype, justication for substantial projects is generally required before they start. But, as you have deigned to offer some ex post facto rationale, it's worthwhile examining this in detail:
Parrot is or was intending to support the CLI bytecode set in addition to its own. It's therefore hard to see how Miguel's criticism can be of this bytecode set - or is he concerned about those he'll never use?
Guile is bytecode VM targeted at Scheme and as such is relevant. In fact, there are plenty of good arguments for the use of a Scheme-based intermediate language on a VM, as the botched 'meta-data' implementations of Java and C# are starting to reveal.
Regarding the Kaffe Java VM, it's interesting to see that you switch arguments here to complain about its slow development rather than any technical flaws. The reason for this is of course that there are no less than three major, high-quality implementations of Java 2 for Linux on Intel, plus the possibility of licensing the source for other platforms. Regardless of this, naturally the Mono crew were free to start with this rather than start from scratch, but that would be assuming that they're focused on delivering capability rather than hype.
Your last paragraph seems almost desperate in its attempt to deny the momentum of Java. A glance at SourceForge, job listings or a wander around any large corporation would show that the growth of Java continues unabated, and is leagues ahead of Dotnet, never mind the Mono knock-off. It is possible that some major desktop apps will be written for Dotnet, but I shall not be holding my breath for Photoshop on Mono.
That's a good point. It's true I haven't worried about WINE but then I haven't had a cause to use it in my 10 years or so of working with Linux.
The bottom line is that I hate getting sued, particularly over dumbass patents. WINE, like the Win32 API, is really old technology. Yes, MS may still claim IP in it and make life difficult but it's not really where the action is.
Mono / Java is critical for Linux - most people don't realise this but very quickly most big apps will be targeted at VMs - simple commercial expedience will ensure this regardless of the technical merits.
Mono therefore risks putting MS in the Linux driving seat. There are alternatives, but the Linux community's reluctance to embrace Java could mean a shotgun wedding with Mono. And that way we're all worse off for the forseeable future,
Oh dear, are you sure you were concentrating before?
What we are referring to here is the Dotnet Framework. Not just C#, not just the CLR or CLI, but the whole platform - the APIs that people write real applications on. Nobody is disputing that for Mono to be useful, it has to go beyond what has been made public and clone those parts that are private and patented.
The word "liable" is well chosen regarding Mono's position with MS - and those using it will be in just the same position legally as those creating it.
The situation with the Java Platform (to include J2SE, and J2EE if you like) is quite different. Not only are there already multiple vendors and dozens of separate implementations, but the legal position has been set forth in the JSPA (that link again, for the hard of memorizing). No equivalent exists for Dotnet whatsoever.
Thanks for the link regarding Mono's rationale. I encourage everyone to visit this page and evaluate the reasons stated. I'm afraid that when I looked I could only find the following rather contradicatory statements:
There is not really a lot of innovation in this platform: we have seen all of these concepts before, and we are all familiar with how these things work.
What makes the Common Language Infrastructure development platform interesting is that it is a good mix of technologies that have been nicely integrated.
The.NET development platform is essentially a new foundation for program development that gives Microsoft a room to grow for the coming years.
Now, regardless of whether the Mono people think that Dotnet is or is not an innovation, I think we are obliged to observe the rationale for their enthusiasm is less than one sentence long and rather vague. Given that Perl and Java could equally well be described as an interesting mix of technologies, that they were around a long time before Dotnet, and that the Mono proponents themselves admit that there is not a lot of real innovation in it, it is very hard to see how this aspirational fragment can add up to a convincing manifesto.
Regarding your analysis of other open source VM efforts, I again find myself unable to discern nuch of a coherent argument in your statements, despite your earnest entreaties. You appear to be against a multiplicity of similar efforts where Perl and Python are concerned, but apparently for multiplicity where Java, Mono and Dotnet are concerned.
I'm not particularly disappointed that you are unaware of original, innovative and preexisting OSS work in this area - the problem is that the Mono developers are unaware of them too, and prefer to subject themselves to Microsoft's leadership rather than work with those that share more compatible goals and methods.
Unfortunately, the casual reader might gain the impression from your post that Microsoft have made the whole of Dotnet public (around 1200 C# classes) rather than just C# and the CLR (around 150 classes).
I'm sure you will be as anxious as I am to clarify the true position, perhaps by mentioning Steve Ballmer's comments from March last year where he states that MS holds patents on Dotnet technologies and that free implementations will not be allowed, or by comparing the MS position with that of Sun and Java, which, under the JSPAexplicitly permits free implementations.
But there was a serious point in there - that Ximian are encouraging people to risk cloning a substantial portion of Microsoft's IP.
Don't forget that Miguel and co. have never been particularly clear about why they are doing this, and what precisely was wrong with established OSS efforts such as Parrot, Guile, Kaffe etc.
What many people have noticed is that
a) baiting MS makes headlines
b) Miguel and co. were too late to appoint themselves leaders of the other projects
1. Mono can be the universal component hub, allowing you to use C objects from Python, C++ objects from Perl, and so on.
We've certainly been here before. As has been pointed out on/. a number of times, ActiveX, CORBA, DCE etc. have all made claims like this and have met with limited success.
First there is the inefficiency introduced by constantly translating data (where equivalents exist at all), second the impedance mismatch of languages with quite different call models.
Yes, there's some capability here for scripting code written in low-level languages, but that's quite a different thing from claiming to provide universal, peer-level interoperability.
Note that this isn't the same argument that says that bytecode level interworking is doomed - one is still limited to a rather C#-like subset of features, just as one is to a Java-like subset in a JVM.
Nat goes on to give an example of how Mono is changing things:
This is possible because C#'s language features make it trivial to automatically bind C# objects into other languages. Check out Python Scripting for.NET: http://www.zope.org/Members/Brian/PythonNet/FAQ.ht ml.
OK, let's see what Brian thinks this new Python Dotnet is bringing to the table:
" While a solution like Jython provides "two-way" interoperability, this package only provides "one-way" integration. Meaning, while Python can use types and services implemented in.NET, managed code cannot generally use classes implemented in Python.
A Jython-like solution for.NET would certainly be doable and useful - but it would also be a lot more work than the current approach."
Hardly a ringing endorsement of Mono here. Perhaps the last reference will be the proposition that we can't refuse?
Nat says:
There's also a Mono-based JavaScript compiler in the works (MS already has one, of course).
Doesn't the Java world have one of those too? Yes, in fact, it's had one for five years. Rhino is a full Javascript compiler, interpreter and debugger, released by Netscape in April 98 and still developed under the Mozilla banner. Not some also-ran knock-off here, but something used in quite significant products such as the Resin web app server.
So, draw your own conclusions about what real new capabilities Mono will bring to the OSS world.
And don't forget that there is at least one company that will definitely gain from this all this free marketing and "innovation".
That rather depends on what your definition of is is.
At the moment, there is no Windows Forms, Web Forms or ADO.NET for Mono. Whether MS will allow there to be in due course is a very interesting question.
Personally, I shall be taking great care to ensure that this remains of academic interest only.
For web service development in the J2EE world, and soon for much else (portals, workflow management) you might like to take a look at BEA's Workshop.
I like its approach to messaging a lot - makes SOAP/HTTP just another transport like JMS, presents RPC and async alternatives very clearly and shows what's going on message-wise live, rather than being a separate code generator.
Slashdot Mirror
Oh yes there is: Convention for the Protection of Human Rights and Fundamental Freedoms
Not bad for a non real-time OS.
Wonder if Linux will be extended to run an RT subsystem or the RTS extended to run Linux?
In the UK, the Oxford dictionary is the official lexicon, as far as I know.
Nope, there is no official UK lexicon. The OED is not prescriptive in the sense that Noah Webster's was, for example.
FWIW, "oriented" (in "object-oriented" etc.) was unknown in British English 15 years ago. My impression is that it is still pretty much confined to "object-oriented" here, and when travelling about people will still "try to orientate" themselves.
Hmmmm.
WebLogic only replicates state between pairs, never between three or more.
It's not necessary to understand the details of this as it happens automatically - essentially WL picks a secondary server that it knows is on a different physical machine.
If your BEA consultant has only ever set up a cluster once, and that for a version of the product dating from four years ago (I assume you mean WL 5.1) it sounds like he was an impostor.
Apart from these little criticisms, I have some sympathy with your "load balance only" approach. One thing you can do when not using clustering is upgrade servers in rotation, which is admittedly pretty handy.
Real competitive advantage revolves around integration and portability, not dumb little language tricks.
Most people will appreciate JDBC drivers for their local database, flexible security, true cross-platform working etc. Conversely,, we can probably get by without "attribute annotations" for a while.
Stuff and nonsense.
Java standardization occurs through the JCP. Regardless of this process, people are free to implement anything they want.
The fact that you chose Gnome bindings as an illustration of what is impossible would be very amusing to the SWT team at IBM who have already implemented them (as open source).
Sun retains rights to the Java trademark and associated frameworks such as J2SE and J2EE. You can't do a Microsoft and pass an incompatible version of these off as Java, but you can call it anything else you want.
Your discovery that there are Sun patents prohibiting fully compatible implementations will doubtless come as a bit of a shock to IBM, BEA and the several dozen other companies implementing fully-compatible platforms. I trust you've taken steps to inform them?
The penetrating observation that Java is a platform may well cause Linux C API fans some concern. Though not as much concern, I think, as the thought of having no high quality VM on the OS at all, thereby leaving it at a severe disadvantage compared to other mainstream OSes.
they have been known on occasion to get very mad about people making versions of Java without their support.
Yes, they don't like having their platform polluted. This helps my applications stay portable.
I sincerely hope they continue to keep implementors in line. Don't you?
Ah yes, it's 19:29 Groundhog Standard Time and the "C Sharp is a standard platform" post makes its due appearance. And we in turn recite the standard rebuttal, viz:
1. C Sharp the language is a standard, but this counts for little since the platform (corresponding to J2SE or J2EE) is really the Dotnet framework, which is not standardized and remains proprietary and patented.
2. Shared source is not open source, in fact, I doubt if many people here would be willing to accept the terms for looking at Rotor, let alone using it.
3. "Not stood in the way of" (yet) other implementations is a little different from actually supporting them. With the Java Platform, not only are there already multiple vendors and dozens of separate implementations, but the legal permission for their development has been set forth in the JSPA. No equivalent exists for Dotnet whatsoever.
(Yawn. Hope I'm not missing anything good on TV...)
Java - there are too many releases and java applications seem to be too tightly tied to specific point releases. This causes huge support problems.
Really? That's not my experience at all - I can run all old Java apps on the latest VMs, backward compatibility is very good. Perhaps they seem to be tied to a particular release because they ship with that release included, like WebLogic or Oracle do?
Compare this to the situation with VB programs, for example.
Why can't I just simply get an RPM that WORKS!
Try looking here?
Mozilla + Java has worked out-of-the-box in all releases I've tried, I think since 6.4 three or four years ago.
My interest is in the FS developing more DB-like features:
- versioning
- multiple namespaces
- transactions
- datatype awareness ("metadata")
I think we can agree that a full-blown RDB isn't really on the cards yet.And of course Windows FS is on the horizon so database-backed file systems might get popular.
;-)
How about merging Reiser with PostgreSQL?
Ah, the "undeniably correct but irrelevant followup" gambit. Ideal for abstruse language debates.
Nonsense. C# and Java semantics are so close that if it wasn't for different capitalization approaches it would be hard to tell the difference. The CLR bytecode is somewhat different, but the Java innovations such as code verification and signing (which Smalltalk never had) are all present and correct, whereas Smalltalk' syntax, lack of static typing and persistent image are all missing.
If anything, Java is more like Simula. And the Dotnet architects usually identified, such as Anders Heljsberg, did not come from a Smalltalk background.
You can't be tied to MS standards if MS isn't providing any of the code here. So what if MS takes their .NET framework and breaks Mono compatiblity in a future release? They hang onto the old framework and go to work re-coding it and branch it off from there.
I find this a very revealing line of argument. It seems that Dotnet compatibility is something that Mono proponents are very keen to tout as a major advantage of the platform, but when the real-world difficulties of achieving it are pointed out it suddenly becomes minor and optional.
If the only possible benefit is so much at risk, why subject yourself to all the constraints?
It's rather as if one were advertising an expensive French language school which guarantees that you'll benefit greatly from the course, whether or not French people can understand you.
A "nice platform to work with"? I see. This sounds about as convincing as the Mono Rationale document, which reduces to the same kind of vacuous assertion.
I would be very interested in studies comparing Dotnet against Java for large developments. Given the undeniable similarity of the basic technology, the existence of VS.NET-like tools for Java and not forgetting of course the minor detail that Dotnet is useless for anything not running on Windows, it's pretty hard to see what great advantage Dotnet is going to offer a typical enterprise.
I've no idea what we're supposed to make of the bald assertion of "compatability". Compatible with what? And necessary for whom? Your method and reasoning, never mind motivation, remain very far from being clear.
I trust it will not come as too much of a surprise to learn that, outside the world of Mono hype, justication for substantial projects is generally required before they start. But, as you have deigned to offer some ex post facto rationale, it's worthwhile examining this in detail:
Parrot is or was intending to support the CLI bytecode set in addition to its own. It's therefore hard to see how Miguel's criticism can be of this bytecode set - or is he concerned about those he'll never use?
Guile is bytecode VM targeted at Scheme and as such is relevant. In fact, there are plenty of good arguments for the use of a Scheme-based intermediate language on a VM, as the botched 'meta-data' implementations of Java and C# are starting to reveal.
Regarding the Kaffe Java VM, it's interesting to see that you switch arguments here to complain about its slow development rather than any technical flaws. The reason for this is of course that there are no less than three major, high-quality implementations of Java 2 for Linux on Intel, plus the possibility of licensing the source for other platforms. Regardless of this, naturally the Mono crew were free to start with this rather than start from scratch, but that would be assuming that they're focused on delivering capability rather than hype.
Your last paragraph seems almost desperate in its attempt to deny the momentum of Java. A glance at SourceForge, job listings or a wander around any large corporation would show that the growth of Java continues unabated, and is leagues ahead of Dotnet, never mind the Mono knock-off. It is possible that some major desktop apps will be written for Dotnet, but I shall not be holding my breath for Photoshop on Mono.
That's a good point. It's true I haven't worried about WINE but then I haven't had a cause to use it in my 10 years or so of working with Linux.
The bottom line is that I hate getting sued, particularly over dumbass patents. WINE, like the Win32 API, is really old technology. Yes, MS may still claim IP in it and make life difficult but it's not really where the action is.
Mono / Java is critical for Linux - most people don't realise this but very quickly most big apps will be targeted at VMs - simple commercial expedience will ensure this regardless of the technical merits.
Mono therefore risks putting MS in the Linux driving seat. There are alternatives, but the Linux community's reluctance to embrace Java could mean a shotgun wedding with Mono. And that way we're all worse off for the forseeable future,
Oh dear, are you sure you were concentrating before?
.NET development platform is essentially a new foundation for program development that gives Microsoft a room to grow for the coming years.
What we are referring to here is the Dotnet Framework. Not just C#, not just the CLR or CLI, but the whole platform - the APIs that people write real applications on. Nobody is disputing that for Mono to be useful, it has to go beyond what has been made public and clone those parts that are private and patented.
The word "liable" is well chosen regarding Mono's position with MS - and those using it will be in just the same position legally as those creating it.
The situation with the Java Platform (to include J2SE, and J2EE if you like) is quite different. Not only are there already multiple vendors and dozens of separate implementations, but the legal position has been set forth in the JSPA (that link again, for the hard of memorizing). No equivalent exists for Dotnet whatsoever.
Thanks for the link regarding Mono's rationale. I encourage everyone to visit this page and evaluate the reasons stated. I'm afraid that when I looked I could only find the following rather contradicatory statements:
There is not really a lot of innovation in this platform: we have seen all of these concepts before, and we are all familiar with how these things work.
What makes the Common Language Infrastructure development platform interesting is that it is a good mix of technologies that have been nicely integrated.
The
Now, regardless of whether the Mono people think that Dotnet is or is not an innovation, I think we are obliged to observe the rationale for their enthusiasm is less than one sentence long and rather vague. Given that Perl and Java could equally well be described as an interesting mix of technologies, that they were around a long time before Dotnet, and that the Mono proponents themselves admit that there is not a lot of real innovation in it, it is very hard to see how this aspirational fragment can add up to a convincing manifesto.
Regarding your analysis of other open source VM efforts, I again find myself unable to discern nuch of a coherent argument in your statements, despite your earnest entreaties. You appear to be against a multiplicity of similar efforts where Perl and Python are concerned, but apparently for multiplicity where Java, Mono and Dotnet are concerned.
I'm not particularly disappointed that you are unaware of original, innovative and preexisting OSS work in this area - the problem is that the Mono developers are unaware of them too, and prefer to subject themselves to Microsoft's leadership rather than work with those that share more compatible goals and methods.
Unfortunately, the casual reader might gain the impression from your post that Microsoft have made the whole of Dotnet public (around 1200 C# classes) rather than just C# and the CLR (around 150 classes).
I'm sure you will be as anxious as I am to clarify the true position, perhaps by mentioning Steve Ballmer's comments from March last year where he states that MS holds patents on Dotnet technologies and that free implementations will not be allowed, or by comparing the MS position with that of Sun and Java, which, under the JSPA explicitly permits free implementations.
But there was a serious point in there - that Ximian are encouraging people to risk cloning a substantial portion of Microsoft's IP.
Don't forget that Miguel and co. have never been particularly clear about why they are doing this, and what precisely was wrong with established OSS efforts such as Parrot, Guile, Kaffe etc.
What many people have noticed is that
a) baiting MS makes headlines
b) Miguel and co. were too late to appoint themselves leaders of the other projects
Some interesting claims made for Mono:
/. a number of times, ActiveX, CORBA, DCE etc. have all made claims like this and have met with limited success.
.NET: http://www.zope.org/Members/Brian/PythonNet/FAQ.ht ml.
.NET, managed code cannot generally use classes implemented in Python.
.NET would certainly be doable and useful - but it would also be a lot more work than the current approach."
1. Mono can be the universal component hub, allowing you to use C objects from Python, C++ objects from Perl, and so on.
We've certainly been here before. As has been pointed out on
First there is the inefficiency introduced by constantly translating data (where equivalents exist at all), second the impedance mismatch of languages with quite different call models.
Yes, there's some capability here for scripting code written in low-level languages, but that's quite a different thing from claiming to provide universal, peer-level interoperability.
Note that this isn't the same argument that says that bytecode level interworking is doomed - one is still limited to a rather C#-like subset of features, just as one is to a Java-like subset in a JVM.
Nat goes on to give an example of how Mono is changing things:
This is possible because C#'s language features make it trivial to automatically bind C# objects into other languages. Check out Python Scripting for
OK, let's see what Brian thinks this new Python Dotnet is bringing to the table:
" While a solution like Jython provides "two-way" interoperability, this package only provides "one-way" integration. Meaning, while Python can use types and services implemented in
A Jython-like solution for
Hardly a ringing endorsement of Mono here. Perhaps the last reference will be the proposition that we can't refuse?
Nat says:
There's also a Mono-based JavaScript compiler in the works (MS already has one, of course).
Doesn't the Java world have one of those too? Yes, in fact, it's had one for five years. Rhino is a full Javascript compiler, interpreter and debugger, released by Netscape in April 98 and still developed under the Mozilla banner. Not some also-ran knock-off here, but something used in quite significant products such as the Resin web app server.
So, draw your own conclusions about what real new capabilities Mono will bring to the OSS world.
And don't forget that there is at least one company that will definitely gain from this all this free marketing and "innovation".
I think you've fallen into that trap that MS has so carefully laid.
There is no requirement for a trusted system at your end in order for a bank to authenticate you reliably.
Palladium is all about the means of control of your machine and the information on it effected by external agents.
Banks do not need to control information they send to you - they only send you your information.
That rather depends on what your definition of is is.
At the moment, there is no Windows Forms, Web Forms or ADO.NET for Mono. Whether MS will allow there to be in due course is a very interesting question.
Personally, I shall be taking great care to ensure that this remains of academic interest only.
For web service development in the J2EE world, and soon for much else (portals, workflow management) you might like to take a look at BEA's Workshop.
I like its approach to messaging a lot - makes SOAP/HTTP just another transport like JMS, presents RPC and async alternatives very clearly and shows what's going on message-wise live, rather than being a separate code generator.