Eric Newcomer follows up on our discussion with regards to UML’s suitability for Web services.
First of all, Eric states that UML is not suited very well for Web services, since they are typically used for integration scenarios across application domains. The easy, MDA-zealot answer would be that of course you can UML for integration purposes. In fact there is a two-year-old, 304-page specification, the UML for EAI profile, that is explicitly aimed at this (it’s a bit out of date, with mappings just to MQ Series and JMS, but so what). I don’t have any experience with it, though, and I’m highly skeptical about publicly adopted UML profiles anyway; so I’ll avoid that easy answer.
I can follow Eric’s argument that basically, UML (not MDA ;-) ) has been designed to build new systems, not to integrate existing ones. Still, often you build a new system and need to integrate several existing ones into it. When you’re building a system today, you’ll also equip it with a Web services-enabled interface right from the start, and not add one later. In these cases, you need to do both “classical” as well as “service-based” development, and that is where I believe UML-driven Web service creation makes a lot of sense.
Even if this is not your use case, I’m not sure I agree that learning UML in order to use Web services is overkill. I’ll try to back that up with a nice example, stay tuned (I’ll need some spare time to do this, as well as to publish some information about the project I was referring to). It basically seems to boil down to the question whether you know one (Web Services or UML) already. Picture yourself not knowing either; what would be easier to understand — a UML class diagram, or an XSD/WSDL file?
When I’m not constrained by the borders of reality — i.e. when I stop thinking about what is actually usable today, and allow myself to think about what I believe would be ideal — I feel that it’s actually MOF that I would really love to be able to use, instead of “just” UML. With a MOF-based meta-CASE tool, the Web services world would have its own Service Modeling Language (SML™), perfectly suited to the task at hand, and easy to integrate with the rest.