Leaving Callisto and All Aboard for Europa

Contents:

• Where to go for MDD and DSL
• Eclipse Packaged Distributions
• Eclipse Project Management
• Getting Started
• Eclipse Benefits
• Risks and Risk Mitigation
  

Where to go for MDD and DSL?

On one of my recent projects, I was given an opportunity to look into tool options for Capability Requirements Development, Model Driven Development, and Domain Specific Languages. The organization had been using a number of commercial tools which did provide many of the required features individually, but left us with many challenges with respects to streamlining their integration. The modeling notations and presentation came close to meeting our requirements, but in many cases required us to abuse the intent of UML's metamodel. The trend towards DSLs (Domain Specific Languages) was getting increasing levels of attention in our group, sufficiently so that a project was created to look into the matter.

Our primary modeling tool, a commercial suite which includes a modeling tool which sits on top of Eclipse did provide many extensibility and customization options. Unfortunately, what was available at the time was a bit too constrained. A number of articles on the vendor's web site as well as help files within the tool itself pointed to the direction of using the Eclipse Modeling Framework, or EMF.

Although the commercial tool vendor's version of Eclipse did include EMF, I did not want to tie any decisions I would make to an aging release. Only a bit of browsing of newsgroups made it clear that a lot of work was being done on the EMF Tools side (EMFT) and that work was being done using newer releases of EMF. Also the Modeling Tools Project (MDT) and Graphical Modeling Framework (GMF) inspired possibilities which otherwise could not have been considered due to limited developer resources.

Eclipse Packaged Distributions

A first challenge when planning out the Eclipse stack to use is one of configuration management. The Release Train idea is an absolutely terrific one. Unfortunately, the features I was aiming to get where not yet available in the Callisto synchronized release, so I had to choose my releases piecemeal from the evolving pre-Europa GA. Be forewarned that this is not an easy undertaking as you are basically trying to patch together features of work in progress (in open heart surgery is one metaphor). The Eclipse Plug-In architecture and the evolving community conventions did lead to my deciding that it would be possible to make due until the Europa Release train came to town, so to speak.

Eclipse Project Management
To help maintain a comfort level about working with pre-release code, the Eclipse project plans did a good job at providing visibility into the milestones of the release cycle. This, together with active community forums and bugzilla (bug tracker), provide a "pulse" of the projects. Having tutorials available early on is also a very good idea, and many of the authors were good enough to note version differences in the behavior. I do suggest however that you set up some rudimentary configuration management to keep snapshots of the tutorial in sync with your release configuration of your tool set. I was bitten a few times when, in the time it took me to complete a tutorial, it had undergone changes which were only applicable to a more recent integration release. This is one of the costs of working with pre-release artifacts, but considering this was the case, they are minor issues and can be managed if you are forewarned.

Getting Started
Projects have been pretty good at providing tutorials. For GMF, the Mindmap tutorial was sufficiently detailed and broken down so to make it possible to ramp up within a reasonable amount of time. However, given the additive nature of these tools (they are built on top of each other), there was a need to work back to building up more knowledge about the EMF and a bit of the Graphical Editing Framework (GEF). Both projects had good tutorials and references.

There are a number of books on EMF and I suggest you scan through them on O'Reilly Safari and either buy or borrow. Some are getting a bit out of date, but still have good basics, examples, and ideas to offer. Integrating examples and tutorials right into Eclipse's Help system is a class act. People often disregard going to a help system because the content is often very anemic. In my experience working with Eclipse Callisto and Europa, I have to say that you should make sure that you go through what has been published in the Help systems. If anything the wealth of links will give you a good start.

The GMF Mindmap example walks you through building a working graphical manipulation capable model editor. Make sure that your JRE is set to the right revision. This is absolutely essential with GMF examples.

Eclipse Benefits

EMF allowed us to define our metamodels in a very intuitive fashion. Though you can get a lot done through the sample ECore Editors and property dialogs, you are best advised to have a Java programmer on hand. After you enter your models either by providing code stubs in Java, or through the sample ECore Editor, or through import of IBM Rational Rose or XML files, your next step is to generate the supporting code for the model, the editors, and if need-be the test case scaffolding. These features are comprehensive. The generated code is very readable and there are clean guidelines on where to introduce your own code. Once you have successfully generated the EMF supporting classes for your metamodel, you are ready to move on to building up the GMF model. An Eclipse cheat sheet is available for both EMF and GMF examples and are a good way to become familiar with the workflow.

Once you have cut your teeth on the examples, you can then import your EMF model and start adding tool bar and graphical definitions in the supplied GMF editors. These editors do require a certain understanding of how the pieces fit together however, so do make sure you work through the examples before you commit to a delivery timeline. There are references to an "experimental SDK" for GMF which is supposed to allow you to do graphical editing of the GMF models, but I haven't tried it yet. One thing you should be aware of is that refactoring capabilities aren't really there yet. I suggest you get a reasonable amount of work done using just the GMF supplied editors before you start coding in extensions. The reason I say this is that the easiest way to deal with refactoring issues (until you start understanding how GMF behaves) will be to delete the generated code and then regenerate.

Now let's take a moment to reflect. At the beginning of this article, I mentioned our need to find possible tooling solutions for Model Driven Development and Domain Specific Languages. With EMF alone, I think we have a really good base for building up our MDD foundations by allowing us to readily build up our metamodel and then our model instances in the runtime. Adding in GMF has given us the added possibility of graphically manipulating the model instances. These are capabilities which would have taken way more programmer resources than we have available. Sure it could be done, but nowhere near as extensive in features and maturity. There was obviously a lot of work and effort put in to these tools and there is a lot of "standing on the shoulders of giants" going on here.

Our latest work has us exploring the use of OCL and EMF Query tools for querying model instances. These tools provide a lot of potential for being able to harness the value of the models. As the number of modeling elements grow big and the overall complexity increases, it is makes a very big difference to be able to use a query language to find matching modeling elements. This is what EMF Query offers. The OCL sub-project, beyond providing model integrity capabilities, also has examples of tying in with EMF Query, basically providing an OCL Query capability. The provided examples give a good start in showing where these tools may grow in the future.

Risks and Risk Mitigation

If you are considering using Eclipse Europa for similar projects, be advised that a number of tool vendors are planning to build on top of this platform. From our experiences to date, the vendor's position on this could either qualify or dismiss them for certain projects. Certainly, it makes sense to work with fully tested products supported in all necessary geographies by a well established vendor. That is the nature of doing (software) business in many large corporations and also in public sector projects. However, given the thoroughness of the Eclipse community processes, the visibility offered by supporting communication tools, and the significant collaboration the Eclipse Foundation has managed to foster from major industry tool vendors and top notch developers, it would be silly to disregard Eclipse Europa as a possibly viable tool set on its own for many projects.

As your needs grow, or if a vendor offers capabilities beyond that of the open-source projects, then you will have an upgrade path. To avoid vendor lock-in, I suggest you always have access to a SME that can let you know how dependent you may get on vendor-specific features. The extent to which the vendors are "good citizens" in the Eclipse community (and open-source in general) may be an indicator of the pains you may need to go through should you decide to change tool vendors. For example what is a custom vendor feature today may eventually seed an open-source project tomorrow. And even if there is a fork in the road, a good vendor should facilitate the migration of the vendor specific work products to the ever appearing new standard on the block.

Conclusions

Eclipse Europa has shown itself as providing the necessary ingredients for pursuing our MDD and DSL work. Though it is probable that we will eventually move on to a commercial stack (we need some commercially available features) it will need to sit on top of Eclipse. The Eclipse Foundation has fostered an excellent collaborative environment and a community which has been able to build a formidable toolset.

The move from Eclipse Callisto to Europa has seen a tremendous growth in the number of projects and features. Many of the projects are starting to build on top of each other, limiting the amount of duplication. The Europa release of the tools we used are pretty solid and are definitely worth taking a look if you are in the market for new tooling. You would be doing yourself a disservice if you didn't.

Ron Charron

Welcome!

What ever became of The Object People inc?
The following link will redirect you to archive.org, which maintains an archive of The Object People web site shortly after the announcement of it's acquisition by BEA Systems and WebGain in April 2000.
click here

Message Driven Beans(MDB) - When should I use them?

J2EE introduced Message Driven Beans (or MDBs for short) a few years ago to provide garanteed delivery and asynchronous processing capability while providing all of the benefits of an Enterprise Beans. The intended benefits include:

• Standard APIs to post and retrieve messages
• Guaranteed delivery of messages
• The ability to use alternate providers (undelying implementation of the messaging engine)
• EJB benefits (Transactions, Security, Persistence, etc..)

JMS

JMS, itself a Java standard library has traditionally been used to post messages to a queue. JMS, like Java, is platform independent, relying on the provider (actual implementation) to deal with platform specifics as necessary. Although your organization may have such tools as IBM MQ Series, a robust commercial queueing and messaging system supporting many programming languages, you would usually use MQ via JMS bindings in a Java program. This gives you more flexibility to choose alternate providers in the future should you so decide. This also means that you can use MDBs to read messages off of the queue.

MDBs act on behalf of the sever, not the client

Client applications can be java applications, applets, servlets, or even other EJBs acting in response of a client request. These client applications are responsible for:

• Creating the message
• Performing a lookup of the queue (or Topic)
• Posting the message on the queue

Your MDB is then notified by the underlying messaging provider through the EJB container (you don't care about the provider). The MDB reacts through it's implementation of the onMessage method. Like other EJBs, much of the information available through container supplied context objects let you get additional information.

Security Context vs. MDBs

One problem with using MDBs is that the J2EE specification doesn't specify how to handle the security context. If you were using a Session or Entity Bean, having the propagated EJB context include the security context means that you could get information about the caller and his security role, etc.. This makes sense in the case of Session Beans and Entity Beans, as it is usually the case that these types of beans are running as a result of an on-going conversation between a client (whose credentials have been authenticated) and the server (which has been able to identify the security roles and permissions as defined in descriptors and can then propagate through context objects). MDBs are by nature, asynchronous. Although it is possible that a client is actively engaged in conversation with the server, it may also be the case that messages have been queueing up for a while (e.g.: while a ressource such as a DB is down) and that it is processing messages from a large number of sources. Queuing up credentials in the messages or similar metadata in the queue would cause other kinds of problems. These would be needed for security context propagation, but the cost would be a need to secure the queue. These issues were not resolved as a part of the J2EE specification and as a result, are not handled well in most current day implementations (e.g.: IBM WebSphere). Designers and architects have to find alternate ways to deal with security when using MDBs.