Skip to main content
Jump to: navigation, search


Revision as of 14:58, 15 February 2007 by (Talk | contribs) (first draft)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Newbie /General

What is EMF?

The <a href="">Eclipse Modeling Framework</a> is a Java/XML framework for generating tools and other applications based on simple class models. EMF helps you rapidly turn models into efficient, correct, and easily customizable Java code. It is intended to provide the benefits of formal modeling, but with a very low cost of entry. In addition to code generation, it provides the ability to save objects as XML documents for interchange with other tools and applications. Models can be created using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. The code generator turns a model into a set of Java implementation classes. These classes are extensible and regenerable - you can modify them by adding user-defined methods and instance variables. When the model changes, you can regenerate the implementation classes, and your modifications will be retained. This works both ways - changes in the Java code can be used to update the model.

How do I get started with EMF?

Start by reading the <a href="">overview documents and the tutorials</a>, followed by <a href="">downloading the driver</a>.

After going through the tutorial, you will have generated a completely working editor from nothing but a picture of the object model (i.e., the simple libarary model shown in the tutorial). If you run the generated editor, you can add and remove books and authors, edit the properties (e.g., the book title), copy, paste, drag-and-drop, etc. All with unlimited undo/redo. You can also save the document (the default framework serialization format is XMI).

The purpose of the tutorial is to illustrate the power of a model driven architecture (MDA). By providing a model for the data your application will manipulate, you can use EMF to generate a Java implementation for you. EMF.Edit can leverage the same model (meta) data to generate view support and even a working editor. Read the overview documents for more details.

What version of Eclipse do I need for EMF, SDO and XSD? Which EMF version will run on my Eclipse version?

The most recent version requirements and bleeding edge information about requirements can be seen on the EMF Downloads page.

EMF 2.2.x run on Eclipse 3.2.x.

EMF 2.1.x run on Eclipse 3.1.x.

EMF 2.0.2 through 2.0.5 run on Eclipse 3.0.2.
EMF 2.0 & 2.0.1 run on Eclipse 3.0 & 3.0.1.

EMF 1.0 & 1.1 run on Eclipse 2.0 & 2.1.

Are there any "real" example EMF models in Eclipse?

Well, for starters, EMF itself contains two interesting models. The Ecore model serves as the meta-model for any EMF model you create -- it is the model that describes the structure of your models. The Genmodel controls generation of an EMF model. In fact, the generator UI that is used in the tutorial is the EMF.Edit editor for the Genmodel, which explains why it looks so much like the library editor in the tutorial. If you want to explore Ecore and Genmodel further, you'll find their Rose models and Java code in the EMF source package available on our download page. Of course, the code produced by the EMF generator is meant to be a starting place, so you'll see that much functionality has been manually added to both of these models. But, it's quite easy to see the same sort of generated patterns that appear in the simple library example. Ecore is in the org.eclipse.emf.ecore plugin, the Genmodel is in org.eclipse.emf.codegen.ecore, and its editor UI is in org.eclipse.emf.codegen.ecore.ui. You'll find the Rose models in the "model" subdirectory of the source for the former two plugins.

Finally, an even more complex example of an EMF model is XSD, the <a href="">XML Schema Infoset Model</a>, a subproject of the Eclipse Technology Project. XSD models the concrete and abstract relationships expressed in an XML schema document, providing an API to manipulate the model and an XML-schema-specific replacement for EMF's default XMI serialization. Of course, there's also an EMF.Edit-based XML schema editor built on it.

How does EMF perform in regard to serializing to relational databases? I am wondering if this framework suits central repository servers, where hundreds of thousand of instances are present. When is it mandatory to have a relational database as the EMF's object serialization target?

There is no out of the box EMF support for RDB persistence, but several people have done or are doing such things themselves. It involves customized resources, or in the case of SDO - mediators. See also <a href="">CDO</a> and <a href="">Teneo</a>.

If using EMF in a non-Eclipse environment is feasible (licensing issues), what if any, advantages does using EMF have over using JAXB?

EMF and XSD are definitely intended to support standalone execution outside of Eclipse.Only the EMF jars are needed for standalone execution (as described in the FAQ).Within IBM, you should discuss licensing issues with the WSWB folks, since that's the supported distribution vehicle for EMF and XSD within IBM.I don't believe there are any issues as long as you stick to using released (i.e., supported) drivers.

JAXB produces a simple Java API given an XML Schema and it does so using essentially a black box design.EMF produces an Ecore model given an XML Schema and then uses template-based generator technology to generate a rich Java API (of hand written quality).The XML Schema to Ecore conversion can be tailored, the templates used to generate the Java API can be tailored, and the resulting Java API can be tailored.The generator supports merging regeneration so that it will preserve your hand written changes.In other words, EMF is far richer and more flexible, and supports a broader subset of XML Schema (especially in 2.0, where wildcards and mixed content will be supported).


EMF is failing to load a resource. How can I make it recognize a non-standard archive URI scheme? Why does EMF fail to load resources when running on an application server or other specialized runtime?

EMF recognizes a couple of well known archive schemes, such as "zip" and "jar", so everything will work fine if the URI of an archived resource starts, for example, with "zip:".Although most applications probably use one of these recognized schemes, you may find that certain runtimes use a different one.For example, when running in the IBM WebSphere Application Server, Class.getResource(String) may return a URL with a "wsjar" scheme, like "wsjar:file:/C:/dev/ws/default/sample_app/xsd.resources.jar!/org/eclipse/xsd/".
By default, EMF will not recognize this as an archive URI and will fail to handle it correctly, probably resulting in multiple unregistered resources errors and/or null pointer exceptions. If you are facing this problem, you will need to change EMF's set of recognized archive schemes. This is done by defining a property named "org.eclipse.emf.common.util.URI.archiveSchemes", whose value is the desired space-separated list of archive schemes.Here's an example of how you could define it when invoking your Java application:

java MyApp -Dorg.eclipse.emf.common.util.URI.archiveSchemes="wsjar wszip jar zip"

Is there a built-in facility to check whether a given value is valid compared to the effective facets of its type?

To determine if a literal is valid with respect to a simple type, you can use either XSDSimpleTypeDefinition.isValidLiteral or XSDSimpleTypeDefinition.assess.

I have a simple model consisting of a root that contains a single EList of children.The child type contians several attributes.I would like to create a custom editor such that the model is completely displayed in a table.How should I start?Overload getText() on the child item provider, and just return null for a propery descriptor?

Try working within the generated editor and updating the tab with existing table viewer support there until you have it working nicely. You might want a plain table or a table tree.You can add some more columns in the editor for the table/table tree and then use your item provider's implementation of ITableItemLabelProvider to populate the additional columns.Property descriptors will only be used when they are needed, so you don't have to do anything to hide them.

How big a job would it be to get the EMF editor generator to spit out Swing editor code instead of SWT/JFace code?

You'd want something similar to org.eclipse.emf.edit.ui, but for binding the platform independent .edit support to Swing instead of to Eclipse, and you'd want to replace the editor templates with stuff for Swing. It's not a trivial task, but not a huge one either.

Are there any examples of EMF used standalone?

Yes, definitely. In fact, SDO (Service Data Objects) is a standalone application of EMF. <a href="">Javadoc</a>, <a href="">Download</a>.

Is it possible to convert back from EMF model (ecore files or generated Java code?) to UML?

It's possible in theory, but we don't have anything like the working in practice.It shouldn't be too difficult to do the Ecore to UML2 conversion using Eclipse's EMF-based UML2 model.

Check the uml2 newsgroup. They may have plans or already have an Ecore model importer.

As of EMF 2.0.0.I20040408, it seems like the code templates in chapter 14.2.3 in the emf-book needs to be rewritten. Is this already done and published somewhere?

The existing mechanisms should continue to work, but will result in deprecation warnings for 2.0. The framework was generalized so that a number of places where only EReference was supported, now EStructuralFeature is supported. It would certainly be a FAQ worthy addition to outline the places where such changes would be made.

Can I link parts of UML diagrams to portions of the code in the EMF editor?

Yes, but the <a href="">UML2 project</a> should be able to provide you with most of the "model" code that you need, and the <a href="">GEF project</a> will give you a huge head-start when it somes to creating the "view" and "controller" bits.

I would guess that the best approach when it comes to linking your model and code would be via the JET framework which is part of EMF, this will handle most of the merging issues for you.

Is there an electronic version of the EMF book?

There's an IBM "RedBook" on GEF which also has some chapters on EMF in it, it's a free download at <a href=""></a>.

You can buy an electronic copy of the book here: <a href=""></a>.

===Is there a clean way to use an EMF model's generated editor in a standalone application?

The .edit projects can be used standalone (although you'd need to put the and icons into a resource jar), but the .editor projects are tightly integrated Eclipse components that will only function within an Eclipse environment.

For more information on working outside Eclipse, see the question "<a href="faq.php?Question=standalone#dev20040401-2098357246">How do I use EMF in standalone applications (such as an ordinary main)?</a>".

I want to use EMF, SDO, or XSD in my standalone project, or include only a working subset of the code. What libraries (jar files) do I need in my CLASSPATH?

Eclipse Modeling Framework (EMF) provides the infrastructure to run the generated models and dynamic model based on existing ecore files. It also provides XMI/XML serialization and deserialization.

The following jars can be used in standalone mode. Jars are found under the plugins directory of your Eclipse installation - there will be a release number appended to the plugin name, e.g. org.eclipse.emf.common_2.1.0.

Add to the following jars to your CLASSPATH or copy them into your project. This includes, but is not limited to:

  • org.eclipse.emf.common/runtime/common.jar
  • org.eclipse.emf.common/runtime/common.resources.jar (needed at runtime, not at compile time)
  • org.eclipse.emf.ecore/runtime/ecore.jar
  • org.eclipse.emf.ecore/runtime/ecore.resources.jar (needed at runtime, not at compile time)
  • org.eclipse.emf.ecore.change/runtime/ecore.change.jar
  • org.eclipse.emf.ecore.xmi/runtime/ecore.xmi.jar (requires SAX parser - <a href="#20050114-120205-note">see note below</a>)

Service Data Objects (SDO) is an API specification in the format of Java interfaces and the EMF implementation that requires the EMF jars above and the following jars to be used in standalone mode:

  • org.eclipse.emf.commonj.sdo/runtime/commonj.sdo.jar
  • org.eclipse.emf.ecore.sdo/runtime/ecore.sdo.jar

XML Schema Infoset Model (XSD) is a reference library for use with any code that manipulates XML schemas and requires the EMF jars above and the following jars to be used in standalone mode:

  • org.eclipse.xsd/runtime/xsd.jar
  • org.eclipse.xsd/runtime/xsd.resources.jar (needed at runtime, not at compile time)
  • org.eclipse.xsd.test/runtime/xsd.test.jar

<a name="20050114-120205-note"></a>NOTE: If using ecore.xmi or any of the XSD jars, you will require a SAX parser such as <a href="" target="_xerces">Xerces</a>.

For more information on working outside Eclipse, see the question "<a href="faq.php?Question=standalone#dev20040401-2098357246">How do I use EMF in standalone applications (such as an ordinary main)?</a>".

Does it matter what node in the genmodel tree I invoke Generate from?

Definitely. To do a full generation, you need to invoke "Generate" or "Generate EMF.Edit" from the root node in the genmodel editor. If you invoke Generate lower down, you'll only generate the files associated with the selected subtree.

Can model classes be in the Java default package?

No. EMF does not allow model classes to be in the default Java package because it would need to be handled specially in the code generator, and since it's not a good Java convention anyway, we don't think it is worth supporting. Make sure that if you load your model from annotated Java that all the interfaces and classes with an @model tag also have an explicit package declaration.

Can annotated Java files use * imports?

Currently no. Until our Java name lookup mechanisms are improved, we really rely on explicit imports to resolve names, i.e., two * imports would confuse the code. It's best to entirely avoid * imports for the time being. We will improve identifier lookup in the coming weeks.

Does regeneration/merge work for properties and plugin.xml files?

Not yet. The current generator does not support merge for the and plugin.xml files, so it will not overwrite them if they exist. If you want to regenerate them, you'll need to remove or rename them before regenerating. This will also be improved in the future.

How do I use EMF in standalone applications (such as an ordinary main)?

An EMF model can be used without change in a standalone application with couple of exceptions.

Default resource factories are not registered in the standalone EMF environment. Therefore, for each file extension or scheme your application wants to load or save, you need to register the corresponding resource factory. For example, to load and save XMI documents, add a line similar to the one below to your main program:

Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("library", new XMIResourceFactoryImpl());

To load and save XML documents, register the following factory:

Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("xml", new XMLResourceFactoryImpl());

In the above examples, the model is registered using the global static resource factory registry instance. You can also register factories local to the ResourceSet being used, e.g:

ResourceSet rs = new ResourceSet();
rs.getResourceFactoryRegistry().getExtensionToFactoryMap().put(("xml", new XMLResourceFactoryImpl());

In addition, you'll also need to register your package, which happens as a side effect of accessing XyzPackage.eINSTANCE. For example, to register the library model, add the following line to your main program:

LibraryPackage packageInstance = LibraryPackage.eINSTANCE;

You need to add to the CLASSPATH all the jars for the plugins (and their dependent plugins) that you want to use standalone. The list is dependent on exactly what plugins you want to use and is available by looking at the runtime libraries in their plugin.xml files. This includes, but is not limited to:

  • org.eclipse.emf.common/runtime/common.jar
  • org.eclipse.emf.common/runtime/common.resources.jar
  • org.eclipse.emf.ecore/runtime/ecore.jar
  • org.eclipse.emf.ecore/runtime/ecore.resources.jar
  • org.eclipse.emf.ecore.xmi/runtime/ecore.xmi.jar

The jars are found under the plugins directory of your Eclipse installation. There will be a release number appended to the plugin name, e.g. org.eclipse.emf.common_2.1.0.

For EMF.Edit you would also have to add the following jar files to your classpath:

  • org.eclipse.emf.common.ui/runtime/common.ui.jar
  • org.eclipse.emf.common.ui/runtime/common.ui.resources.jar
  • org.eclipse.emf.edit/runtime/edit.jar
  • org.eclipse.emf.edit/runtime/edit.resources.jar

Also, to produce the right .jar file for standalone execution of a generated project, you need to copy the file and the icons directory to the directory containing the EMF XyzPlugin for the project. This will put the resources in just the right place to be found by the generated XyzPlugin during standalone execution. Such a project will work as both a plugin and for standalone execution.

I get a PackageNotFoundException: e.g., "Package with uri ? not found." What do I need to do?

When an EMF model instance (or SDO data graph) is loaded from its serialized form, the resource needs to obtain the correct metamodel, which is to be instantiated. The metamodel, represented by EMF as an EPackage, must be available (either in memory, or in serialized form), and EMF must be able to locate it from its namespace URI, which appears in the serialized model instance.
There are number of different ways this can occur, depending on a number of factors:

  • Static or dynamic: static means code has been generated at development time to implement the model; dynamic means no code has been generated and the metamodel is built in memory.
  • Eclipse or stand-alone: you may be running your code under or outside of Eclipse. The latter is referred to as stand-alone.
  • EMF or SDO: you may be using non-SDO EMF, or SDO.

When using static SDO stand-alone, it is recommended to follow the instructions described under "Do I have to pre-register my static, generated package when running stand-alone (outside of Eclipse)?"

If you are using static EMF, the generated package interface (e.g. CompanyPackage) will include a static field called eINSTANCE. Accessing this field will cause the package to be initialized and registered in the global package registry, allowing any resource to locate it. For example, the following code accesses the eINSTANCE field of CompanyPackage:

CompanyPackage packageInstance = CompanyPackage.eINSTANCE;

When running under Eclipse, this step is unnecessary, as a plug-in manifest file drives automatic package registration.

In SDO, the package can be included in the serialized data graph, along with the instance data that requires it. This is one option with dynamic, for example. To do so, refer to "How do I serialize the model of an SDO data graph?"

To register a dynamic model, refer to "How do I register a dynamic package?" Alternatively, the metamodel can be automatically loaded from its serialized form. For details, refer to "Do I have to initialize and pre-register my dynamic packages?"

Do I have to pre-register my static, generated package when running stand-alone (outside of Eclipse)?

No. Use the OPTION_SCHEMA_LOCATION_IMPLEMENTATION option to avoid pre-registration of your generated packages. This is the recommended approach to using static SDO.

When a model instance is saved with this option set, an xsi:schemaLocation attribute will be added to the document element, associating the package's namespace URI with the qualified name of the generated package interface. When the package is needed at load-time, the eINSTANCE field of that interface will be reflectively accessed to obtain it.

The following code shows how to set the option in the resource associated with an SDO data graph:

((XMLResource)eDataGraph.getDataGraphResource()).getDefaultSaveOptions() .put(XMLResource.OPTION_SCHEMA_LOCATION_IMPLEMENTATION, Boolean.TRUE);

How do I register a dynamic package?

In order for EMF to locate a dynamic package that has been built up programmatically, it must be registered in a package registry. For example, the following code globally registers companyPackage:

EPackage.Registry.INSTANCE.put(companyPackage.getNsURI(), companyPackage);

Each resource set has its own local package registry, which is consulted before the global registry. To avoid collisions, you may prefer to register the dynamic package locally, instead of globally:

ResourceSet set = new ResourceSetImpl();
set.getPackageRegistry().put(companyPackage.getNsURI(), companyPackage);

Do I have to initialize and pre-register my dynamic packages?

No. The package needed to load a model instance will be automatically loaded from its serialized form, if available.

The simplest approach is to use an accessible URL as the package's namespace URI, and to make the package serialization available at that location (for example, via HTTP). If found, the package will be loaded with no additional effort.

If the package is available at a different physical location, whether public or on the local filesystem, you can serialize the model instance with the OPTION_SCHEMA_LOCATION to include that location, so that it can be found at load-time.

First, create a resource and add your package to it. For example:

ResourceSet set = new ResourceSetImpl();
Resource packageResource = set.createResource(URI.createURI("file:///c:/data/company.ecore"));

Then, use the OPTION_SCHEMA_LOCATION when you serialize your model instance:

Resource resource = set.createResource(URI.createURI("file:///c:/data/company.xml"));
Map options = new HashMap();
options.put(XMLResource.OPTION_SCHEMA_LOCATION, Boolean.TRUE);;

This adds an xsi:schemaLocation attribute to company.xml, associating the company package's namespace URI with the physical URI "company.ecore" (this relative URI is automatically computed, allowing the two files to be relocated, together).

Is there a built-in facility to check whether a given value is valid compared to the effective facets of its type?

To determine if a literal is valid with respect to a simple type, you can use either XSDSimpleTypeDefinition.isValidLiteral or XSDSimpleTypeDefinition.assess

===I'm generating EMF models from xsd files. To generate relations between entities I use the following syntax, with the ecore:reference attribute on xsd:element. ...


<xsd:complexType name="Writer">
<xsd:element name="name" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0"
name="books" type="xsd:anyURI" ecore:reference="lib:Book"/>

But I have to generate this XSD schema and for this I need the schema that defines the ecore namespace. Where can I find this schema?

I don't think you actually need it in order to generate a schema like the one below.The XML Schema spec defines the wildcard for these "non-schema namespace attributes" like this:

<xs:anyAttribute namespace="##other" processContents="lax"/>

so no schema needs to exist for that namespace in order for the schema to be valid, you only need to ensure that the prefix is defined.

I have an element that comprises four sub-elements derived from type <xs:string>. How can I examine the contents of an <xs:complexType>? How could I programmatically determine its restrictions/enumerations/etc.?

Here's snippet of code that does some of the things you mention:

void handle(XSDElementDeclaration xsdElementDeclaration)


XSDTypeDefinition xsdTypeDefinition = xsdElementDeclaration.getTypeDefinition(); if (xsdTypeDefinition instanceof XSDSimpleTypeDefinition) { XSDSimpleTypeDefinition xsdSimpleTypeDefinition =


for (Iterator i = xsdSimpleTypeDefinition.getFacets().iterator();

i.hasNext(); )


XSDFacet xsdFacet = (XSDFacet);
if (xsdFacet instanceof XSDEnumerationFacet)

for (Iterator j = ((XSDEnumerationFacet)xsdFacet).getValue().iterator(); j.hasNext(); ) { Object enumerator =; }

else if (xsdFacet instanceof XSDPatternFacet)
// ...

} } else { XSDComplexTypeDefinition xsdComplexTypeDefinition =


switch (xsdComplexTypeDefinition.getContentTypeCategory().getValue()) {

case XSDContentTypeCategory.EMPTY:


case XSDContentTypeCategory.SIMPLE:

XSDSimpleTypeDefinition xsdSimpleTypeDefinition = (XSDSimpleTypeDefinition)xsdComplexTypeDefinition.getContentType(); break;

case XSDContentTypeCategory.ELEMENT_ONLY:
case XSDContentTypeCategory.MIXED:

XSDParticle xsdParticle = (XSDParticle)xsdComplexTypeDefinition.getContentType(); XSDTerm xsdTerm = xsdParticle.getTerm(); if (xsdTerm instanceof XSDModelGroup) { XSDModelGroup xsdModelGroup = (XSDModelGroup)xsdTerm; for (Iterator i = xsdModelGroup.getParticles().iterator();

i.hasNext(); )


XSDParticle childXSDParticle = (XSDParticle);

} } else if (xsdTerm instanceof XSDElementDeclaration) { } else if (xsdTerm instanceof XSDWildcard) { } break;


} }


How does setIncrementalUpdate() work?

You can use XSDSchema.setIncrementalUpdate(false) to turn off the expensive global updates and set it back to true, or call XSDSchema.update(), afterwards. Calling update() does not cause setIncrementalUpdate(true). Attached to this state is the warning that names will no longer be re-resolved and non-concrete relations will no longer be recomputed.If you aren't relying on these to drive your actions, it won't matter.

How can I load a XSDSchema from a simple Java String or from a DOM Tree?

Assuming you do something much like what's in XSDMainTest in org.eclipse.xsd.test, this should do the trick:

ResourceSet resourceSet = new ResourceSetImpl();
XSDResourceImpl xsdMainResource =
if (fromString)
xsdMainResource.load(/* ByteArrayInputStream created from
String */, resourceSet.getLoadOptions());
XSDSchema xsdSchema =
xsdSdchema.setElement(/* your <schema> element */);

How do I convert code that runs in an Eclipse environment to a standalone environment?

In an Eclipse environment the EPackage.Registry.INSTANCE is populated at startup time by the registrations of the models in the plugin.xml, e.g.,

uri = ""
class = "org.eclipse.xsd.XSDPackage" />

But in a standalone environment, this doesn't happen, so you need to register each package explicitly.

If you have a package Xyz, accessing XyzPackage.eINSTANCE will create the package and register it in the registry.

So if you add the line XyzPackage.eINSTANCE.getEFactoryInstance() to your initialization code, the Xyz package will be properly registered.

Downloading EMF

How do I install EMF 2.x (for Eclipse 3.x)?

<a href="">Download</a> the version of EMF, SDO and/or XSD that matches your installation of Eclipse. Generally, the version of Eclipse is one version greater than that of EMF; eg., EMF 2.3 is build against (and for) Eclipse 3.3. Exit Eclipse, then unzip into your Eclipse directory.

How do I install EMF or XSD 1.x for Eclipse 2.x?

<a href="">Download</a> the version of EMF and/or XSD that matches your installation of Eclipse. Exit Eclipse, then unzip into your Eclipse directory.

How do I get EMF, SDO or XSD source from CVS?

See <a href="">Getting EMF, SDO and XSD from CVS</a>.

Does EMF, SDO or XSD have a site that I can use with the Eclipse Update Manager?

Yes, as of June 21, 2004, there is an Update Manager site for EMF, SDO, and XSD.

This is only for the 2.x+ stream, not the 1.1.x stream.

IBM Internal can use:

The rest of the world can use:

If you're not familiar with Update Manager, surf to one of the above URLs and read the instructions there.

Please note, however:

  • You cannot upgrade from EMF 1.x to EMF 2.x, since you must also upgrade versions of Eclipse (2.x -> 3.0).
  • If you install a stable, integration build of EMF, such as 2.0.0.I200406211000, when EMF 2.0.0 Final is launched, UM will consider this to be an OLDER version, rather than a newer version. So, if you wanted to use UM to stay abreast of changes between Eclipse 3.0 Milestones, when 3.0 Final was launched, you'd have to download EMF manually and remove your 2.0.0.yyyymmddhhmm version manually anyway. The same problem exists with updating Eclipse itself via UM to 3.0.0.yyyymmddhhmm - once 3.0.0 is launched, you won't be able to use UM to upgrade the the Final version, since 3.0.0 < 3.0.0.yyyymmddhhmm. However, we're planning to drop a new UM site build for every zipped build, so you should be able to continue to upgrade without having to download zips manually.

Modeling Standards

What is Model Driven Architecture (MDA)?

MDA is an industry architecture proposed by the OMG that addresses full life cycle application development, data, and application integration standards that work with multiple middleware (CORBA, J2EE), languages, and interchange formats. MDA unifies some of the industry best practices in software architecture, modeling, metadata management, and software transformation technologies that allow a user to develop a modeling specification once and target multiple technology implementations by using precise transformations/mappings.

An example of the use of MDA is to use a UML model representation of a tool or application and to use this model to automate (some or all) of the Java interface, implementation, as well as any XML serialization for the modeled objects. Many of the recent OMG standards such as UML, MOF, and CWM were developed using MDA principles of using abstract models (these are also referred to as Platform Independent Models - PIM) which can be mapped to Platform Specific Models (PSM). Please note that 'platform independent' is a relative term!

or more information on MDA and related MDA specifications including UML, XMI, and MOF, please visit

Does EMF support OMG XMI?

EMF uses OMG XML Metadata Interchange (XMITM) 2.0 as the default XML serialization format for Ecore models and Ecore instances. The EMF framework allows the use of other serialization formats also. The XMI 2.0 document production rules are used because of more compact representation than XMI 1.2.

Can I create an EMF model using OMG XMI?

Yes. The XMI document that conforms to the EMF Ecore model can be directly edited using your favorite text or an XML editor. Alternately you can use a modeling tool that can produce the XMI document from a UML model. You can also use annotated Java interfaces to define your input model.

Can I create an EMF model using UMLTM modeling tools?

EMF models can be defined using UML modeling tools such as Rational Rose. You simply define a class model with the packages, attributes, references, data types, and operations. This class model can be imported into EMF for additional code generation. Since many Java developers are familiar with simple class modeling, this serves as a 'gentle introduction' to UML class modeling. In addition to UML class models, EMF models can be created by using annotated Java interfaces or by directly editing an XMI document using an XML editor. This approach is used to allow the benefits of model based code generation (one of the principles of the OMG Model Driven Architecture - MDA) to not just users familiar with UML, but also the larger community of developers using Java and XML.

What is the relationship of OMGTM MOFTM to the EMF Ecore model?

The OMG MOF 1.4 Model has influenced the design of the EMF Ecore model. The Ecore model evolved in parallel with the MOF 1.4 model. Implementation experience in integrating a number of tools led to an optimized implementation (focused on tool integration as opposed to the original MOF focus of metadata repositories) that uses a subset of the modeling concepts in MOF 1.4. For example, Ecore does not support 'first class' Associations. Associations are mapped to a pair of Ecore References. To minimize confusion, we have used the term 'Ecore' to refer to the object model in the EMF framework. We use the terms 'Ecore model' and 'EMF model' interchangeably in this FAQ, because the object model of the Eclipse EMF framework is the Ecore model.

The designers of EMF are participating in the OMG process to influence the design of MOF 2.0 and UML 2.0, which are still being defined.

What is the relationship of EMF to OMGTM MDATM?

One of the key goals of EMF is to use simple visual models to allow easy integration of Java and XML tools. To accomplish this you can use a UML class model as input to the EMF framework. This model is then used to drive Java interface and implementation generation for EMF instances. These Java interfaces define a consistent programming model for tools built using EMF. The same EMF model is also used to generate the XML serialization (XMI 2.0 format) for EMF instances. Essentially EMF supports the key MDA concept of using models as input to development and integration tools which produce multiple programming language (Java in the case of Eclipse EMF itself) or data interchange format (XML) representations. The code generation and XML serialization is 'driven' from the same model.

EMF supports OMG XMI 2.0 XML serialization format and the use of UML models for the analysis and design of EMF models.

What is the relationship of EMF to JMITM?

JMI (JavaTM Metadata Interface) is a mapping of the OMG MOF 1.4 to the Java language developed by the Java Community Process. The JMI spec and the Eclipse EMF model to Java mapping were developed in parallel and are not the same. The Eclipse EMF Java mappings have been optimized for in memory tool integration using Java and XML while JMI has been optimized for metadata repository usage scenarios. Eclipse EMF designers are actively involved in the ongoing development of MOF 2.0 and related mappings to XML and Java that are expected to proceed in the OMG and Java Community Process respectively.

Service Data Objects (SDO)

What are Service Data Objects (SDO)?

Service Data Objects (SDO), previously Web Data Objects (WDO), is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems. For more information about the goals and architecture of SDO, see the whitepaper "<a href="" target="_dw">Next-Generation Data Programming: Service Data Objects</a>."

SDO is based on the concept of disconnected data graphs. A data graph is a collection of tree-structured or graph-structured data objects. Under the disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and can then apply the data graph changes back to the data source. <a href="" target="_dw">More...</a>

What is the relationship between SDO & WDO?

Web Data Objects, or WDO, is the name of an early release of SDO shipped in IBM WebSphere Application Server 5.1 and IBM WebSphere Studio Application Developer 5.1.2. If you've spent any time with WebSphere Studio 5.1.2, you should already be somewhat familiar with SDO, although you're probably accustomed to seeing it denoted as WDO, for example in library names. WDO is now called SDO.

What is the relationship between EMF & SDO?

EMF and SDO both deal with data representation. The SDO implementation is based on EMF and is essentially a thin layer (facade) over EMF. You can get SDO from the <a href="">Eclipse EMF Project Downloads page</a>.

How do I serialize the model of an SDO data graph?

It may be convenient to serialize the package in the data graph, along with the instance data that requires it. To do so, the package's resource needs to be added to the resource set of the data graph.

For example:

EDataGraph companyGraph = SDOFactory.eINSTANCE.createEDataGraph();
ResourceSet set = companyGraph.getResourceSet();
Resource packageResource = set.createResource(URI.createURI(companyPackage.getNsURI()));

At load-time, the package will automatically be located with no further effort.

What is the relationship between SDO & JDO?

JDO is a Java Community Process (JCP) standard and stands for Java Data Objects. JDO looks at data programming in the Java environment and provides a common API to access data stored in various types of data sources. JDO preserves relationships between Java objects (graphs) and at the same time allows concurrent access to the data.

JDO's goal is similar to SDO's in that it wants to simplify and unify Java data programming. The main difference, however, is that JDO looks at the persistence issue only (the J2EE data tier or enterprise information system (EIS) tier), whereas SDO is more general and represents data that can flow between any J2EE tier, such as between a presentation and business tier.

SDO can be used in conjunction with JDO where JDO is a data source that SDO can access, applying the Data Transfer Object (DTO) design pattern.

What is the relationship between SDO & JAXB?

JAXB is a Java Community Process (JCP) standard and stands for Java API for XML Data Binding. As an XML binding framework for the Java language, JAXB performs marshalling/serializing (Java to XML) and unmarshalling/deserializing (XML to Java).

SDO defines a Java binding framework of its own and it goes one step further. While JAXB is only focused on a Java-to-XML binding, XML isn't the only kind of data SDO can bind to. SDO provides uniform access to data of various types through its Data Mediator Service (DMS). Examples of data types include relational databases (RDBs), entity Enterprise Java Beans (EJBs), or XML registries. SDO also offers both a static and dynamic API, whereas JAXB only provides a static binding.

What is the relationship between SDO & ADO .NET?

ADO .NET provides uniform data access between different tiers in the .NET framework.

ADO .NET and SDO share similar motivators for supporting XML and applications distributed on multiple tiers. Other than technical differences, one major difference between the two technologies is that ADO .NET is for the Microsoft .NET platform whereas SDO is for the Java (J2EE) platform.

Other Documentation

Back to the top