Jack Greenfield

XMI is a set of production rules that define how to generate a DTD or XSD from a MOF metamodel. There are several different versions of XMI in common use (1.0, 1.1, 1.2 and 2.0). Each version yields a different DTD or XSD from a given MOF metamodel.

 

Next, there is the question of MOF. There are several different versions of OMG MOF in common use (1.3, 1.4 and 2.0). There are also proprietary variants of the OMG MOF that are not OMG compliant, including CMOF, JMOF (Sun) and EMOF. IBM uses eCore, which is a proprietary variant of EMOF. We do not expect practical standardization at the MOF level by commercial tool vendors, since the MOF is too intimately tied to the tool architecture. Like everyone else who builds tools, we have our own MOF called IMS.

 

In practice, we expect to be able to import models based on metamodels based on other MOFs, using either something like a custom XSLT transformation before the model is imported, or a custom deserializer in our tools that performs the mapping during the model import.

 

Next, there is the question of the metamodel. There are many different metamodels that could be described using one of those MOFs and then rendered into XSDs using one of those XMI versions. UML is one of them. CWM is another. MOF itself is another. SPEM is another. Of course, all of these are versioned, as well. There are several versions of UML in common use (1.3, 1.4, 1.5 and 2.0).

 

Given the number of combinations of XMI, MOF and metamodel version, it will be necessary in some cases to write custom XMI importers for specific models written out by specific tools.

 

Of course, importing XMI implies not only that we can read the XML, but that we have something to map it to. We are not planning to implment all of UML. I don't know of anyone who does today, including IBM.

 

That said, we do expect to deliver some base DSL metamodels that approximate some of the UML diagram types, such as state chart, activity graph and sequence diagram, and we plan to support migration of existing UML models into our tools as instances of those metamodels. It won't be a push button, however, for the reasons mentioned above.

 

Finally, there is the question of profiles, which are collections of stereotypes and tags that people have defined to essentially approximate DSLs by marking up existing UML diagrams. XMI does not help at all with profiles, since the stereotypes and tags are not true MOF metaclasses and metaattributes, respectively.

 

We also plan to support migration of existing UML profiles into new DSL metamodels, and migration of existing UML models based on those profiles into our tools as instances of those metamodels. These tasks won't be push button, either, but will hopefully be supported by a well defined authoring experience (e.g., start with a DSL metamodel that approximates the UML diagram type on which the profile is based, then add/remove/modify metaclasses as necessary to make it a suitable target for importing models based on the profile, then define a custom XMI deserialization for reading models based on the profile from a specific tool).

 

Sorry for the long answer, but it reflects the reality behind the marketing promises about XMI.

2. We agree that UIP is an excellent architecture for application front ends.

Our approach to model driven development is called Software Factories. You can read about it at http://msdn.microsoft.com/architecture/overview/softwarefactories/.

Differences between SFs and MDA are summarized on my blog, and by my post on the Server Side at http://www.theserverside.net/news/thread.tss?thread_id=30082.

In a nutshell, you can think of SFs as MDA and more. What we have in common is the idea of generating code and less abstract models from more abstract models. The differences are in the "more", which deals with all of things that we think are critically important to making model driven development a practical reality, such as integrating code and models effectively, partitioning models into files that work well in configuration management scenarios, and so on.

As for using Software Factories for UIP, we have the pieces of the solution, but we can't yet offer you a way to pull them together. You can build a UIP designer using the DSL tools (http://labs.msdn.microsoft.com/teamsystem/workshop/dsltools/). You can use the UIP block from PAG, as you've already discovered. You might also write some templates and wizards that create a UIP project in an existing solution and then provide additional short cuts in building the pieces you need to work with the application block.

Of course, putting all of these pieces together to provide integrated guidance to your developers is what Software Factories are all about. We're working on tools that will help you combine pieces of guidance into packages and automate their installation and deployment. We'll have more to say about that later.

3. Not sure I follow your question here.

4. Great question. We have technologies that automate the construction of the UI and the database, but the middle tiers remain untamed territory. We're actively working on technology for modeling service oriented architectures, where the middle tier becomes the focal point of the system, and the UI and database become peripheral parts. The Application Designer and Systems Designer in VS 2005 are down payments on our long term solution in this space.

5. Regarding Java to .NET Migration, we have developed an online workshop is designed to help Java developers become acquainted with the Microsoft platform by using their Java skill set as a frame of reference for learning Microsoft .NET development.

This course can be completed for free, online, and at your own pace. It consists of video presentations, downloadable class notes, and hands-on labs which are supported by the MSDN Virtual Labs infrastructure. Topics include skills mappings (i.e. "I know how to use RMI – how does .NET Remoting work?") as well as code migration (i.e. "I have a piece of Java code I want to migrate to the .NET Framework – how do I use J# or the JLCA to move it over?").

To access this workshop, visit: http://msdn.microsoft.com/vstudio/java/migrate/workshop.

Cheers,
Jack Greeenfield | Architect | Enterprise Tools | Visual Studio