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.


6 responses to “UML/MDA — Not Well Suited for Web Services

  1. Web Services Integration Scenarios and UML

    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 domai…

  2. Eric Newcomer is blogging!!!

  3. I can’t believe you said “UML/MDA do not address a major requirement of Web services — data integration and reconciliation of semantics”.
    MDA is based on MOF, which is all about metadata and mapping between metamodels. And there is no reason at all why an MDA tool (or tool chain) should not create applications that cross domain boundaries. They just haven’t gotten around to it yet. Watch this space!
    Seems to me MDA is exactly what Web services need. While everyone pays lip service to SOA, and the merits of asynchronous, loose-coupled, message-oriented communication, 99.9 percent of Web service development today is synchronous, tight-coupled RPC. And that is because people
    start with what they’ve got, and use the nifty tools to generate WSDL from their existing classes and methods… thus whipping up fast-food
    autospaghetti – on which they will choke, in due course.
    There is a view that it is best to start with the network and the messages (and their schemas) and work outwards. Of course, that undermines the sales message that Web services = cheap/fast/easy. But if you do things that way, MDA is a good fit.

  4. I agree the potential is there, but you are also saying more or less what I’ve said, which is that the tools are not well adapted for use with Web services today. MDA could be, but it isn’t, and I am not sure it ever will be.
    I would very much like to see the tools adapted better to what you call “starting with the network and the messages” because I think it’s a big problem with respect to getting the real value out of Web services that the tools continue to focus on the “RPC-oriented” and “object-oriented” view of the world.
    But I just don’t see that happening anytime soon, do you?

  5. Will St Germain IV

    I am new to Web Services (as it is pretty new to the world). I feel that UML and CASE based application development and Systems Integration has been around for decades. UML tools are maturing, so much so that Rational can reverse engineer most databases and applications. MDA, as I understand it, allows for a UML model to be transformed into a datamodel thus enabling better forward engineering of UML. Your book, Understanding Web Services, by Eric Newcomer, is what brought me to this page. (namely Page 74)
    There is a reference of two data stores, one is the source, and one is the target. The mapping of the source and target data stores, which easily could be reverse engineered into UML, should not be proprietary guessing game. Web Services-XDI will be needed sooner then later!
    Hope this helps sway your opinion, or you could provide more arguements, besides complexity, on why it is not a good idea to document the mapping of two data stores using WSDL isn’t a good idea?
    Thanks, Will

  6. Will,
    My apologies for the delay in responding to you. I’ve been on the road a lot recently, on vacation, and trying to finish up the new book I’m writing with Greg Lomow.
    In reference to page 74 of my previous book, that shows an example of a visual tool designed to generate XSLT scripts for transforming an XML document from one schema format to another. XML document instances are distinct from their content models (i.e. schemas), and a document instance can have multiple content models associated with it. Similarly, a single document instance can be transformed into multiple content models, depending on the XSLT script(s) defined for it.
    This particular tool was designed to help companies receiving XML in one format transform it to a format they recognize. For example, a company might receive an XML document in RosettaNet format, and need to transform it to SAP format. The company’s developers would use such a tool to define an XSLT script to transform the incoming document (which might be in an industry standard or neutral format like RosettaNet, FMPL, HIPAA, etc.) into a format that the IT systems can deal with (such as SAP, Baab, PeopleSoft, or a custom internal format).
    This is a good example of a problem space that UML and MDA does not address. Perhaps it could, but then one has to ask why, since there are so many XML transformation tools already available for the purpose.
    I am not trying to argue against the usefulness of UML and MDA for certain purposes. This whole argument started because I said that UML and MDA are not likely to replace textual languages as the basis of all software development.
    During the very interesting and productive discussion that followed, I learned that my views of MDA were somewhat out of date. It is now being promoted more as a productivity tool than a complete development environment replacing all other languages. That’s good news, and much more realistic, in my view.
    And the point about UML not being well-suited for Web services still stands, however. I realize that it is possible to use UML with Web services, and that adaptations of UML (and MDA’s subset of UML) are being developed and used for Web services and Web services orchestration (i.e. BPEL). However, to me this remains a bit like the old proverb of the round peg in the square hole. UML was designed explicitly for object-oriented development, and Web services are not object oriented.
    Let’s take’s Web services for example. publishes Web services in two formats: SOAP and WSDL, and plain XML over HTTP. How would UML support this type of Web services development? I don’t think it does.
    I can see UML being used for generating Web services for new object-oriented code, and that is a potentially interesting and useful application of UML. However, unless we (as a software industry) all recognize Web services and XML as something different, with a requirement for new and different development tools, we are not going to realize the true power of Web services and XML through their ability to represent any execution environment.
    If we limit our thinking about Web services and XML by viewing them in the context of familiar object oriented technologies and tools, we miss the point. And though these tools have some application to Web services, and some relevance to them, they do not address at least have of the current software world — the part that is not (and will never be) object oriented.