Yes, I have been bitten with the modeling bug. It has been a challenging, yet interesting roller-coaster ride doing program management within different Oslo feature teams, particularly focusing on domains. Bill Gibson eloquently defines what it entails in building a domain over “Oslo” platform. I initially started out by investigating the provider/adapter story for Oslo and its integration with Visual Studio, but quickly moved on to working on creating new ‘concept’ domains using a new modeling language named “M”. With the future vision of modeling a BPM/SOA domain over “Oslo” platform, we had fragmented teams building different pieces of this end-vision.
My team worked on modeling Business Process Modeling Notation (BPMN) 1.1 and creating a prototype Microsoft Visio Add-In to load Microsoft Visio BPMN diagrams into the Oslo Repository. Just individual domains are not sufficient for a complete integrated IT end-to-end solution, there needs to be a web of interconnected domains that cross disciplines and role boundaries. The natural progression from BPMN in a typical BPM system is to transform it into an executable model such as Windows Workflow Foundation (WF) 4.0 or Business Process Execution Language (BPEL). I worked with .NET Framework team to define a WF/WCF model and my feature team extended “Quadrant” to demonstrate different viewers over the WF model including a Diagram Editor. At PDC 2008, we were successfully able to demonstrate creating a new WF model in Quadrant and deploying it in Microsoft code name “Dublin”. David Chappell captured this work in his October 2008 paper titled Workflows, Services and Models. The WF and WCF models were part of this overarching model called Application Model, which resembled loosely with the Component and Deployment models found in Object Management Group’s Unified Modeling Language (UML) Domain.
After PDC 2008, we made a call to focus on more infrastructure domains that can be then used iteratively in conjunction with or part of some broader domains including (but not limited to) domains such as BPM/SOA. We prioritized investing in an extensible modeling platform in early releases, while iteratively creating an eco-system for diverse domains over this platform. We reset our plans to start with more foundational domains such as UML and Common Language Runtime (CLR). These domains play a small yet important role in the end Microsoft Dynamic IT vision. Keith Short elaborates about Oslo and UML in his blog.
Dynamic IT is Microsoft’s long-term strategy for providing critical technologies that enable IT and development organizations to become more strategic to their businesses. A dynamic infrastructure is Microsoft’s vision for what an agile business looks like—a business in which IT works closely with business to meet the demands of a rapidly changing and adaptable environment. Dynamic IT is Microsoft’s technology strategy for products and solutions that help businesses enhance the dynamic capability of their people, processes, and IT infrastructures.
“No one can whistle a symphony. It takes an orchestra to play it.” (H. E. Luccock). Ultimately, many inter-related domains with appropriate tooling need to come together to provide an environment for different personas involved in building IT solutions for their businesses. The following diagram shows a web of interconnected domains that are required to fully realize Dynamic IT strategy. UML and CLR domains fit in the left box close to a Developer and Application Architect personas.
In May CTP of Oslo, you can find a subset of OMG UML 2.1.2 model specification modeled in M, along with a utility tool called LoadUml.exe that lets you load UML Class Models from an XMI 2.1 file. I have created an Eclipse plug-in that calls LoadUml.exe executable from within Eclipse Ganymede Modeling Tool Platform and loads the Eclipse UML2 semantic model into the Oslo Repository. If there is enough interest, I can share the plug-in with you. Currently the UML team is on the path to complete the modeling of entire OMG UML specification up to L3 Compliance Level for RTM. Also, the team plans on providing an XMI Loader to load UML2 model instances into Oslo Repository and an XMI Exporter to serialize UML2 model instances from Oslo Repository as XMI. We are also planning a sample transform feature between CLR and UML domains.
In most of our references to UML Domain, we are thinking beyond the static diagrams that are created to communicate the design which then gather ‘dust’ after the system is built. We think of the UML Domain as the conceptual/abstract model over the runtime models that represent the actual running business application.
We are in the early phases of building this domain. We are very interested in hearing your feedback and incorporating the results in our next CTP. Are you an ISV who provides UML Tools as part of a suite of designing and developing software? Do you think you can benefit by having a repository under the covers that gives you more granular access over each UML model element? What scenarios do you envision with respect to various domains and how can we help?