PART I IDENTIFICATION SHEET

Transcription

1 PART I IDENTIFICATION SHEET Project ref. no Project acronym ELLECTRA-WeB Project full title European Electronic Public Procurement Application Framework in the Western Balkan Region Security (distribution level) Restricted Contractual date of delivery 30/09/2007 Actual date of delivery 30/09/2007 Deliverable number D5.1 Deliverable name Electronic Public Procurement Solutions Transformation Rules Type Prototype Status & version Final Number of pages 62 WP contributing to the Deliverable 3 WP / Task responsible 3 / T3.1, T3.2 Editor Author(s) EC Project Officer Keywords Gøran K. Olsen Gøran K. Olsen, Brian Elvesæter, Christos Georgousopoulos Aniyan Varghese Model-Driven Engineering (MDE), Model-Driven Development (MDD), Model Transformation, Code Generation, Service- Oriented Architecture (SOA), Web Services, Java Enterprise Edition, Java Persistence API, Java Query Language Abstract (for dissemination) This documentation contains the overall architectural description of the ELLECTRA-WeB epp solution, the intermediate-developed transformation rules used for the generation, and some in-depth descriptions of important parts of the transformation rules. Copyright ELLECTRA-WeB 2007 Page 1 of 62

2 VERSIONING AND CONTRIBUTION HISTORY Version Date Description Contributors /08/07 Initial structure. Georgousopoulos C. (INTRASOFT) /09/07 Updated structure. Olsen G. K. (SINTEF) /09/07 Added content chapter 2. Olsen G. K. (SINTEF) /09/07 Added content chapter 3. Olsen G. K. (SINTEF) /09/07 Updated chapter 2, 3, 4 and 5. Added Appendix A and B /09/07 Updated chapter 1 and 2. Minor formatting issues. Olsen G. K, Elvesæter B. (SINTEF) Olsen G. K, Elvesæter B. (SINTEF) /09/07 Added content in chapters 2, 4 and 5. Olsen G. K, Elvesæter B. (SINTEF) /09/07 Updated chapter 2. Minor restructuring. Included contributions from INTRASOFT to the architecture description. Olsen G. K, Elvesæter B. (SINTEF) Georgousopoulos C., (INTRASOFT) /09/07 Updated chapter 3. Olsen G. K, Elvesæter B. (SINTEF) /10/07 Review of content & proof-reading. Updated list of acronyms & minor amendments in whole content. Final formatting. Georgousopoulos C. (INTRASOFT) Olsen G. K (SINTEF) Copyright ELLECTRA-WeB 2007 Page 2 of 62

3 TABLE OF CONTENTS PART I IDENTIFICATION SHEET... 1 VERSIONING AND CONTRIBUTION HISTORY... 2 TABLE OF CONTENTS... 3 LIST OF ACRONYMS... 4 LIST OF FIGURES... 6 LIST OF TABLES... 7 PART II EXECUTIVE SUMMARY... 8 PART III FULL DESCRIPTION INTRODUCTION TARGET PLATFORM AND ARCHITECTURE INTRODUCTION OVERALL ARCHITECTURE OF ELLECTRA-WEB EPP SOLUTIONS JAVA EE TECHNOLOGIES ANNOTATION-BASED DEVELOPMENT TECHNOLOGY PLATFORM EPP APPLICATION FRAMEWORK MODEL TRANSFORMATION RULES INTRODUCTION ELLECTRA-WEB MODEL TO TEXT TRANSFORMATION APPROACH OVERALL TRANSFORMATION SPECIFICATION ARCHITECTURE JEE PERSISTENCY GENERATION Entity Object Generation Relationship Annotation Generation Generating Inheritance Hierarchies Java Query Language Generation JEE SERVICE GENERATION JEE Web Service Generation Java Query Language Calls Generation SPECIALIZING THE MODEL TRANSFORMATIONS TOWARDS EPP DEVELOPMENT TEST CASE INTRODUCTION TO TEST CASE TEST CASE MODELS VALIDATION OF THE CURRENT TRANSFORMATION SPECIFICATIONS CONCLUSION PART IV APPENDICES APPENDIX A: GENERATED CODE EXAMPLES APPENDIX B: MODEL TRANSFORMATION RULES PART V REFERENCES BIBLIOGRAPHY Copyright ELLECTRA-WeB 2007 Page 3 of 62

4 LIST OF ACRONYMS Term AF API BPEL DBMS EC EIS EJB epp ERP ESB EU HTML HTTP ICT JAXB JAX-WS JEE JQL JPA JSF JSP MDA MDD MDE ODBC OMG OSS PIM POJO PSM QVT SHTTP SOA UML WSDL Description Application Framework Application Programming Interface Business Process Execution Language DataBase Management System European Commision Enterprise Information System Enterprise JavaBeans electronic Public Procurement Enterprise Resource Planning Enterprise Service Bus European Union HyperText Markup Language HyperText Transfer Protocol Information and Communication Technology Java Architecture for XML Binding Java API for XML Web Services Java Enterprise Edition Java Query Language Java Persistence API JavaServer Faces JavaServer Pages Model Driven Architecture Model-Driven Development Model-Driven Engineering Open DataBase Connectivity Object Management Group Open Source Software Platform-Independent Model Plain Old Java Object Platform-Specific Model Query View Transformation Secure HyperText Transfer Protocol Service-Oriented Architecture Unified Modeling Language Web Services Description Language Copyright ELLECTRA-WeB 2007 Page 4 of 62

5 XML extensible Markup Language Copyright ELLECTRA-WeB 2007 Page 5 of 62

6 LIST OF FIGURES Figure 1: Overview of the epp solution architecture Figure 2: Transformations from model to text Figure 3: A persistent class Figure 4: Generated Java code Figure 5: Entity relationships (Bidirectional ManyToOne and Unidirectional OneToOne) Figure 6: epporganisation relation generation result Figure 7: eppuser relation generation result Figure 8: Entity inheritance Figure 9: Generated inheritance Java source code Figure 10: Inheritance model transformation rules Figure 11: Model transformation rule that generates JQL implementation Figure 12: Modelling a service that manages a collection of persistent objects Figure 13: Generated service as JEE Session Bean Figure 14: epp service stereotype Figure 15: Generated Web service implementation Figure 16: A method that will be exposed as a Web service Figure 17: Generated JQL methods Figure 18: Text transformation declaration using two models as input Figure 19: Simple epp Reference Model example Figure 20: Entity stereotype specification enabling epp specific code generation Figure 21: Using the rule getrefclass() from the entity generator Figure 22: Entity view of Test Model Figure 23: Service view of Test Model Copyright ELLECTRA-WeB 2007 Page 6 of 62

7 LIST OF TABLES Table 1: List of model transformation rules Copyright ELLECTRA-WeB 2007 Page 7 of 62

8 PART II EXECUTIVE SUMMARY The overall aim of the ELLECTRA-WeB project is to specify, develop and test an open-source electronic Public Procurement (epp) Application Framework and a set of Supporting Guidelines that will enable, on the one hand, Western Balkan ICT solution developers to cost-effectively develop, and, on the other hand, Western Balkan Public Organisations and Suppliers to easily deploy and use trusted, interoperable, user-friendly, secure and EC compliant electronic Public Procurement solutions. The epp Application Framework (AF) supports the latest evolutionary approach of Software Engineering, called Model-Driven Engineering (MDE). In contrast with traditional Software Engineering approaches, MDE shifts the focus of software development from writing code to modelling. An epp solution produced via the utilisation of the epp AF comes in the form of a Web-based application that adheres to Service-Oriented Architecture (SOA). The target of this report is to specify the model transformation rules that will be utilised for the generation of an electronic Public Procurement solution. The rules map the artefacts defined in the electronic Public Procurement Platform Independent Model into the artefacts of the SOA-based implementation architecture. The development of the model transformation rules has followed an iterative and incremental approach. This document forms the first release of deliverable D5, namely D5.1 that reports on the intermediate results of this development. A second release, i.e. D5.2 to be released at M12 will finalise the model transformation rules and complete the work that has to be carried out in the context of the deliverable D5. Copyright ELLECTRA-WeB 2007 Page 8 of 62

9 This part includes Chapters 1 5. PART III FULL DESCRIPTION Chapter 1. Introduction Chapter 2. Target Platform and Architecture Chapter 3. epp Application Framework Model Transformation Rules Chapter 4. Development Test Case Chapter 5. Conclusion Copyright ELLECTRA-WeB 2007 Page 9 of 62

10 1. INTRODUCTION The overall aim of the ELLECTRA-WeB project is to specify, develop and test an open-source electronic Public Procurement (epp) Application Framework and a set of Supporting Guidelines that will enable, on the one hand, Western Balkan ICT solution developers to cost-effectively develop, and, on the other hand, Western Balkan Public Organisations and Suppliers to easily deploy and use trusted, interoperable, user-friendly, secure and EC compliant electronic Public Procurement solutions. Traditionally object-oriented frameworks are targeted for a particular application domain, such as user interfaces, business data processing systems, telecommunications or enterprise systems. A framework is more than a class hierarchy. It is a semi-complete application that contains dynamic and static components that can be customized to produce user-specific applications. Mature frameworks may be reused to form the basis for the development of many other applications. The purpose of this Deliverable is to specify of the epp Application Framework s (AF) model transformation rules. The model transformation rules will be part of a software production environment where model-driven, interoperable, customisable, secure, and EC compliant epp solutions can be efficiently generated. Technically, the proposed epp AF will effectively reduce the problem of developing epp solutions into the customisation of existing models [1] that detail public procurement processes. Future (Western Balkan and EU) ICT developers can, then, focus only in solving the business problem a particular epp solution requires and not to deal with any technical details of targeted epp solutions. The rest of the Deliverable is organised as follows. Chapter 2 includes a description of the epp Solution Architecture and technologies. Chapter 3 describes the overall architecture of the model transformation rules and also describes in detail some important aspects. In Chapter 4 a test case model is used as input to the model transformation rules and the quality and amount of code generated is discussed. Chapter 5 concludes the deliverable. The appendices at the end of the Deliverable contain the produced model transformation rules and samples of generated code. Copyright ELLECTRA-WeB 2007 Page 10 of 62

11 2. TARGET PLATFORM AND ARCHITECTURE 2.1 Introduction The purpose of this chapter is to present the target platform and architecture that specifies the application model that the epp Application Framework (AF) will support. Besides the specifications for the various components of the epp AF, it will also serve as a foundation for the subsequent design and development phases of the project. The application model specifies a multi-tiered Web architecture that software developers should adopt when designing and implementing epp solutions. The epp AF will provide the necessary model-driven development tools and guidelines required by the software developers enabling them to easily and effectively develop epp solutions according to the multi-tiered application model. 2.2 Overall Architecture of ELLECTRA-WeB epp Solutions The guiding design rational behind the platform s architecture is to facilitate interoperability and extensibility, as well as preserving in this sense a considerable degree of independence regarding the implementation of the end platform. Key factors to achieving this objective are the adoption of widely accepted as well as emerging standards and the usage of Open Source Software (OSS). Java and Web standards and technologies such as Java Enterprise Edition (JEE), XML, WSDL and BPEL will be utilized to bring forth the desired objective. Application Client Dynamic HTML Pages Client Tier Client Machine JavaBeans (optional) JSP / JSF Pages Web Tier Web Services Web Services Web Services Business Tier Java EE Server EJB Session Beans BPEL Processes Persistent Entities Database Enterprise Information System (EIS) Tier Database Server Figure 1: Overview of the epp solution architecture The epp AF utilises a distributed multi-tiered (4-tier 1 ) application model for epp solutions. An epp solution will be implemented as a Java EE application on a Java EE platform. A Java EE application is 1 The term tier is used both to describe division of application logic and describe distribution on different locations (machines). Though a Java EE application typically consist of the 4 (application logic) tiers shown in Figure 1, Copyright ELLECTRA-WeB 2007 Page 11 of 62

12 made up of Java EE components which are self-contained functional software units. Application logic is divided into components according to function, and the various components are installed on different machines depending on the tier to which the application component belongs. Figure 1 illustrates the tiers and their respective components. The client tier will typically contain Web clients. A Web client consist of two parts: (1) dynamic Web pages (e.g. HTML and XML) which are generated by Web components running in the Web tier, and (2) a Web browser that accesses server-side components in the Web tier using HTTP or SHTTP and renders the pages received from the server. It is also possible to access server-side components from an application client running on the client machine. Application clients can accommodate a richer graphical user interface than what can be provided by Web browsers. The Web tier components are either servlets or pages created using JavaServer Pages (JSP) and/or JavaServer Faces (JSF) technologies. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. JavaServer Faces technology is build on servlets and JSP technology and provides a user interface component framework for Web applications. - The Web tier might also include components based on the JavaBeans component architecture to manage the data flow between an application client and components running on the Java EE server. JavaBeans components have properties and have get and set methods for accessing the properties. The business tier contains Enterprise JavaBeans (EJB) components that implement the epp business logic. EJB components will be exposed as Web services that use open XML-based standards and transport protocols to exchange data with calling clients. Session beans represent a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. Persistent entities represent persistent data stored in one row of a database table. If the client terminates, or if the server shuts down, the persistence manager ensures that the entity data is saved. - The Web Services Business Process Execution Language (BPEL) processes will be used for the composition and orchestration of Web services. BPEL specify business processes and business interaction protocol using Web services interfaces. An executable BPEL process will itself be exposed as Web service on the platform. The enterprise information system tier handles EIS software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. Resource adapters (e.g. JDBC or ODBC drivers) provide access, search and update services to databases and its data stored in a database management systems (DBMS). 2.3 Java EE Technologies The epp Application Framework utilizes Java Enterprise Edition (EE) [2]. Java EE is a descendant of the Java technology, built on the solid foundation of Java Standard Edition (SE). The Java EE is an extension to Java SE that allows developers to use Web technologies and develop enterprise applications. It is widely accepted as the industry standard for developing portable, robust, scalable and secure server-side Java applications. A wide range of APIs [3] assists the development of Service- Oriented Architecture and next-generation Web-based applications. JavaServer Pages (JSP) [4] technology allows you to easily create Web content that has both static and dynamic components. A JSP page is a text document that contains two types of text: (1) static data, which can be expressed in any text-based format, and (2) JSP elements, which construct dynamic content. JavaServer Faces (JSF) [5] technology is a server-side user interface component framework for Java technology-based Web applications. JSF includes amongst others a set of APIs for representing user interface (UI) components and managing their state, handling events and input validation, converting values, defining page navigation, and supporting internationalization and accessibility. Java EE applications are generally considered to be 3-tiered applications because they are distributed over three locations; client machine, Java EE server and database server. Copyright ELLECTRA-WeB 2007 Page 12 of 62

13 Java Web Services (JAX-WS) [6] provides full support for W3C XML Schemas, maps Java Classes to XML data and is used to encode and decode data sent in Web services calls. JAX-WS defines client APIs for accessing Web services as well as techniques for implementing Web service endpoints. Enterprise JavaBeans (EJB) [7] technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology. Java Persistence API [8] provides an object/relational mapping facility to Java developers for managing relational data in Java applications. It is used to handle the communication between the business tier and the EIS tier (of the generated epp solution). 2.4 Annotation-based Development Annotation-based development is one of the latest Java development trends that enable a declarative style of programming. Annotations are meta-tags introduced into the code to describe package declarations, constructors, methods, parameters etc. This approach simplifies programming and allows indicating whether methods are dependent on other methods, whether they are incomplete, whether Classes have references to other Classes etc. Annotations do not directly affect program semantics, but rather trigger code generation tools to generate additional constructs e.g. a deployment descriptor for a specific Class. Within the code of the generated epp solutions, annotations are used to describe both Web-services and persistence objects. Annotations are defined for Stateless Session Beans (SLSB), Stateful Session Beans (SFSB), Entity Beans, Entity relationships and Object-Relational mappings. A Java Class that stores and maintains information into a database is declared as an Entity Bean. Entity relationships annotations are used to define the connection between two or more Entity Beans. Annotations within Entity Beans are also used for customization purposes, such as the definition of table and field names, configuration properties of each field etc. Session Beans are used for the implementation of Web-services, and Object-Relational mappings are used to define linear relationships between Java objects and corresponding database entities. In addition annotations for security, transactions and internationalization are potential candidates in the generated epp solution. 2.5 Technology Platform The epp solutions generated from the epp AF has to be deployed on an application server. There is no restriction on the type of application server that might be used, as long as it supports EJB 3.0 [7]. Examples of open-source application servers are JBoss [9], Glassfish [10] and Sun Java System Application Server [2]. In the same sense, a developer might choose any type of persistence medium to support the EIS tier of the architecture, as long as it is a relational database. The Java Persistence API abstracts vendorspecific database connection and access details from implementation code. The most popular opensource relational DBMS is MySQL [11] and Derby [12] which is bundled with Sun s application server. Moreover, a BPEL Server such as Open ESB [13] or ActiveBPEL [14] will be used to allow the execution of the BPEL files. The BPEL XML files will be based on the definition of BPEL 2.0 [15] and the BPEL server can be any open source server, which supports BPEL 2.0 and runs on any application server that supports EJB 3.0 We have decided to use the following specific technologies for the target platform of the epp AF: Sun Java System Application Server 9.1: The application server is based based on GlassFish and is a Java Enterprise Edition 5 compatible platform that fully supports the EJB 3.0 standard for developing and delivering server side Java applications and Web services. Open ESB 2.0: The Sun application server does not come with a BPEL engine which is required by the epp AF. Open ESB was chosen since it is an open source project that can easily be integrated with the Sun application server, and it will become a standard way to work with BPEL and service-oriented integration. Copyright ELLECTRA-WeB 2007 Page 13 of 62

14 3. EPP APPLICATION FRAMEWORK MODEL TRANSFORMATION RULES 3.1 Introduction In system development the main goal of the activity is the production of a running system that supports the user requirements. The most important assets for the running system are the developed or generated code that is compiled and executed and the deployment descriptors that are used at deploy time. Transformations can be achieved both from model to model (e.g. by using OMG QVT like languages) [16] and from model to text by using specialised model serialization languages e.g. MOFScript [17]. Figure 2: Transformations from model to text As illustrated by Figure 2 the transformation from model to text can be achieved from different abstraction levels. It is possible to generate code from a quite high-level architecture model, which can be considered a PIM. The transformation logic then will be of high complexity to bridge the detail gap from the PIM to the code. On the other hand, it is possible to create a platform specific model, based on the PIM and then generate textual code from the PSM. The complexity will then be in the model transformation between the PIM and the PSM. The mapping from the PSM to the code should be a simple matter, since the PSM and the code should be closer to semantic isomorphism. Textual transformations should be possible from any model abstraction level. From the transformation architect perspective, the challenge is to find the appropriate level, and to design the transformations. The complexity of transformations will increase proportionally to the abstractness of the models. Therefore, the exact timing, or level of model detail appropriate for transforming from PIM to a PSM rather than PIM to text is not given. Whatever level is chosen, the transformation to text needs to be done at some point [18]. Another approach that has proven useful is to generate code toward an existing framework. These frameworks can be domain or platform specific. In this way the code generators complexity can be kept to a minimum. This approach is often used when developing Domain Specific Languages[19]. 3.2 ELLECTRA-WeB Model to Text Transformation Approach In ELLECTRA-WeB we will utilize the approach that takes a Platform Independent Model (PIM) as input to the transformation and generates as much as possible of the server side epp source code e.g. persistency objects and Web services. Since the epp AF will be used by developers that are not Copyright ELLECTRA-WeB 2007 Page 14 of 62

15 necessarily familiar to MDE and modelling in general, the PIM will be divided into two separate models; the AF_UserModel and the AF_RefrenceModel. An Application developer will be able to model and make changes to the AF_UserModel, but not in the AF_ReferenceModel. The AF_ReferenceModel model will contain specific information pertinent to epp domain of which an Application developer will be able to use in order to describe the required functionality in his/her AF_UserModel. The primarily objective of the AF_ReferenceModel is to abstract the level of complexity, and as the name suggests its role is to be used as a reference model no amendments are possible to be performed on this model. If amendments are required to be carried out in the AF_ReferenceModel this is the responsibility of the Framework developer. The responsibilities and activities of the Framework and Application developers are described in detail in[20]. For instance, the CallForTenders Class of the AF_ReferenceModel will contain all the required details (i.e. attributes, operations, tagged-values and appropriate associations with other Classes) to describe a Call For Tender - in regard to the epp domain. In the AF_UserModel, when an Application developer will stereotype a Class with the CallForTenders name, after the model transformations are executed, in the gerenated code that Class will automatically inherit all of the information of the AF_ReferenceModel s corresponding Class. For further details please refer to section 3.6. On one hand, from the Application developer s perspective, complexity is decreased since model transformation rules use information from the AF_ReferenceModel based on properties defined within the AF_UserModel. On the other hand, a more abstract and simplest interface to the framework is provided. In addition we use models to represent something that normally would have been specified in source code. The generated code uses several existing frameworks as described in chapter 2, this is handled by the application server based on the annotations in the code. 3.3 Overall Transformation Specification Architecture Writing and maintaining model to text transformations is a complex task and therefore care must be taken when it comes to the structuring of the transformation specifications. Utilizing a Model Driven approach, updates and maintenance that normally has been conducted on the source code level is moved to the transformation specifications. Therefore Model to text transformation rules are defined within a collection of specification (files) in a structured way as any other development artifacts. In the ELLECTRA-WeB epp Application Framework there is a main file that is called by the user of the framework. This specification then loads the input models (i.e. PIM) and makes appropriate calls to other specifications that handles the generation of the epp server side solution. Table 1 provides an overview of the transformation specifications that constitutes the ELLECTRA-WeB model transformation library. Table 1: List of model transformation rules Filename Description Group eppmaingenerator The parent file with the appropriate dependencies to the rest of the model transformation files that will be executed by the generation engine. JEE_EntityGenerator The parent file of the Persistent Entity generators Main(All) Persistent Entity (EJB Container) epp_genericentitygenerator Generic Entity generator Persistent Entity (EJB Container) JEE_WebServiceGenerator Generic WS generator Service (EJB Container) JEE_StatelessGenerator Generic Stateless Bean generator Service (EJB Container) epp_refrencemodel_utils Utility rules that handles the usage of the AF reference Generic Utils (All) Copyright ELLECTRA-WeB 2007 Page 15 of 62

16 UML2JavaUtil eppglobalproperties model Utility rules that handles the usage of the UML2 metamodel Global properties collection, used for structure and maintainability Generic Utils (All) Generic Utils (All) epp_organisationgen epp specific code generation epp Specific epp_callfortendergen epp specific code generation eppspecific epp_useraccountgen epp specific code generation eppspecific 3.4 JEE Persistency Generation To enable storage and retrieval of persistent data, the epp solution must generate source code that is capable of communicating with a database to store and retrieve persistent information. This is achieved through the use of JEE Persistency APIs. By generating Plain Old Java Objects (POJOs) annotated with persistency annotations, the application server - at deploy time - will generate the database schemas according to the code. The following sections provide detailed information explaining parts of the developed model to text transformation specifications and the appurtenant epp profile Entity Object Generation From a UML class marked with the stereotype entity in the AF_UserModel, the model transformation will generate a POJO annotated with persistency annotations. It will also generate several queries based on the properties (explained in 3.4.4) Figure 3: A persistent class Running the epp transformation with the model in Figure 3 as input source model, results in the generation of a complete Java source code file that can be deployed on any JEE compliant application server. Based on only five properties (entity stereotype, class name, id stereotype, property name and property type) the complete JEE compliant code displayed in Figure 4 is generated. Copyright ELLECTRA-WeB 2007 Page 16 of 62

17 Figure 4: Generated Java code As it can be observed, a Java file annotated followed by and annotation is generated. The property id:string and stereotyped <<id>> from the model has been transformed to private String id annotated with annotation and in addition public getter and setter methods for the property are also generated. Considering a more realistic scenario, the eppuser will typically consist of several attributes (e.g. firstname, lastname, occupation and so forth) in addition to the single id from Figure 3. In an epp solution these properties are fixed, meaning that it is required by the European Union s epp Web service interfaces. Therefore these attributes are already modelled in the AF_ReferenceModel. An application developer can easily view this model, but changes are not allowed. This additional information is collected from the AF_ReferenceModel by using the TaggedValue property Type s value from the stereotype entity. This part of the model transformations are explained in chapter Relationship Annotation Generation The server side business tier of an epp solution will typically consist of several persistent objects with relations to each other. This must also be reflected in the generated code to achieve the expected behavior. Figure 5 illustrates a UML model that has three classes with the stereotype <<entity>> applied. The classes also have properties, but the important elements in this context are the two UML associations that have their origin in the epporganisation class. The unidirectional OneToOne association between epporganisation and Address means that an epporganisation can have one single address and that only epporganisation has a reference to an address (unidirectional). The second association between epporganisation and eppuser, means that one eppuser can work in zero or maximum 1 organisation, while an organization can have many employees. The arrowheads on the association show that both classes should have a reference to the opposite class. Copyright ELLECTRA-WeB 2007 Page 17 of 62

18 Figure 5: Entity relationships (Bidirectional ManyToOne and Unidirectional OneToOne) To provide any value for the application developer, these associations must also be reflected in the generated code as properties with getter and setter methods. Figure 6: epporganisation relation generation result Figure 6 shows the code snippet that will be added to the epporganisation class based on the associations in the model. The relationship to the eppuser will generate a collection (i.e. List employee) annotated with = worksat ) association annotation that specifies the multiplicity and which attribute (worksat) for the opposite class that corresponds to the relationship (this can be seen in Figure 7). Copyright ELLECTRA-WeB 2007 Page 18 of 62

19 Figure 7: eppuser relation generation result ManyToMany relationships are also supported both as bi and unidirectional. In this case, both classes will have annotation placed over the collection property that corresponds to the opposite class Generating Inheritance Hierarchies One of the most powerful mechanisms in Object Oriented system development is inheritance. This mechanism enables a subclass to inherit all properties and operations from a superclass. The extensions are specified on the subclass, in addition to those provided by the superclass - without replicating the specification. This mechanism is present in our target language Java and also in the UML metamodel (with some minor differences). The model of Figure 8 demonstrates an inheritance relation in UML. The eppuser is the superclass of ProcurementOfficer, which means that the ProcurementOfficer in addition to its own owned elements, it should also provide all the attributes and operations of the eppuser. Figure 8: Entity inheritance Modeling inheritance is simple in UML, the only prerequisite needed is the modeling of the generalization association between any classes. In the Java programming language, the keyword extends followed by the name of a superclass must be added. From the subclass, the superclass Copyright ELLECTRA-WeB 2007 Page 19 of 62

20 (code), its attributes and methods may be reached by using the super keyword. Figure 9: Generated inheritance Java source code The generated Java code of Figure 9 depicts the ProcurementOfficer.java source code file that is generated from the model of Figure 8. In addition to the extend keyword in the class declaration section of the file (that is common Java syntax), two Java Persistency annotations are = eppuser_type ). These annotations are used by the application server at deploy time to specify how to generate the database schemas. For instance, annotation specifies the name of the column that should hold information of what kind of user the instance really is. It is also used by the application server when Java Query Language statements are executed and, therefore they are mandatory in a JEE environment. Figure 10: Inheritance model transformation rules The transformation rules illustrated Figure 10, demonstrates two important transformation rules that are involved in the generation of the source code in Figure 9 from the model of Figure 8. The first rule entity_addinheritanceannot makes a call to the uml_getsuperclassname; this rule checks if the class in context uml.class has a generalization target element. If this rule returns a string variable (if(targetname!=null)) the inheritance annotations are added to the Java file with the values according to the generalization relationship Java Query Language Generation Java Query Language provides (as the Java Persistency API) an annotation extension to POJOs that makes it possible to implement search and retrieval queries on entity objects in a clean and simple way. These queries can, (as we will see in the section on service generation) be exposed as Web services. Copyright ELLECTRA-WeB 2007 Page 20 of 62

21 Figure 11: Model transformation rule that generates JQL implementation The JQL generation, for each property of every class stereotyped with <<entity>> will generate a query to retrieve all objects matching the value provided as input parameter to the query operation. In Figure 4 it can be observed that two queries have been generated, findall and findbyid. 3.5 JEE Service Generation In order to access persistent data, CRUD operations on the persistent objects need to be created i.e. implemented. The epp AF enables the user to model this in a simple and abstract way by applying the stereotype <<service>> to a UML class. The class must then be connected to the persistent object representation with a bidirectional association stereotyped <<manage>>. The service modeling is shown in Figure 12. Figure 12: Modelling a service that manages a collection of persistent objects Running the epp transformation with the above model as input will result in the generation of a Java Session bean. The session bean will have a reference to the EntityManager that can access the persistent objects and several utility methods such as mergeentity(object entity) and persistentity(object entity). Copyright ELLECTRA-WeB 2007 Page 21 of 62

22 Figure 13: Generated service as JEE Session Bean It will also be possible to generate statefull session beans from the model. In order to accomplish this, the application developer must set the Tagged value ServiceType in the service stereotype to Statefull. The profile definition is shown in Figure 14. Figure 14: epp service stereotype JEE Web Service Generation In Figure 14 it can be observed that the stereotype <<service>> also has a Boolean property named ExposeAsWebService. Setting this property to true will result in the generation of a Web service implemented as a stateless session bean. Figure 15: Generated Web service implementation Copyright ELLECTRA-WeB 2007 Page 22 of 62

23 From the code snippet of Figure 15 it can be observed that that the stateless session bean apart from being annotated it is also annotated with When deployed on the application server, this will result in the generation of files that will expose the service through a Java Web service and automatically generate a WSDL[21] file on where all the methods stereotyped will be included. Figure 16: A method that will be exposed as a Web service For instance the createeppuser method of Figure 16 is annotated and will be exposed as a Web service. In addition, it can be observed that the creation also includes the setting of the relation property worksat. All these are handled automatically in the code generation, and no manual updates are required in the code Java Query Language Calls Generation In it has been described how from an entity object, JQL statements where generated for each property from an entity object. In the corresponding service that manages the persistent object, calls to these queries will also be generated so that the queries will be accessible to the GUI designer. The code section below shows the generated methods that will be contained in the stateless session bean eppusermanager. Figure 17: Generated JQL methods 3.6 Specializing the Model Transformations Towards epp The model transformation rules described in the previous sections are generic, and can in theory be used to generate JEE system solutions in several different domains. This is a big advantage knowing the impact of reuse in software engineering [22]. But making the model transformations generic also means that epp specific functionality is not targeted in the transformation specification. In the ELLECTRA-WeB AF this will be handled by several epp specific model transformations that will be used in addition to the generic ones. We are also making use of an AF_ReferenceModel that contains epp specific information that is used as input to the model transformations. The alternatives are to hard-code this information in the model transformation specifications or require that the application developer models everything in the AF_UserModel. The first approach often leads to complicated model transformation rules that are difficult to maintain. Similarly, the second approach will make the AF_UserModel over complicated. The usage of two input models separates common epp functionality from the AF_UserModel so that the application developer can focus on the variability aspects of the solution, while still keeping the model transformation rules as generic as possible [1]. Copyright ELLECTRA-WeB 2007 Page 23 of 62

24 As we can see from the transformation declaration in Figure 18, the transformation JEE_EntityGen has two input models (uml and ref) of type UML2 as input. Uml is the user model that the Application developer will model, and the ref model is the pre-made reference model supplied with the ELLECTRA-WeB AF. Figure 18: Text transformation declaration using two models as input The reference model will contain an extensive amount of epp specific information that the generic model transformation rules will utilize. A snapshot of a simplified reference model is shown in Figure 19. Figure 19: Simple epp Reference Model example The simplified reference model contains epp specific information e.g. the UserAccount class. It has several properties that is common to all epp solutions e.g. username and password. This model will be available in the epp AF and automatically be loaded into the transformation execution. In this instance, Application developers will only have to focus on the specialisation and customisation needed in their specific solution. To enable this functionality the stereotype <<entity>> has a Tagged Value EntityType. The EntityType is an enumeration that has several epp specific values including the value Generic. Setting this value to e.g. UserAccount will make the code generators collect all the information from the UserAccount class in the reference model and add this additional information to the class from the user model. Figure 20: Entity stereotype specification enabling epp specific code generation Copyright ELLECTRA-WeB 2007 Page 24 of 62

25 The model transformation rules that implement the ability to retrieve information from the reference model is specified in epp_referencemodel_utils.m2t. An example of such a rule is getrefclass() and is depicted below. Figure 21: Using the rule getrefclass() from the entity generator The tagged value EntityType is also the value used to generate epp specific code from the epp specific generators e.g. epp_organisationgen.m2t and eppcallfortendergen.m2t. A conditional statement in the MOFScript specification will check this value before calling the epp specific rules that have been defined. If the type value is generic no actions will be taken. Copyright ELLECTRA-WeB 2007 Page 25 of 62

26 4. DEVELOPMENT TEST CASE 4.1 Introduction to Test Case In this chapter we will present a test case model that will be used as input to the specified model transformation rules. The test case will serve as an intermediate validation of the produced transformation specifications in relation to the requirements specified in D3 Application Framework Specification and Concept Prototype [20]. The validation is not meant to provide an in-depth validation, as this is part of WP4 Trials and evaluations. 4.2 Test Case Models The different views of the model that will be used for demonstration are shown in the following figures. In addition, the AF_ReferenceModel presented in Figure 19 will be used as additional epp specific input. Figure 22: Entity view of Test Model The test model consists of four classes that need an EJB Java Persistency API implementation (they all have the <<entity>> stereotype applied). User defined properties are added and there are three associations that describes the relationship between them. From this part of the AF_UserModel we will get a fully functional implementation conforming to the latest specification of JEE Persistency API. Properties from both the AF_User Model and the AF_ReferenceModel will be generated as private attributes. In addition public accesor methods operating on these properties will be generated. The generated Java classes will also include JQL statement implementations that will operate on all the specified properties and association properties. At this time, from an epp stereotyped model, we have generated the Persistent Objects and the connection to the database (shown in Figure 1). Deploying the annotated code on the application server will generate and execute the database schema creation scripts. This will enable the application to store and retrieve entity data from an external DB e.g. Derby, MySQL or Oracel. The JPA source code is placed in a package org.ellectraweb.entity. This value has been collected from a tagged value that is part of the eppmodel [1]stereotype and has been applied on the model element. Since the generated epp System Solution should be based on the Service Oriented Architecture, the functionality can be exposed as Java Web services. Therefore we need classes that implement an EntityManager [23] that will be capable of accessing the persistent unit generated and provide the appropriate Web services that can be used to reflect the functional requirement of an epp solution. Copyright ELLECTRA-WeB 2007 Page 26 of 62

27 Figure 23: Service view of Test Model The service view shows (for demonstration purposes) that every persistent object has a service that can provide CRUD operations as Web services. The Application developer will have to model four new classes and apply the stereotype <<service>>. The stereotype has a Tagged value: ExposeAsWebService:Boolean that must be set to the value true (see Figure 14). Then the service classes must be connected to the persistent classes with a bidirectional relationship stereotyped with <<manage>>. Based on the model presented above, an execution of the transformation specifications will result in the generation of two java packages, namely entity and service. Each package will contain four java source code files (code segments may be viewed in Appendix A: Generated Code Examples). By running the accompanying Ant build file, the generated code will be packaged in a Java Archive File (jar) that can be deployed on any JEE compliant application server. In addition to the generated database schemas, accompanying web service description language (WSDL) files will also be generated according to the system s functionality. 4.3 Validation of the Current Transformation Specifications Several requirements that the ELLECTRA-WeB AF must fulfil were identified and documented in [20]. The current transformation specifications address several of these requirements: Open Source: The developed transformation specifications are open source and can be executed on the open source model to text transformation engine MOFScript [17] (the input models are produced in the open source tool Papyrus [24]. Increased Productivity: This requirement spans several different aspect of the AF but in relation to the presented model transformation rules and the models used as input two sub categories are important - Automatic generation of code from models: The model transformations automatically generate an extensive amount of the server side code. Based on the simple model presented, eight java classes containing approximately 1000 lines of code in total are produced. If all the required functionality can be supported will be investigated in the second release of this deliverable. - Easy to use: The transformations can be executed by a simple mouse click, and we also believe that the models required as input are simple to create. Copyright ELLECTRA-WeB 2007 Page 27 of 62

28 Increased quality: The generated code is well structured and documented (the current version does not provide complete documentation), and it follows common JEE best practise (e.g. all attributes are declared private and can not be accessed directly). Generated code has also proven to have fewer errors, where fixes may be applied only in one place (i.e. within the model transformation rules). Scalability and extensibility: Due to the architecture of the transformation specifications they can easily be extended (and they will be in new iterations), either by adding new rules to an existing specification or creating a complete new. The model transformation engine utilised also allows a new specification or rule to extend an already existing one. The models used as input can also be of unlimited size - it is a matter of processing power. Interoperability: The generated code implements services based on the JAX-WS API [6] and are therefore interoperable by following the SOA paradigm. Portability: The generated code can be deployed on any JEE compliant application server and run without manual modifications. The intermediate validation concludes that the transformations in their current state already partially fulfils several of the epp Application Framework requirements. They must however be extended and improved to support more epp specific scenarios. Copyright ELLECTRA-WeB 2007 Page 28 of 62

29 5. CONCLUSION The deliverable consists of a prototype implementing several transformation specifications that takes the models as defined in WP2 as input and generates source code output. The generated output is state of the art Java Enterprise Edition technology that can be deployed on any JEE compliant application server. The services generated are implemented as JAX-WS (Java Web services) and as a consecuence the code is both portable and interoperable. The transformation specifications demonstrate a partially novel approach to code generation through the separation of the User Model and the Reference Model. This introduces some new complexity aspects to the transformation specification implementation, but provides an easier and more user friendly interface to the Application developers of the ELLECTRA-WeB epp AF. Similar approaches have also been followed in earlier and ongoing research work especially in the Aspect Oriented community where you have one base and several aspect models as input to a model to model transformation. Our solution is however specialised towards epp solutions and moved down to the model to text transformation level. The utilisation of tagged values in the proposed profile, enables the code generators to produce both generic JEE source code from the AF_UserModel and epp specific code that is modelled in the AF_ReferenceModel. In general the deliverable has demonstrated and explained a set of transformation specifications that can be used to generate parts of a state of the art JEE epp solutions easily and cost efficient. The current transformations do not cover all layers and aspects of the complete solution but this will be extended and improved towards the second release of the deliverable. Copyright ELLECTRA-WeB 2007 Page 29 of 62