OASIS Symposium

I’m attending the OASIS Symposium this week in New Orleans.
Yesterday, I took part in a presentation and panel discussion on Web services transactions. I presented on WS-CAF, which is also holding a face to face meeting tomorrow and Thursday here (more on that later).
We had a good, spirited discussion about the differences and similarities across WS-CAF, BTP, and the WS-TX set of specifications from Microsoft, IBM, and BEA. We also heard one of the common themes that’s been expressed throughout the symposium – why do we have to have competing specifications?
This question came up again during a similar presentation and panel discussion on reliable messaging, and came up in a discussion on RosettaNet, ebXML, CIDX, and AIAG.
William Stangel, Senior VP and Enterprise Architect at Fidelity Investment Systems said during his keynote yesterday that HTTP and HTML were standards that really changed how Fidelity does business. Web services standards have yet to make a similar impact, he said.
Does anyone else find it interesting that one of the reasons cited for awarding Tim Berners-Lee the Millenium Prize (1M Euros) is that he did not patent his inventions (URL, HTTP, HTML)?
“Pekka Tarjanne, chairman of the prize committee, underlined the importance of Berners-Lee’s decision to never strive to commercialize or patent his contributions to the Internet technologies he has developed.”
Does anyone know what is the position of IBM, Microsoft, et al with regard to patent rights to the Web services specifications they are privately authoring and publishing?

More on suitability of MDA/UML for Web Services

One of the great things about blogs is that you can get into a great discussion with people with whom you’d otherwise not have any contact.
So far, it’s been a very helpful discussion overall, with the exception of a few knuckleheads on the ServerSide.com who post comments without bothering to understand the point of the discussion. (Most of the comments there were interesting and to the point, reinforcing my growing appreciation of the positive power of Blogs!)
For the record, I never said or implied that drawings aren’t useful or important. Of course they are, especially for the design and documentation phase.
The whole thing started because I was thinking about (and wrote about) something someone told me more than a year ago, about how MDA was going to become the “next great abstraction” in software, similar to the way in which COBOL established itself as the next abstraction over assembly language. And I guess in my original posting I didn’t leave much room for subtlety, such as acknowledging the fact that some people still used assembler even when the majority moved on to COBOL and the other so-called third-generation languages that COBOL epitomized.
So it would seem natural, if I had thought further, to acknowledge the future of software would likely include a mixture of whatever becomes the next abstraction with current languages.
But I still am not convinced the MDA will become the new “fourth” or “fifth” generation language (wherever we are in the count, since fourth generation languages didn’t really succeed), or the epitomy of it, since it seems so unlikely that any graphical language could ever really replace a text based language as a new abstraction layer. (And that was the entire original point.)
However, I do believe XML and Web services have that potential, and seem very likely to succeed at becoming the “future of software” by providing that new text-based code abstraction layer with which people can successfully create enterprise computer systems.
After clarification on the currently more modest goals of the MDA community around increasing the productivity of coders, which make a lot more sense to me than the sort of “new abstraction level” stuff, the discussion moved on to whether MDA (and its superset, UML) are well suited to use with Web services. I said that they weren’t, and Stefan Tilkov said that they are.
This is very interesting, since his entry highlights the fact that there are two real streams of thought converging in Web services — and this is sometimes forgotten in the debates since all of us tend to be guilty in assuming one model or the other. I always assume the asynchronous, message-oriented model for Web services since it’s the most useful (Web services are not RPCs, and shouldn’t be mistaken for them desipte the fact that they have an RPC- emulation message exchange pattern).
And that’s why I say UML and MDA are not well suited for Web services, since they are not well suited for integration-oriented applications.
The two streams of thought or models could also be called the synchronous, application server model and the asynchronous messaging, or EAI broker model. The world of distributed systems is divided in some nearly equal measure between applications better suited for one or the other, and always will be.
Anyway, it seems that many people are thinking about Web services as if they are equivalent to the application server model, since that’s what they are familiar with. And if you think that way, and you are used to using UML with your application server development, then it does seem to make sense to use UML for Web services, since what you are really doing is creating a new EJB, not a Web service per se.
However, if you think that Web services are better suited for SOA and integration applications, as I do, then UML doesn’t make sense since UML is aimed at new development, not fitting service interfaces onto existing or legacy code. Web services need to be language and protocol neutral to support the broadest level of interoperability, like browsers on the Web, and they can’t if they are tied to a single development language or tool.
When developing SOAs with Web services, it doesn’t make sense to think about Web services as if they were a single software environment technology. The whole point of SOA is to join disparate software systems together, not constrain yourself to whatever you can accomplish using VisualStudio, WebLogic Workshop, WebSphere Rational, or whatever.
Something that allows and supports greater neutrality is needed, something that works across those tools and more, and today XML on its own does the job pretty well, especially the Web services applications of XML, such as SOAP and WSDL. No need for UML — it just gets in the way.

UML/MDA — Not Well Suited for Web Services

In my recent postings, I’ve asserted that UML and MDA are not well suited for Web services. There are two main reasons:

• Web services are intended for cross-domain interoperability
• Web services need a data model, not an object model

Stefan Tilkov says that he is using UML for a Web services project. It would be great to hear more details about that, in particular whether it’s a data-oriented integration project.
I never said it’s impossible to use UML or MDA with Web services. I’m sure it is. My position is that UML and MDA are not well suited for use with Web services — they are not the right tool for the job. Putting a camera on a phone doesn’t mean it’s a camera. Just because it’s possible to use UML and MDA for Web services doesn’t mean it’s the right thing to do.
UML is too complex for Web services; simple and cheap is always better. I’d be surprised if anyone is using UML/MDA for Web services who didn’t already know UML. Learning UML in order to use Web services seems like real overkill.
This article on the WS-I sample application illustrates one of the main points — UML was not designed for use with applications that span multiple domains. UML and MDA were designed to model an application for a single object-oriented domain (and by domain I mean coherent software systems such as J2EE application servers, the .NET Framework, or CORBA-compliant object request brokers). I realize the models are generic; however as implemented in development toolsets the goal is to generate mappings to a specific technology.
UML and MDA are not designed for modeling integration projects in which reconciling data type and structure differences are the paramount activity. Integration projects do not start with a clean slate – by definition integration means joining things that already exist – and UML/MDA does not have a good way to understand or model transformations, aggregations, and associations among related data items and structures. Sure — it wasn’t designed to.
So on the one hand UML/MDA are overkill for Web services. It also already seems clear that the original vision of providing another “layer of abstraction” in the evolution of software, i.e. replacing programming languages as the way in which people tell computers what to do, hasn’t panned out. And finally, UML/MDA do not address a major requirement of Web services — data integration and reconciliation of semantics.
The argument therefore has everything to do with what Web services are good for. They are not good for developing applications – they are good for integrating applications. UML is a development tool, not an integration tool. I realize UML can be used to model integrations, and systems, and SOAs, etc. But let’s face it, the modeling language was designed for use with executable software systems, not for use with an XML contract representing the integration of multiple domains, and is therefore not very well suited for it.
UML and MDA are great as productivity aids for the application developer – I can buy that. But just I can’t see how they are helpful for data-based Web services integration projects.

Clarification on UML/MDA

It just goes to show that I shouldn’t write about things I haven’t been keeping up with.
Apologies also for taking so long to respond. Last week was pretty hectic, and I was in catch-up mode all week after being sick the week before.
Stefan Tilkov takes me to task on my statements about the “grand vision” of MDA in the Graphically Yours posting.
I checked, and some of the more recent whitepapers and descriptions of MDA indeed talk about it more as a “productivity” tool than as a complete, end-to-end programming environment.
Some of the material on the OMG site still positions MDA as a solution for multi-platform interoperabilty through code generation. The troubles arise when people try to think about UML/MDA as an executable system, however, and that gets them to thinking everything can be done using heavily annotated diagrams.
A couple of years ago, when IONA was a bigger company and into MDA, and I had the pleasure of working with David Frankel, the vision for MDA included “using the modeling language as a programming language” – as Slide 33 of Dave’s presentation shows. Also check slides 3 and 22-27 for more about this original (or at least one-time) vision for MDA.
Though a strong proponent, Dave always acknowledged the MDA was subject to over-hype, and tried to present a balanced view, as he does in his book, which I’m very happy to recommend. But I think the vision as articulated at the time included the ability to work entirely in the graphical environment, abstracting completely the underlying execution environment, whatever it was.
On Stefan’s page he references his answer to Martin Fowler’s critique, but he also acknowledges the main point I was trying to make (and which Martin also makes), which is that pictures are just not going to replace words in software development.
My experience with UML-generated code seems to be in line with what Stefan is saying, and with a more practical view of UML and MDA that now seems to be emerging. I was running a COM+ architecture lab program at the time for Compaq services. We started with UML to capture the use cases and create the initial class diagrams, from which we generated the initial VB skeletons. However, once we got into the code we never went back to the diagrams. True round-tripping, as far as I know, remains an unrealistic goal.
The current thinking about modeling tools seems to be that they are not intended to completely replace coding, as Stefan says, but to generate as much code as possible. It’s good to see a more realistic view being promoted nowadays, and yes, if I’d been aware of this shift I would certainly not have taken the old vision to task.
A recent statement from Bill Gates is interesting in this light, including the observation that UML is too complex (which I agree with for what it’s worth), although modeling is definitely the future. He includes Web services in the picture by saying that you need modeling for them.
I’m not sure about that, but I certainly agree that UML and MDA are not right for Web services, as I said. And I am sticking to that part of the original post!