Eclipse World 2007: Fundamentals of the Eclipse Modeling Framework
•
0 j'aime•766 vues
EclipseWorld 2007 long talk discussing the fundamentals of EMF and introducing its CDO and Teneo persistence components.
![Goal ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Eclipse World 2007: Fundamentals of the Eclipse Modeling Framework
Similaire à Eclipse World 2007: Fundamentals of the Eclipse Modeling Framework (20)
Dernier
Dernier (20)
Eclipse World 2007: Fundamentals of the Eclipse Modeling Framework
- 1. Fundamentals of the Eclipse Modeling Framework Dave Steinberg IBM Rational Software Toronto, Canada EMF Project Committer
- 16. XML Schema <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/SimplePO" xmlns:PO="http://www.example.com/SimplePO"> <xsd:complexType name=" PurchaseOrder "> <xsd:sequence> <xsd:element name=" shipTo " type="xsd:string"/> <xsd:element name=" billTo " type="xsd:string"/> <xsd:element name=" items " type="PO:Item" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name=" Item "> <xsd:sequence> <xsd:element name=" productName " type="xsd:string"/> <xsd:element name=" quantity " type="xsd:int"/> <xsd:element name=" price " type="xsd:float"/> </xsd:sequence> </xsd:complexType> </xsd:schema>
- 26. Bidirectional Reference Handshaking public interface PurchaseOrder { ... PurchaseOrder getNext (); void setNext (PurchaseOrder value); PurchaseOrder getPrevious (); void setPrevious (PurchaseOrder value); } Bidirectional reference imposes invariant: po.getNext().getPrevious() == po
- 28. Bidirectional Reference Handshaking p1.setNext(p3); p2 p1 p2 p3 change notification previous next previous next next previous next previous
- 38. Proxy Resolution and Demand Load proxyURI="p2.xml#p2" proxyURI=" p2.xml #p2" p1 p1.xml PurchaseOrder p2 = p1.getNext(); next p2 p2.xml next
- 55. Legal Notices IBM, Rational, and Rational Rose are registered trademarks of International Business Machines Corp. in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
Notes de l'éditeur
- Welcome…
- I hope to help you learn about modeling and convince you that EMF can help you write just about any application in significantly less time, simply by leveraging the data model you’ve probably already defined (even though you might not know it yet).
- Here’s our agenda. I’ll start with some philosophy…
- What is modeling? The Object Management Group, an industry consortium, has tried to answer that question by proposing MDA – Model Driven Architecture…
- MDA initiative began in 2001. Some people are wondering not just “are we there yet?” but “are we ever going to get there?”…
- This is the environment in which EMF was introduced and took hold…
- EMF’s take is that models are everywhere, and we just need to find them, extract them, and leverage them…
- How? With all this…
- Also, as of last summer’s Europa release, EMF provides support for Java 5.0… Generics support includes the ability to model generic types within Ecore.
- Where does EMF fit into the Eclipse “big picture”? EMF was one of the first projects at Eclipse outside of the Eclipse Project itself, starting in 2002 as part of the Tools project. Since then, the modeling project has formed around it…
- Now, let’s talk some more about models in EMF: what they consist of and where they come from.
- I’ve mentioned that EMF’s view of modeling favours simplicity over expressiveness. But, to be more concrete, here’s what we mean by a “model” in EMF…
- EMF is very much intended to be a unifying technology. It expects models to be expressed in any number of different ways, and aims to extract its core view of the model from those different representations. Out of the box, it supports what we consider to be the most important ones… To dwell for a moment on the notion of equivalence of different model representations, let’s consider a simple, familiar example. Imagine we wanted to represent the data in a purchase order. The non-modeler would probably start by writing some Java interfaces…
- An interface for each type, accessors for each attribute or association (reference). This really is a definition of the model. Sometimes, we’d like to express things that aren’t captured in these signatures…
- A graphical representation of the model is more concise. Here, we’re using UML notation…
- There’s another important way of coming at this: by asking “how do we want to instances of the model to look when they’re serialized?” That’s what XML Schema is all about… Notice that there’s additional information in this one…
- To reiterate, these different forms all provide the same core information about the model, or structure, of the application’s data. EMF allows you to capture this information and use it to, among other things, generate code.
- Let’s turn to EMF’s architecture. If EMF’s purpose is to capture the core information about an application’s data model, the big question is how…
- Not surprisingly, it uses a model… Here is a simplified picture…
- The way EMF defines your application model, such as the purchase order we discussed previously, is by instantiating Ecore…
- Ecore is persisted as XML, using the OMG’s standard for metadata serialization, XML Metadata Interchange… EMOF is the OMG’s equivalent to Ecore. Based on experience with EMF, MOF was split into to two layers, where EMOF is the minimal core. Because of their similarity, EMF directly supports saving Ecore as EMOF XMI and loading EMOF XMI into Ecore.
- Here’s the pretty block diagram that will hopefully tie everything together…
- I’ve mentioned more than once that EMF lets you generate code from a model. But what does that code look like?
- First off, for each modeled class, an interface/implementation pair are generated. Notice that the interface looks like the Java model representation… Using interfaces allows us support for multiple inheritance… Interfaces extend EObject, the EMF equivalent of java.lang.Object…
- Looking in the implementation class at the accessors, we see an almost minimal implementation…
- Things get a bit more complicated if you model bidirectional associations, in order to ensure that referential integrity is maintained. To illustrate…
- EMF implements this using a handshaking pattern… It’s not possible to turn off this handshaking bahvior or stop it part-way, without significantly altering generated code.
- Now, looking at the example, let’s follow the whole handshaking process. If we have three purchase orders arranged like this…
- Earlier, I mentioned the EObject interface. Primarily, it provides the API for manipulating objects reflectively…
- These generic accessor methods are implemented using an efficient switch, so as to only impose a small constant-time overhead… Metadata in EMF is represented in two ways…
- EMF realizes enumerated types with Java 5 enums. Previously, a class-based type-safe enum pattern was used.
- Obviously, there’s not enough time to talk about every artifact that EMF generates, so here’s a quick list. Notice that the code is divided into four projects…
- As I mentioned in the intro, Ecore is simple by design. Instead of trying to provide a modeling vocabulary that’s as expressive as Java…
- The generator also supports a pattern for extending generated methods, analogous to overriding a method in a subclass…
- Let’s talk about how you can use all this code we generated…
- We’ll start with EMF’s resource-based persistence framework. A resource in EMF is a container for a bunch of objects that will be persisted together. A resource set provides a context for multiple.. Demand-loading is used for cross-resource references…
- Out of the box, EMF provides a generic XML resource and a number of different specializations of it…
- To expand on EMF’s demand-load model for cross-resource references, let’s look at another simple example…
- Switching gears, a few words on notification. As we saw when we were discussing generated setter implementations, change notification is built in…
- The reflective EObject interface is a powerful mechanism for data integration, as it allows your application to discover the model for objects at runtime and modify them accordingly. If you know the model ahead of time…
- Built upon the reflective API is dynamic EMF. Rather than generating code, you can define an Ecore model at runtime and instantiate it immediately, using a generic implementation. All of the behaviours of the generated code are emulated by this implementation. You can define the model…
- EMF provides a facility for representing and recording changes to data. As we’re big believers in eating our own dog food…
- A change recorder is a special adapter that attaches to an entire content tree and, based on the change notifications it receives…
- The EMF core also has a built-in framework for validation of invariants and constraints… The API for invoking validation is the Diagnostician class…
- As I mentioned at the beginning of the talk, the modeling project is building a whole stack of technologies on top of EMF. I thought that, for this audience in particular…
- There are two emerging technologies in the EMFT project that provide support for database persistence in EMF…
- I’m going to focus on Teneo today, just because of time pressures and because I’m more familiar with it… … with plans to include EclipseLink. It also allows you to use ordinary, unchanged generated model implementations…
- I’ll focus on Hibernate just because it seems to be more popular, but the capabilities and APIs for JPOX are very much analgous… A Hibernate data store manages the O/R mapping and, in fact, creates it automatically at runtime…
- The data store then provides a session factory, which can be used in typical Hibernate transactions…
- Alternately, Teneo provides a Hibernate resource implementation, allowing you to use the ordinary EMF persistence API…