From Taylor

Taylor's model driven architecture on rails makes creating JEE applications as easy as the much talked about ruby-on-rails, but with all the power of JEE and UML. Business models are defined using simplified UML diagrams following well-defined conventions. These models are then used to generate the exact same ejb3/portlet code your would write by hand. Then use the code as is or modify it as you see fit and your changes will be preserved.

Taylor consists of a set of Eclipse plugins for simplified UML modeling and the generation of JEE code such as: EJB3 entity and session beans, JSR-168 Portlets, and JMS-based business processes. It leverages many other open-source tools instead of reinventing the wheel. Read more about the Architecture.

Why did I write Taylor? Check out my blog entry.

Taylor implements MDA. Model Driven Architecture (MDA) is the concept of first defining a Platform Independent Model (PIM) and then using the PIM to generate a Platform Specific Model (PSM). Taylor's simplified UML business models represent the PIM and its customizable templates generate the PSM.

Taylor also applies Convention-based Development. There are many ways to build the same application. But, if proven conventions are followed then code generation and development can be much more productive and can put you on the fast track to success. Hence MDA on rails. Taylor's simplified UML models embody these conventions.

Taylor distingishes itself from other tools by three key concepts:

  • Specialization/Simpification
  • Stereotypes/Annotations
  • Transparency


Taylor is not a general purpose UML tool. It is specialized (i.e. simplified/tailored) for building Enterprise Applications. As such only the UML features that you need to build these systems are exposed. This means that you don't have to spend time trying to decide which UML features you need to use to design your system. Nor do you have to write and enforce a set of best practices. A decade of experience with using UML and its predecessors to build enterprise applications has lead to the best practices/conventions that are exposed by Taylor. With that said, the use of the Eclipse UML2's XMI file format does allow for compatiblity with general purpose UML tools. Taylor also comes out of the box with templates for generating an EJB3 PSM and more. These templates could certainly be replaced to generate a Spring/Hibernate PSM or a .NET PSM or what ever you like, so long as your goal is to create an enterprise application.


Java Annotations are one of the most controversial new features of Java 5. However, they are very powerful when combined with a Model Driven Architecture. In fact Java 5 Annotations are exactly equal to UML Stereotypes. Stereotypes are the UML approach for extending the UML language. Stereotypes have all the same features as annotations:

  • They have a name.
  • They specify which components they can be applied to: class, field, method, etc..
  • They can have attritbutes.
  • Those attributes can be arbitrarily complex.

Stereotypes are then grouped into profiles that can be applied to a model. Taylor comes with several profiles that correspond to the standard Java annotations:

  • EJB3 - for defining Session Beans
  • JPA - for defining Entity Beans
  • JWS - for flagging Session Beans to be exposed as Web Services
  • Types - a platform independent set of basic types

These profiles are automatically applied when a Taylor model is created. Many stereotypes are automatically applied when dragging components to a canvas, while others are applied on demand through the navigator. The defaults of the stereotypes also match the defaults of the annotations to comply with the configuration-by-exception approach of EJB3. On the screen shots page you can see the stereotypes in the Navigator and in the Properties view. The label of each node shows the applied stereotypes (e.g. <<entity>>). Stereotype attributes are set via the Properties view. The stereotypes are then generated verbatim into the source code as Java 5 Annotations. Hence the Power of Annotations in an MDA.


  • def. transparent - easily understood or seen through
  • def. transparency - the quality of being clear and transparent

Many similar tools generate code and compile it before you can see it. And they often depend on proprietary frameworks. They are not transparent. Taylor generates exactly the same code that you would write by hand and gives you ample opportunity to customize the code. So, if you don't like what is generated or if there is a bug in the generation then you can change it. It is completely transparent all the way down into the open-source code it leverages.

Personal tools