JAG - the Java Application Generator - is a open source application that generates out-of-the-box working J2EE applications. Until now JAG has only been able to 'reverse architect' an application based on an existing database model, but with JAG v3.0 you can now import your system design from a UML model, exported from any XMI-compliant modelling tool (Together, PoseidonUML, etc.)

JAG started off life as an internal development tool within Finalist IT Group where it has been used successfully in a number of projects for commercial clients - and now Finalist has made JAG freely available as an open-source project.

The motivation behind JAG is to simplify J2EE development so that developers can concentrate on the business and presentation logic, rather than the J2EE 'scaffolding' itself. The keyword here is "simplify", and J2EE application development doesn't get much simpler than this:

   1) design entity and session beans and the relationships between them in a UML class diagram,
   2) import the model into JAG (a Java Swing application) and configure a database connection
   3) let JAG generate the application, then
   4) build, deploy and enjoy!

What you get is a fully-functional J2EE application (the current template is most compatible with JBoss 3+) with full create/retrieve/update/delete persistance functionality, whose architecture follows best-of-breed design patterns, and a JSP-based web tier using Struts 1.1 features such as declarative client- and server-side input validations.

We invite you to check out JAG at http://jag.sourceforge.net, and hopefully this article will generate some discussion here on TheServerSide.

Can anyone tell me the difference between JAG, AndroMDA and Architectureware? It seems that JAG and AndroMDA use XDoclet and Velocity and Architectureware uses it owns template language? I intend to insert UML/MDA to specification transformation in my EJOSA process, so I need one of them but what should I take?

AndroMDA:
http://sourceforge.net/projects/andromda
Architectureware:
http://sourceforge.net/projects/architecturware
JAG:
http://sourceforge.net/projects/jag

Gee, at one time we have so many choices in MDA with Open Source ;-) Anyway this is great!

Thanks,
Lofi.
http://www.openuss.org

Lofi
How has your exoperience with MDl based generators ? Have you generated parts of openuss app with any of the above ? Could you share your insight into the process ? What level of complexity can these generators handle ? Can they handle CMRs?

Regards
-manish

Hi Manish,

At the moment OpenUSS does not use MDA technique. OpenUSS uses XDoclet approach in some of it components. We use the EJOSA process as describe in this diagram to develop OpenUSS Component:
http://ejosa.sourceforge.net/ejosa-images/ejosa-template-process-matrix.jpg

I've played a bit with AndroMDA. It seems that it is very flexible. It uses Velocity as the template language and you can always define your own template/cartrige. This is very important for us because we completely use interface-based development and we use our EJOSA structure, describe in this digram:
http://ejosa.sourceforge.net

I also use EJOSA for teaching activities. For beginners it's just too much if you add MDA on the top ;-) By using the EJOSA structure I can always show the "suitable" view to the students, depends on their capabilities.

Adding this MDA technique within our EJOSA process on the top would be the next step for us. Instead of defining the interfaces, factories, delegates, other stuffs by hand, we would develop our own template/cartrige, so we can generate those things from the UML diagram automatically.

If you check the example of MDA, it is a very complete example. Yes, you can have CMR and AndroMDA delivers some nice templates/cartriges.

Therefore I would like to know whether JAG, Architectureware also deliver some nice cartriges... And what are the difference? Someone can answer?

Thanks,
Lofi.
http://www.openuss.org

As one of the JAG developers and user of AndroMDA I would like to react.
First of all, JAG does not use any MDA techniques but uses XDoclet where possible. Instead of focusing on cartridge development and specifying a Platform Independent Model, JAG is really focused on J2EE projects only. Some parts of the templates could probably be replaced by different technologies (For example using Hibernate instead of Entity EJBs) but this hasn't been the focus of JAG. It is really intended to generate a complete out-of-the-box working J2EE application instead of just a part of it.
A big advantage of JAG is that it has a GUI to setup your J2EE project, which makes the usage of JAG intuitive. As one of the first tools it supports both importing and exporting UML, as most other tools only allow reading UML.
UML is where JAG and AndroMDA are complementary. With JAG you can easily create Entity EJBs and Session EJBs and export them as XMI in a format compatible with the AndroMDA EJB cartridge (Using <GUI.
For users that want to create a complete J2EE application based on open source technologies JAG can give you really a head start.

cheers,

Rudie Ekkelenkamp

Finalist IT Group
Java Specialists
Web: http://finalist.com

Hi Lofi,

> I've played a bit with AndroMDA. It seems that it is very flexible. It uses
> Velocity as the template language and you can always define your own
> template/cartrige. This is very important for us because we completely use
> interface-based development and we use our EJOSA structure...

I thought it worthy to mention that JAG's templates are also defined using Velocity, and so the flexibility you describe is also a feature of JAG. Once you have mastered Velocity (you will already know how simple that is), tailoring the templates to your specific requirements is a simple matter.

The latest template shipped with JAG generates a fully working J2EE project with the following features:

  o Builds with Ant
  o Extensively uses XDoclet to cut information redundancy
  o EJB2.0 : local interfaces and container-managed relationships
  o Seperated business and presentation tiers
  o Struts 1.1 used in the web tier, with client- and server-side validations on user input
  o System architecture distilled from years of commercial J2EE experience, e.g. Value Object, Fast Lane Reader, Session Facade patterns

I hope this helps!

regards,

Michael O'Connor

Finalist IT Group
Java Specialists
Web: http://finalist.com

Funny, I didn't see much mention of MDA on the JAG site. Is this intentional? Of course that begs the question of "What really is MDA?"; however, I would assume that any tool which transforms a UML model (XMI) into code is pretty close if not identical to being MDA...

Hi Stuart,

> Funny, I didn't see much mention of MDA on the JAG site. Is this intentional? Of course that begs the question of "What really is MDA?"; however, I would assume that any tool which transforms a UML model (XMI) into code is pretty close if not identical to being MDA...

I must admit, I have been thinking about putting some MDA blurb on the site as well.

My Yorkshire upbringing means I tend to "call a spade a spade" as it were (i.e. keep it simple!) - but if it helps people to understand what JAG is about by referring to MDA concepts then I'll happily do this.

thanks for the feedback,
Mike O'Connor

Michael, thanks for the response.

Reading Rudie's comments earlier, he highlights a difference between JAG and other MDA tools, viz. that JAG is focused on one thing, i.e. J2EE applications. Nevertheless, since it sounds like the framework is so close to AndroMDA, I predict that JAG will soon mutate into a true MDA tool by developing the concept of cartridges, similar to ArcStyler and AndroMDA. After all, you do realize that the JBoss group is moving more toward lightweight containers using AOP and POJO's. It seems that bringing in Hibernate and working on JDO for JBoss (probably on top of Hibernate) will lead to a model for enterprise Java that is not so dependant on Entity Beans, which if you read the writing on the wall, are not as clean as POJO's with AOP and JDO persistence. The upshot is that if JAG used an MDA cartridge model then it would be more 'agile' at adapting to newer enterprise Java programming models. You can be sure that they are coming. Just look at the SDO thing from IBM and BEA.

Also, how does JAG handle round-tripping, which I believe is one of the trickiest things to do? The only one I have seen do this 'right' is TogetherSoft.

Regards,
Stuart Zakon
Objects by Design
http://www.objectsbydesign.com

Stuart, your comments about loosening the ties with EJB and looking towards JDO and AOP are food for thought. I have been watching these technologies from a distance so far: I sense the time coming closer to try out the water..

In theory JAG already has 'cartridges' (you could probably write a JAG template that produces JDO code for Hibernate without any change to JAG): the big difference between JAG and MDA tools as I see it is that the JAG architecture does not really have the concept of a Platform Independent Model. I can imagine however that the leap between the current model used by JAG and a true PIM is not such a great one, so maybe you are right in saying that JAG will mutate into a true MDA tool. Watch this space!

The round-trip capability of JAG is admittedly limited at present. Basically when JAG regenerates code 'on top of' existing code and an existing source file has changed, the GUI informs you of the fact that the new version is different, lets you view a 'diff' of the two files, and then gives you the option of either:
   a) leaving the old version intact, or
   b) overwriting the old version (and making a backup).

Regards,
Michael O'Connor

Hi Stuart,

I enjoyed your post a lot. Regarding EJB dependency: It seems important for us to have such flexibility and steer an independent path that makes EJBs an option - not a required outcome. I really appreciate whoever it was who listed MiddleGen on their list of tools. This provides some continuity. MiddleGen has had the plug-in cartridge idea going for a while.

With this concept:
A) You might not need to be so dependent on EJB, and
B) You can generate (and hopefully reverse engineer) an alternative information service mechanism.

I tend to associated the MDA idea with the ability to have one, two, even multiple round-trips to re-engineer from and different model sources and generate back - so that at least one round-trip plug-in works in both directions.

It seems the round trip and model sharing technologies build on each other: Having multiple round trip plug-ins enables re-use of the XMI/MOF space as a modeling space.

Or, looked at the other way, sharing among multiple tools within the XMI space should make it easier to to have a robust set of specialized round-trip mediators.

Regarding EJBs: We are currently using a framework that de-emphasizes EJBs so that they are an implementation choice that sits behind a data access layer. The data access layer sits behind a full service description layer and the front end connects to the service description layer.

I guess an even more flexible generation tool would represent the decision to use EJBs at all and various EJB implementation and deployment options as a set of selectable aspects (e.g. requires transactions, requires XA, requires demarcation, etc).

'gardz,

Rich

Dear all,

In my opinion, MDA is both an OMG vision of how to develop distributed software in the next years and also toolkit for enabling "model based engineering".
First, MDA is based on UML (this is mandatory) and its current file export XMI for UML.
Second, MDA split the world in three main areas decribed by models
 - CIM: Computational Independent model (domain analysis model)
 - PIM: Platform Independent model (describe your classes without any information of how to implement them)
 - PDM: platform dependendt model (transformation of PIM in order to implement it on a particular platform).
Third MDA is based on tools doing automated mapping from one model to another like CIM to PIM, PIM to PIM, PIM to PSM and PSM to PSM should be based on tools.

Today part of the MDA vision is real, and is mainly related to PIM to PSM mapping: automatic persistence from class model or XML file (Hibernate for example), application generation on J2EE platform (AndroMDA, compuware, WSAD, etc.) or .Net (Rational XDE for example).

I hope it helped !

Read PSM for pltform specific model and not PDM.
Sorry ;)

MDA has evolved over time and continues to evolve. - as has XMI. XMI 1.2 seems to kind of a minimum requirement for model interchange.

MDA Resources:
--------------------------------------
XMI 1.2 (Jan 2002) and XMI 2.0 (May 2003)
http://www.omg.org/technology/documents/formal/xmi.htm

MDA Resource Page
http://www.omg.org/mda

MOF 1.4
http://www.omg.org/technology/documents/formal/mof.htm
(There is an MOF 2.0 in progress).

MDA FAQ
http://www.omg.org/mda/mda_files/MDAFAQfinal1.pdf

Model Driven Architecture, by Richard Soley and the OMG Staff Strategy Group (Nov 2000)
http://www.omg.org/docs/omg/00-11-05.pdf
Model Driven Architecture: A Technical Perspective (Feb 2001)
ftp://ftp.omg.org/pub/docs/ab/01-02-04.pdf

And if you can make it to Burlingame this morning:
http://www.omg.org/news/meetings/MDA2003/program.pdf

The key to code generating apps is firstly to allow the ‘model’ to be changed and allow for re-generation as often as is required in today’s interactive development cycles, and secondly to allow a simple way for the generated code to be tailored, changed, enhanced, such that you can still re-generate and keep these customizations. As a user of Together UML, I have to agree there live-source concept rocks.

Since this thread is about application generation I have to mention the code generator which is core to the Jaffa Project. Jaffa is a runtime architecture + a code generator + a set of patterns. The goal is to take domain model, and generate a fully working CRUD web application as simply as possible. Seems like everyone is focus on java productivity these days!

With its current release you have to start with your domain objects defined in XML (we have an import tool for Uniface, no XMI yet :-( ). We then have an App Builder that generates all the XML descriptors for the components that need to be built (you can tailor this XML). With the whole application now as ‘modeled’ components, we run this through the code generator, and out pops all the JSP’s, XML Fragments (for Struts, etc), Java Code, SQL scripts, properties files etc. This can then be compiled, built and deployed with a single Ant script. The generator uses XML to define what files the pattern generates, and WebMacro for the actual template files.

The advantages we see to this if you don’t like what the patterns generates, change the templates of create new ones, if you don’t like aspects of our runtime architecture; change the patterns to use your runtime architecture of choice. Our goal is to build up a common set of component patterns into a library so we take the headache out of building new web apps, then refactor these patterns to meet the changing architecture needs as new options come along, and just re-generate the application with the new templates.

Beyond the cool features built into Jaffa’s runtime architecture, the cool part about the generated code, is that it’s compatible with (a) the NetBeans guarded code concept, so customization points are provided throughout the components, and as such are preserved through re-generation. We also (b) put in Together compatible javadoc comment in the generated code so you can view the domain model and its relationships in UML.

The main problem we face when looking just at a RDBMS to reverse-engineer a model, that there is not enough semantic information about the fields, keys and relationships to build an accurate model. This shouldn't be a problem with forward engineering systems like MDA.

Jaffa’s CRUD patterns are currently based on a lightweight web server only deployment (no EJB’s) so if you’re looking for an alternate to the JAG EJB pattern you should have a look. We are currently in the process of refactoring all our CRUD patterns to use Struts 1.1 w/Tiles, these new ones are in CVS currently, and should be officially released later this year.

PaulE

What's nice about JAG is that it has UI where Andromada does not. Having to model your database tables in a class diagram is very time consuming and tedious. Better for me was to use JAG to import the DB and then add whatever session beans I wanted. Just for fun it's cool to import DB tables, export the UML model, and then load UML Model with something like Poseiden and you have a generated UML model from the database. Architecture Driven Models have their advantages.
I did have a few problems using JAG and couldn't find much on the web in the way of problem statements and resolutions. I guess they should be coming soon.
I wrote up a more detailed description of JAG and a comparison to other similar tools on my web site, http://www.j2eehottalk.com/J2EE/Articles?ArticleRefID=0000000000000006000000f91f15732d&Tab=Forums , or just j2eehottalk.com. JAG is heading in the right direction.

Danny

Hi Danny,
> I did have a few problems using JAG and couldn't find much on the web in the way of problem statements and resolutions...

The best arena for bug reports and solutions at this stage is the JAG project forum pages: http://sourceforge.net/forum/?group_id=86381

It's still early days, but the 'Help' forum is beginning to warm up. I'd be very interested to hear whatever problems you experienced with JAG: if I don't know what they are, I can't fix them!

Thanks for taking the time to write the review on you site, btw. It's reminded me that more work could be done on the EJB finders generation..

Mike O'C

i'm new to mda but i do really think that tools such as JAG & Andromda is really useful has great potential.
however, there is one question which i am unable to answer. how do we manage our own source code from the generated source code.

In AndroMDA you separate the "src = the code you write" and "src-generated = the code AndroMDA writes". Your own code can use: inheritance and composition to use the generated code, very simple.

Yes, MDA in general is very interesting and has a great potential. I would never go back to my old environment without MDA.

Anyway, this discussion is very interesting! Maybe a time to write an article about "Open Source MDA Tools Comparison"?

As an intro to "Model Driven Architecture" and "Sourcecode Centric Development" I build EJOSA: http://ejosa.sourceforge.net. Here you can see how you can integrate the MDA process into your enterprise project (I'm using AndroMDA).

Cheers,
Lofi.