Share via

What happened to the Service Model?

  • Article

I just looked at Mikael Håkansson’s blog article on building a Web Service Model using M and the Oslo Repository (https://blogical.se/blogs/mikael/default.aspx ) It’s a very nice article. As Mikael observes, the Service Model we shipped in January was removed from the May CTP. His article correctly points out that such a model allows the repository to store all configuration information for live services.

Here’s some background as to why it was removed. First, the Service Model in M was derived from another model we shipped at PDC/January – the Application Model. Those who downloaded that CTP might recall that this model allowed a “logical” description of composable components that communicated with one another via contract-bearing “ports”. The web service model bindings and configuration information was, in effect, a platform-specific extension to the platform-independent component collaboration model.

As I pointed out in an earlier posting , we elected to move to the increasingly accepted UML2 model which offered an alternative platform-independent model of component collaboration to our original System.Application model shipped at PDC/January. Despite various well-known issues with the UML2 component/port metamodel (often fixed with specific UML2 profiles), we’ve generally had a warm reception from customers for our decision to switch to the effective industry standard.

In the May CTP, you can see the beginnings of the UML2 model we will support – in the next CTP this will cover the entire UML2 model. I fully expect you’ll see the old System.ServiceModel re-emerge as an extension to the UML2 model of components/ports either as a custom UML profile, or just a related M-based DSL, though I can’t say right now exactly when/how this will happen.

In a private communication, Mikael asked me which approach I’d favor:

A. Create a new model

B. Use the Microsoft.Uml2 model

C. Create a new ServiceModel deriving from the Uml2 model 

My first thoughts are I’d personally prefer to go with A since this would give a cleaner model with a natural representation of the concepts – I’m a big fan of custom DSLs. But given the widespread use of existing UML2 tools, I’d choose C if an organization was using existing UML2 tools that supported appropriate extension capabilities.