A workflow based architecture for Public Key Infrastructure

A Workflow Based Architecture for Public Key Infrastructure Improvements to an existing open source Certified Authority application JOHAN EKLUND Master of Science Thesis Stockholm, Sweden 2010 A Workflow Based Architecture for Public Key Infrastructure Improvements to an existing open source Certified Authority application JOHAN EKLUND Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2010 Supervisor at CSC was Kjell Lindqvist Examiner was Karl Meinke TRITA-CSC-E 2010:047 ISRN-KTH/CSC/E--10/047--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc A workflow based architecture for Public Key Infrastructure Improvements to an existing open source Certificate Authority application Abstract EJBCA is a Certificate Authority application currently using the Enterprise JavaBeans 2.1 framework. In the first part of this degree project, workflow management software was evaluated for the purpose of enrolling end users and servers for digital certificates in a Public Key Infrastructure. A workflow in this context is all the necessary high level tasks needed to complete the enrollment process. The jBPM workflow management software was found to be the best choice out of the evaluated open source applications and frameworks. A proof of concept application was implemented using the jBPM workflow execution engine. The execution engine was not working well enough to be used for certificate enrollment. A revisit to this field in the future is recommended. In the second part of the degree project, the Java frameworks Spring 2.0 and Enterprise JavaBeans 3.0 were evaluated for the purpose of replacing Enterprise JavaBeans 2.1 as the framework used for EJBCA. In the theoretical study Enterprise JavaBeans 3.0 was selected for further evaluation. The selection was made due to its stability, potential to simplify maintenance and similarities with the currently used framework. A practical evaluation of the selected framework was performed using a selection of components of EJBCA. The results from the practical evaluation were sufficient to motivate a migration to Enterprise JavaBeans 3.0. A migration strategy was created based on the findings from both the theoretical study and the practical evaluation. Arkitektur för Public Key Infrastructure baserad på arbetsflöde Förbättringar av en existerande certifikatauktoritetsapplikation baserad på öppen källkod Sammanfattning EJBCA är en certifikatauktoritetapplikation som använder ramverket Enterprise JavaBeans 2.1. I första delen av examensarbetet utvärderas mjukvara för styrning av det arbetsflöde som krävs för att registrera och ge ut digitala certifikat till användare och servrar i en Public Key Infrastructure. Ett arbetsflöde är i detta sammanhang de delmoment som krävs, ur ett högnivåperspektiv, för att genomföra registrering och utgivning. Arbets flödemjukvaran jBPM var det bästa alternativet av de utvärderade applikationerna och ramverken. En testimplementation baserad på jBPMs motor för exekvering av arbets flöde gjordes, men motorn fungerade inte tillräckligt bra för att kunna användas för registrering och utgivning av certifikat. En ny utvärdering av området i framtiden rekommenderas. I andra delen av examensarbetet utvärderades Javaramverken Spring 2.0 och Enterprise JavaBeans 3.0 som ersättningskandidater för EJBCAs nuvarande ramverk Enterprise JavaBeans 2.1. I den teoretiska utvärderingen valdes Enterprise JavaBeans 3.0 på grund av dess stabilitet, potentiella möjlighet att förenkla underhåll och likheter med nu varande ramverk. En praktiskt utvärdering av det valda ramverket gjordes med hjälp av ett urval av berörda komponenter från EJBCA. Resultaten av den praktiska utvärderingen var tillräckliga för att motivera en migrering till Enterprise JavaBeans 3.0. En migreringsstrategi skapades utifrån resultaten av både den teoretiska och praktiska utvärderingen. Preface I would like to thank • Tomas Gustavsson, Chief Technical Officer of PrimeKey Solutions AB for excellent support, encouragement and feedback during the entire degree project. • Kjell Lindqvist for all the feedback and having patience with this project that ran for over two years. • The EJBCA community and all the other developers at PrimeKey (especially for working hard to give me time to concentrate on this project). • All of those in the other open source communities affected by this project. Contents 1 Introduction....................................................................................................................1 1.1 Background..............................................................................................................1 1.2 Problem statement....................................................................................................4 1.3 Report outline...........................................................................................................5 2 Workflow languages and page flows..............................................................................6 2.1 Workflow languages................................................................................................6 2.2 Workflow languages and standards ........................................................................7 2.3 Page flows................................................................................................................8 3 Workflow and page flow evaluation..............................................................................9 3.1 Workflow evaluation...............................................................................................9 3.2 Page flow evaluation..............................................................................................10 3.3 Test summary.........................................................................................................11 4 jBPM evaluation...........................................................................................................13 4.1 Scope of evaluation................................................................................................13 4.2 Platform requirements............................................................................................14 4.3 Tested workflows...................................................................................................14 4.4 Outline of solution.................................................................................................17 4.5 Conclusions............................................................................................................17 5 Java framework comparison.........................................................................................19 5.1 Basic concepts........................................................................................................19 5.2 Theoretical Spring framework evaluation.............................................................20 5.3 Theoretical Enterprise JavaBeans 3.0 evaluation..................................................20 5.4 Enterprise JavaBeans 3.0 is the best option...........................................................21 6 Enterprise JavaBeans 3.0 evaluation............................................................................22 6.1 Scope of evaluation and methodology...................................................................22 6.2 Java Persistence API..............................................................................................22 6.3 Stateless Session Beans..........................................................................................23 6.4 JavaServer Faces 1.2..............................................................................................23 6.5 Test application structure.......................................................................................23 6.6 Web Services.........................................................................................................23 6.7 Conclusion.............................................................................................................23 7 Final discussion............................................................................................................25 7.1 The lack of executable workflow solutions...........................................................25 7.2 EJBCA migration strategy.....................................................................................26 7.3 Future work............................................................................................................26 8 Abbreviations................................................................................................................27 References......................................................................................................................29 Appendix A: Tasklist application implementation details............................................32 Appendix B: Enterprise JavaBeans 3.0 evaluation details.............................................40 Appendix C: Migration strategy details..........................................................................58 Appendix D: Java frameworks.......................................................................................66 1 Introduction This chapter will give the reader a quick background and motivation for this degree project. 1.1 Background EJBCA is a free open source Public Key Infrastructure Certificate Authority software. All around the world there are major installations in production, where the application is used in many different ways and in many different environments. PrimeKey Solutions AB is the maintainer of EJBCA. Public Key Infrastructure Public Key Infrastructure is a vital part of IT security and “consists of protocols, services, and standards supporting applications of publickey cryptography” [36]. Public Key Infrastructure is the back bone of Internet security, and is for example used as basic technology every time a secure website is visited. In publickey cryptography a keypair, consisting of a private and a public key, can be used to create (digital) signatures and encrypt data. Signatures are created with the private key and can be verified using the public key. A public key certificate1 contains the public key and information about the holder of the matching private key. Given a certificate and a signature it is possible to verify that a signature has been created by the holder of the private key matching the public key in the certificate. A successful signature verification also means that the identity of the private key holder that created the signature is known, since this information is available in the certificate. The information in the certificate has to be correct and trustworthy. A certificate is always signed by a Certificate Authority's private key to guarantee that the information about a holder of a private key is correct. The Certificate Authority has itself a certificate with a matching public key to its private key. Given this Certificate Authority certificate, and that we trust this Certificate Authority, any information in certificates issued by the authority can be trusted. A simple use case is communication over an insecure network. Two users can verify each others identities without ever having met before if they both have valid certificates and trust the Certificate Authority that issued the other user's certificate. The role of a Registration Authority in a Public Key Infrastructure is to correctly identify and collect information about the private key holder that should be issued a certificate. Public Key Infrastructure is a mature and well researched area. The first design of a global infrastructure was done at MIT and standardized by the Internet Engineering 1 The term ”certificate” is used for “public key certificate” throughout this report. 1 Task Force in 1993 [25]. Other types of infrastructures have been suggested in numerous papers, a proposal for a global certification infrastructure is described in [11]. For the purpose of this degree project, Public Key Infrastructure is defined as the management of public keys and certificates. Workflow Workflow in a general sense means how something can be done. In this report a work flow is a description of how a set of tasks can be performed by different people and/or systems to reach a result. The description should not be too detailed and it is more important to describe who does what, than to get a detailed view of how each person or system in the workflow performs assigned tasks. Assigning tasks and keeping track of who should do what is called workflow management. Workflows in a Public Key Infrastructure In a Public Key Infrastructure one of the core tasks is making sure that a certificate is issued to the right private key holder. The Registration Authority is responsible for collecting correct data about the private key holder. There are many different ways of doing this depending on security requirements, history, economics and other factors. Almost every large organization have their own way of performing this task. The process of collecting the information about the holder, and issuing the certificate is called an enrollment process. A workflow in this context is all the necessary high level tasks needed to complete the enrollment process. Typically there is a mix of both human tasks and automatic, back ground processing. A typical workflow of such an enrollment process for an imaginary organization could look like this: • One of the server administrators generates a new asymmetric keypair on a server. • One of the server administrators generates a certificate request and sends it to the Registration Authority administrators. • One of the Registration Authority administrators validates the request and approves or rejects the request. • If approved, the certificate request is sent to the Certificate Authority. • The Certificate Authority issues a certificate from the certificate request and sends it back to the server administrators. • One of the server administrators installs the issued certificate on the server. In the workflow above, each list item is a high level task of the workflow. Each task is assigned to a role or a system. 2 The different tasks of a workflow can be represented in many different ways, including the listform used above. A graphical representation (illustration 1) might give a better overview of the whole process and an XML representation might be interpreted and executed by the execution engine of workflow management software. Illustration 1: A graphical representation of the example workflow The main point of using workflow management is that there is a centralized view of the process and current progress of ongoing workflows. Changes in the workflow can be made in a single place and it is easier to get a good overview of the system compared to a decentralized system. 3 The Enterprise JavaBeans 2.1 framework Java Community Process's Enterprise JavaBeans 2.1 is a standardized way of building modular serverside enterprise applications where the framework provides transactions integrity, persistence and security. The first public release of EJBCA in 2001 was using the Enterprise JavaBeans 1.0 standard and since then the project has grown to over 200 000 lines of code. EJBCA runs on many of the major application servers and databases. The current version of EJBCA (3.9.2), is based on the Enterprise JavaBeans 2.1 standard. This is part of the Java 2 Enterprise Edition standard and has been superseded by the Java Enterprise Edition 5 standard. As a result of this, the XDoclet tool used for automatic code generation has not been active since 2004 [43] and the last released version cannot be used together with Java 1.5 features like generics or annotations. In Enterprise JavaBeans 2.1, the support for different databases is very tightly coupled to the application server and a change in the database schema requires large amounts of manual work and changes to the configuration. Furthermore, binding between different Enterprise JavaBeans 2.1 components requires application server dependent configuration due to lack of proper standardization. 1.2 Problem statement This section describes the motivation and limitation of the degree project. Purpose The purpose of this project is to investigate and find answers to the following questions: • Is there an open source workflow management framework or tool that can be used to ease the adaptation of EJBCA to different business processes? • What is the best suited replacement for the Enterprise JavaBeans 2.1 framework for EJBCA? Limitations The field of workflow management frameworks is full of buzzwords and promises, and therefore the initial task was to look into how to refine selection criteria and limit the scope. The initial approach was to find out if there were any solid standards in this field that could be used. Business Process Management Notation, Unified Modeling Language 2.0 Activity Diagrams, XML Process Definition Language, Business Process Execution Language and jBPM Process Definition Language was studied. While the last language is not a formal standard, it was included upon request by PrimeKey. 4 Enterprise JavaBeans 3.0 and Spring 2.0 were selected as future candidates for replacing the old framework. As an additional requirement, there had to be a free open source implementation of any tools, frameworks or libraries used by EJBCA. EJBCA is licensed under the GNU Lesser General Public License that grants users the right to modify, use, republish and integrate other applications with EJBCA for free as long as the same rights are passed on to derived software. If a tool or dependency of EJBCA would not live up to the same level of freedom we would not be able to: • Expect that all users in the EJBCA community are able to use it. • Branch it and maintain our own version if the project dies or starts evolving in the wrong direction from the EJBCA developers' point of view. • Bundle required libraries with EJBCA. Whenever “open source”, “free open source” or “free” is used these freedoms are implied. 1.3 Report outline The first half of the report is dedicated to workflow management. The next chapter will explain more in depth what the theoretical options are when it comes to workflow languages. Chapter 3 summarizes a basic evaluation of different existing open source workflow management frameworks and tools. Chapter 4 describes the findings from an evaluation of implementing Public Key Infrastructure workflows using the jBPM work flow management framework. The second half of the report is dedicated to finding a new Java framework for EJBCA. Chapter 5 compares the two Java frameworks Spring 2.0 and Enterprise JavaBeans 3.0 for use with EJBCA. Chapter 6 describes an evaluation of Enterprise JavaBeans 3.0 on different application servers and databases in brief. In chapter 7, the results from both parts of the report is summarized suggested future work is presented. Appendix A describes the details of the jBPM evaluation summarized in chapter 4. Appendix B describes the details of the JavaBeans 3.0 evaluation summarized in chapter 6. Appendix C describes the most important details of the EJBCA migration strategy based on the findings during this degree project. Appendix D describes the two Java frameworks Spring 2.0 and Enterprise JavaBeans 3.0 in depth and gives a brief description of the upcoming Enterprise JavaBeans 3.1 standard. 5 2 Workflow languages and page flows A centralized process of human and machine interactions can be described with a workflow language. Such a high level language can be executable and/or have a graphical representation. A page flow is a description of how and in what order to serve a set of web pages that can be used for human interaction in a workflow. 2.1 Workflow languages A more formal definition of a workflow (also referred to as a business process) than in section 1.1 is “a series of related actions between people and a computer system” [42]. Managing workflows is called workflow management or business process management. A workflow can have a graphical representation and/or a nongraphical representation. Such a representation is called a workflow language. The system that can take a work flow language as input and keep track of the execution is defined in [42] as a workflow management system. A workflow management system is also referred to as a workflow engine. Using such systems/engine could have several benefits: Enterprise Application Integration In a Service Oriented Architecture several different applications could be tied together using a workflow language describing the interactions. An example of this is Web Services Business Process Execution Language (WSBPEL), that allows new Web Services to be created from existing Web Services. This means that old investments in legacy applications can be reused and best of breed components can be brought into the system [1]. Software that interacts with humans In a system where several different people in different roles interact with the workflow, regular programming becomes complicated. The workflow engine keeps track of the current state of the process, a mechanism that the programmer would otherwise have to implement [42]. Maintainable and adaptable applications A better centralized overview of the system will help optimizing and simplifying the workflow. Changing the workflow will be much simpler than trying to change an application that is hardcoded for a specific purpose. This allows an iterative development model where business analysts speaks the same language as the developers [42]. 6 2.2 Workflow languages and standards Listed below are the major existing standards and languages for describing workflow. Business Process Modeling Notation Business Process Modeling Notation (BPMN) is a standard for graphically describing the workflow of business processes and is maintained by the Object Management Group [28]. The graphical representation is referred to as Business Process Diagrams. BPMN can be expressed in XML Process Definition Language [44]. XML Process Definition Language XML Process Definition Language (XPDL) is a standard from the Workflow Management Coalition for exchanging business process definitions between different workflow tools [44]. XPDL is designed to keep track of both the graphical representation and process semantics. The XPDL 2.0 standard was developed to be able to represent all aspects of the BPMN Business Process Diagrams. According to [41], the XPDL specification allows vendor specific extensions through “extended attributes”. This might lead to different tools being incompatible. XPDL itself is available without licensing. Unified Modeling Language 2.0 Activity Diagrams Unified Modeling Language 2.0 Activity Diagrams (UML 2.0 AD) is a graphical representation of business processes adopted by the Object Management Group and is described in [29]. Web Services Business Process Execution Language Web Services Business Process Execution Language 2.0 (WSBPEL) [33], also known as Business Process Execution Language (BPEL), is a standard from the Organization for the Advancement of Structured Information Standards (Oasis). WSBPEL is an executable language designed to orchestrate Web Services by modeling highlevel state transitions of a business process. The transitions are messagebased, meaning that the definition specifies reactions upon incoming messages. WSBPEL 2.0 does not support human tasks or subprocesses, which makes it unsuitable for regular Business Process Modeling. Extensions like BPEL4People tries to add support for human tasks [10] by adding concepts like users, roles and ownership of tasks. To use the WSBPEL specifications, a royaltyfree license from the WSBPEL stake holders (Microsoft, IBM, BEA, SAP and Siebel) must be obtained. This license might not be compatible with LGPL for derived software [35]. jBPM Process Definition Language jBPM Process Definition Language (JPDL) is a proprietary workflow language described in [34] for the LGPL jBPM workflow execution engine from Red Hat. JPDL can be used to manage workflows with tasks witten in Java or to organize in what order 7 web pages are served to a web client user. A good description of JDPL can be found in [8]. Business Process Definition Metamodel Business Process Definition Metamodel is a new proposed standard currently in the final phase of adoption at the Object Management Group. It tries to be more exchangeable between vendors than BPMN and includes service orchestration. Business Process Definition Metamodel is based on XML Metadata Interchange. No open source implementation exists as of spring 2008 and therefore this language will not be evaluated. 2.3 Page flows Page flows are not suited for describing workflows, but are a way to handle conversational user interactions. By decoupling navigation from the actual web pages, changes can be made to the page flow more easily. A stated before, the workflows for issuing certificates contain a large amount of human interaction. To achieve platform independence, these human interactions should be done through a web based user interface. My hypothesis was that page flows could simplify the human interactions with a workflow application for the developer. Spring Web Flow According to [21], Spring Web Flow can be used as an embedded page flow engine with JavaServer Faces or other frameworks. A copy of each step of the navigation is kept to allow the users to go back in the browsing history. The state of the conversation is kept on the clientside to reduce the webservers memory footprint. Users can have several different conversational sessions open at the same time. Spring Web Flow uses a proprietary XML language to describe page flows. Seam Pageflow Seam Pageflow is built on the jBPM workflow engine and uses a simplified version of the JDPL language. The state of the conversation can be persisted in a database to reduce the webservers memory footprint. Users can have several different conversational sessions open at the same time. JavaServer Faces Navigation Rules Navigation Rules are a part of the JavaServer Faces standard. These simple rules allow navigation between web pages to be conditional and specified in a separate XMLfile. The outcome of a method backing an action of a commandtag is translated with help of the navigation rules to the proper page. As for the other page flow implementations, this separation of navigation and view makes changes to the navigation easier when a page is renamed or the flow changes [3]. The state of user interactions with the server can be kept for each request, for the entire session or during the application uptime [4]. 8 3 Workflow and page flow evaluation There are many frameworks and tools for the management of workflows and page flows. This chapter gives a quick overview of the available free tools and frameworks, and evaluates their potential for being used in EJBCA. 3.1 Workflow evaluation This section describes potentially useful workflow frameworks and tools. Requirements In two articles, [12] and [22], the authors describe how well the workflow languages BPMN, UML 2.0 AD and WSBPEL can capture different interactions in a workflow. To be able to use these results a similar study for XPDL and JPDL has to be done and a thorough description of the workflows in EJBCA is required. There are however other strongly limiting factors that affect the choice of a suitable workflow management system: The solution must be executable An executable solution requires the use of one of the XPDL, WSBPEL or JPDL languages, or a tool able to translate a given workflow representation into one of these languages. Since we want to use a workflow engine for keeping track of which task is assigned to whom, WSBPEL is not a good choice. Left to evaluate are XPDL and JPDL. The workflow execution engine should integrate well with EJBCA The preferred solution should not exclude the use of either Enterprise JavaBeans 3.0 or Spring 2.0, since one of them will probably be chosen as the next framework for EJBCA. If custom code for tasks that interact with EJBCA is required, the code should preferably be written in Java to be able to use one of the EJBCA client libraries. The tools must be free as in freedom A quick survey of the available tools showed that the number of available free open source tools for modeling and executing business processes was limited, and many of the projects were very basic or stale. I estimate that first describing the most common Public Key Infrastructure workflows for EJBCA and then converting them from one language to another is a time consuming 9 effort. If the language chosen initially is not supported by the available tools the effort would have been spent in vain. Therefore, it makes more sense to start investigating the available alternatives to see what languages that are supported in practice first. Where nothing else is stated the tested version is the latest available during spring 2008. XML Process Definition Language 65 different implementations of the XML Process Definition Language (XPDL) standard are listed at the Workflow Management Coalition's website [45], but only a few of them were available under a Open Source license. None of the tested frameworks or tools fulfilled the requirements. jBPM Process Definition Language There is only a single editor and workflow execution engine available for the jBPM Process Definition Language. Writing custom code that interact with the jBPM work flow execution engine can be done rather easily with JBoss Seam according to [9]. The jBPM samples included with the JBoss Seam 2.1.0 package are simplified examples of such custom code and works flawlessly. Practical tests showed that it was easy to add custom Java code to the different nodes and transitions, and all the process variables can be accessed from the code. The project is a very active one with new releases in short intervals and it has a large open source company (Red Hat, Inc.) backing it. This suggests that any problem found in this initial study would soon be corrected. 3.2 Page flow evaluation This section describes potentially useful page flow frameworks and tools. Spring Web Flow Spring Web Flow applications can be developed with Spring's workflow editor that runs inside the Eclipse IDE. However, version 1.0.6 of this editor can only load existing samples and not create new ones. Seam Pageflow The tested version of Seam Pageflow was a part of the JBoss Seam 2.1.0 package. The scope of the Seam framework is much larger than page flows and only using the page flow part does not make sense. JBoss Tools (http://www.jboss.org/tools/) are used for graphical design, just as for the jBPM Process Definition Language workflows. The editor has several minor bugs, but was still usable and a couple of simple created Pageflows executed as expected. 10 JavaServer Faces Navigation Rules There are several editors for creating JavaServer Faces Navigation rules, for example Eclipse Web Tools Project 1.5+, JBoss Tools and NetBeans IDE. The first two were tested and the resulting Navigation Rules executed as expected. 3.3 Test summary None of the tested workflow frameworks/systems are close to fulfilling all the requirements. Table 1 on page 12 lists the tested software and its properties. The best and most promising alternative for a proof of concept is to use the jBPM execution engine with a custom frontend and the JPDL graphical editor. 11 Application/project Language Type Comment Intalio BPMN BPMN Editor and engine Not free enough. STP BPMN Modeler BPMN Editor No working execution engine. Enhydra JaWE XPDL Editor Not working properly. Not free enough. JPEd XPDL Editor Not working properly. AgilPro 1.4.0 XPDL Editor Not working properly. Java Workflow Toolbox 0.4 XPDL Editor Not working properly. ProEd XPDL Editor No working execution engine. Enhydra Shark XPDL Engine Not free enough. AgilPro Simulator XPDL Engine Not working properly. WfMOpen XPDL Engine Not working properly. JawFlow XPDL Engine Dead project. Open Business Engine XPDL Engine Not working properly. Project is not active. OAC Business Process Management XPDL Engine Not general enough. Bonita XPDL Engine Not working properly. Open For Business XPDL Engine Not general enough. jBPM 3.1.4 JPDL Editor and engine Not working properly. jBPM Page Flow JPDL Editor and engine Page flow framework. Minor bugs in the editor. Spring Web Flow “XML” Editor and engine Page flow framework. Graphical editor does not work. JavaServer Faces Navigation Rules “XML” Page flow framework. Table 1: Summary of tested workflow and page flow tools and frameworks 12 4 jBPM evaluation In the theoretical comparison of the different workflow management systems, the jBPM workflow framework was selected for further evaluation. The workflow framework will be used in a new small frontend application for issuing certificates with the Public Key Infrastructure software EJBCA. 4.1 Scope of evaluation In the theoretical and practical study of the different workflow languages and engines the jBPM workflow execution engine with the jBPM Process Definition Language (JPDL) graphical editor was selected for further evaluation. Since Seam's Pageflow uses the same execution engine and graphical designer, I assumed that it would be easy to use Pageflows for workflow tasks assigned to humans. The goal was to test using jBPM for the workflows combined with Seam's Pageflow for human tasks to fully understand the benefits and problems of this workflow technology when used within a Public Key Infrastructure. To evaluate these components a small tasklist application was created. The tasklist application has the role of a Registration Authority in the Public Key Infrastructure, meaning that it is responsible for enrolling users or servers. The tasklist application uses a Certificate Authority in a running EJBCA instance for issuing the certificate and is also responsible for making sure that the right user or server gets the resulting certificate. Communication with EJBCA is done through a protocol designed for environments where only outgoing traffic is allowed from the EJBCA instance. Requests to and responses from EJBCA is stored in a database running on the same machine as the task list application. A service running in EJBCA polls the database at regular intervals. There are several reasons why this is a good setup for evaluation: • Thanks to the isolation of the protocol, there are few dependencies on existing technology. This means that the environment can be chosen to best suit jBPM and avoid problems that are not related to the tested technology. • A Registration Authority is a component where many users of EJBCA want organization specific customizations. Being able to quickly adapt the workflow here has the potential to save large amounts of development. • Work on these tests can be done in parallel with any work on EJBCA, without having to compensate for changes in the main project as long as the used protocol is stable. This ensures that the finished software is always up to date with the latest EJBCA release. 13 4.2 Platform requirements Nor the Seam Framework or jBPM have any formal requirement on Enterprise JavaBeans or the use of an application server. Both jBPM and the EJBCA database protocol client libraries depend on Hibernate for persistence. This means that the evaluation project can be deployed as a simple Web Application. This lightweight approach would allow the use of a simple Servlet container like Tomcat instead of an application server. 4.3 Tested workflows The selected workflows are similar to requests by customers of PrimeKey Solution AB or requests on EJBCA's public forum and mailing list on SourceForge. There are several roles defined in the workflows below: • An administrator is authorized to approve or reject requests. • A registrator is authorized to enroll (or request to enroll) for a certificate on behalf of a user or server. • A user is authorized to enroll (or request to enroll) himself/herself All administators are part of the group “administrators” and all registrators are part of the group “registrators”. Group and role is used interchangeably in this chapter. In all the workflows below, every new task for the administrators or registrators generates an email to the group. Another email is sent to the same group when someone from the group has reserved or started working on the task. A keystore is a bundle of a certificate and an asymmetric keypair generated by the Certificate Authority. Workflow1: Public registration for server generated keystore A screenshot of the graphical representation of this workflow from the JBPM workflow editor is shown in illustration 2 on page 16. • A user registers data that should go into the certificate, an email address and additional contact info. • An administrator approves or rejects the request. • If approved, a notification email is sent to the user's email address with a URL to the new keystore. Otherwise a rejection email is sent and the workflow ends. • If approved, the user can fetch the resulting keystore. • If approved, the administrator calls the person referenced in the “contact info” to tell him/her the password for the keystore. The keystore is removed from the system when the task is complete. 14 Workflow2: Registrator requested server generated keystore A screenshot of the graphical representation of this workflow from the JBPM workflow editor is shown in illustration 3 on page 16. • A registrator starts a new process and enters the data that should go into the certificate. • The administrator approves, rejects or sends the request for correction. • If the request is sent for correction, a registrator corrects the request and sends it back for approval. • If the request is rejected, the registrators are notified with an email and the work flow ends. • If approved, the registrators get a new task to fetch the resulting keystore. • When the fetchtask is completed the keystore is removed from the database. Workflow3: Self registration with client generated keys A screenshot of the graphical representation of this workflow from the JBPM workflow editor is shown in illustration 5 on page 16. • A user browses to a page and enters a semisecret password. • The user registers the user's data and a private key is generated in the browser with its corresponding certificate signing request. The certificate signing request is added to the user's data. • The administrator approves or rejects the request with a comment. • If rejected, the user is informed by email that the request has been rejected and the workflow ends. • If approved, the user is informed by email where the finished certificate can be found. One of several passwords used to fetch the certificate is sent in the email. • The administrators get a new task to call, SMS or send the additional passwords by other means to the user. • The user logs on using all the passwords and fetches the certificate. Workflow4: Servletstarted certificate request flow A screenshot of the graphical representation of this workflow from the JBPM workflow editor is shown in illustration 4 on page 16. • A certificate signing request, notificationemail and contact info is sent to a Servlet that starts a new business process. • An administrator approves or rejects the request. 15 • An email is sent to the requester with either a link to the certificate or a rejection message. Illustration 2: Workflow1 Illustration 5: Workflow 3 Illustration 3: Workflow2 Illustration 4: Workflow 4 16 4.4 Outline of solution Since the workflows described earlier in this chapter require human interaction a web based tasklist application was created. The jBPM execution engine is used by the task list application to keep track of which task of the different running workflows that are assigned to which group or user (in this context a user is a client to the tasklist application and can have any role from the workflow perspective). A typical usecase would be: • The user is notified that a new task is waiting for someone with the user's role • The user logs in with a certificate or username/password depending on the security level required for the user's role. • The user is presented with a list of tasks assigned to the user's role and another list with personally assigned tasks. • The user can, if authorized, start, resume, cancel, change priority of, reserve or yield tasks. • The user can, if authorized, start a new workflow. When a task is started or resumed from the web based user interface, the user is sent to a Seam Pageflow and when the flow ends the user is sent back to the list of tasks. Workflows can also be started by users filling out and submitting a form or by submitting a certificate request to a Servlet. Illustration 6 on page 18 shows a screenshot of the finished tasklist application's web interface. Implementation details of the tasklist application are described in appendix A. 4.5 Conclusions The implementation of the tasklist application using jBPM for workflow management and Seam Pageflow for human tasks has shown the complexity in the framework. The finished tasklist application also revealed signs of concurrency issues in the underlying framework. The Pageflow implementation of the simple human tasks in the tested workflows were not worth the added complexity compared to using regular JavaServer Faces. 17 Illustration 6: Screenshot of the tasklist application using full debuginfo 18 5 Java framework comparison This chapter will give a theoretical comparison of the two Java frameworks Spring 2.0 and Enterprise JavaBeans 3.0. The two Java frameworks are described in detail in appendix D. The comparison will focus on how the frameworks can be used for EJBCA. 5.1 Basic concepts In the following chapters terms like POJO and JavaBean will be used. This is a quick definition and/or overview of what they mean in this context. Plain Old Java Object Plain Old Java Object (POJO) has no formal definition, but is usually used to describe a Java object that has no restrictions except for those enforced by the Java language. The term POJO is used here to point out that a Java object has no dependencies on the framework in the way that it is implemented. JavaBeans A JavaBean is a specific way to implement a Java object. The most important requirements on a JavaBean object is that it has to: • Have a public noargument constructor (or no constructor). • Use getters and setters to access private variables. • Implement java.io.Serializable. Using this object design a framework can easily instantiate, persist and manipulate the object. Details are available in the JavaBeans concept [39]. JavaServer Faces Managed Beans JavaServer Faces Managed Beans are Java objects used with the JavaServer Faces web framework. These objects have to implement: • A public noargument constructor (or no constructor). • Getters and setters to access private variables. Details are available in the JavaServer Faces reference [4]. Enterprise JavaBeans There are several different types of Enterprise JavaBeans. Entity Beans and Stateless Session Beans are used in EJBCA. The different types of Enterprise JavaBeans are described in Enterprise JavaBeans standard overview in appendix D. 19 5.2 Theoretical Spring framework evaluation Spring can be used in many different ways. For EJBCA there are two relevant use cases. If Spring is used as an addon library inside the application server or if all Enterprise JavaBeans are converted to simple JavaBeans and Spring is used as the container for transactions: • XDoclet can be removed. • Database abstraction would be simplified. • One kind of XML configuration would be replaced with another of similar extent. Spring's autowiring does not seem suitable for a project of EJBCA's magnitude and would make debugging much more difficult, since Spring only injects “null” instead of a value if a bean was misspelled or had it is name changed. The loose coupling is a very nice feature where resources and beans are injected into other beans. Even though the authors of Spring in Action [6] claim that this makes Spring applications more flexible since there is no dependencies on the framework, I know of no other solution that would handle the exact same JavaBeans exactly the same way. That way there still is a dependency on the framework. Also, most of the useful features like abstracting away all SQL exceptions introduce dependencies on the framework. XDoclet comments for transactions will be replaced with XML configuration. This will make it more difficult to get a good overview of the transactions and the code at the same time. 5.3 Theoretical Enterprise JavaBeans 3.0 evaluation Moving from XDoclet to Enterprise JavaBeans 3.0 looks very straightforward. All the XDoclet comments for Session Beans have Enterprise JavaBeans 3.0 annotation counterparts. The Local and Remote interfaces generated by XDoclet should be kept and converted to regular Java interfaces. Java Persistence API will allow the creation of write database agnostic persistence code. Due to the configuration by exception policy, minimal or no XML configuration will be needed. EJB 3.0 has similar features to Spring for injection of resources and beans into other beans. 20 5.4 Enterprise JavaBeans 3.0 is the best option Both frameworks bring several important features to the table, but Enterprise JavaBeans 3.0 does it better and is the only real candidate for further testing. A stable standard An EJBCA installation can live for 10 years or more, so to make sure it is maintainable EJBCA needs stability and standards more than the latest and greatest features. My impression of Spring is that it is a useful integration framework, compared with Enterprise JavaBeans 2.1, for building small loosely coupled applications from scratch. Good new ideas are quickly incorporated in the project, but this might be done at the price of backward compatibility. Enterprise JavaBeans 3.0 on the other hand is a proper Java Community Process standard [27] where the best ideas from Spring and similar frameworks are incorporated in a stable format. Configuration by exception Large amounts of XML configuration is difficult to overview and maintain. Spring would not be easy to maintain for such a big project as EJBCA. With Enterprise JavaBeans 3.0 minimal XML configuration is required and the same application could be used with many different application servers and databases without having to change the configuration to any great extent. Easy migration path Replacing XDoclet with Spring would require a large amount of code changes as where Enterprise JavaBeans 3.0 would require changes from comments to annotations with similar names. This similarity between XDoclet and Enterprise JavaBeans 3.0 will make the migration easier. 21 6 Enterprise JavaBeans 3.0 evaluation This chapter describes the evaluation of the Enterprise JavaBeans 3.0 framework on several different application servers and databases in brief. Details of this evaluation is available in appendix B. A reader that is not familiar with Java Enterprise Edition 5 should read appendix D or other literature on the subject to gain a full understanding of the evaluation. 6.1 Scope of evaluation and methodology From the theoretical study of Spring 2.0 and Enterprise JavaBeans (EJB) 3.0, the EJB 3.0 standard looks like a superior candidate for the next generation of EJBCA. To evaluate this technology a small Enterprise application was created. The goal further down the road was to give recommendations for the migration of EJBCA, so the components in the evaluation EAR should represent components in EJBCA while still being simple enough for easy construction and testing. The test application contains isolated and converted versions of some of EJBCA's Stateless Session Beans and an Entity Bean. The Entity Bean is used from Stateless Session Beans and the Stateless Session Beans are used from other Stateless Session Beans and Servlets and JavaServer Faces Managed Beans. 6.2 Java Persistence API EJBCA uses the large character object database type to store Java objects. All the currently supported databases are able to store objects with a character representation of up to 1 GiB. Automatic mapping of these objects using annotation metadata was only working with the Java Persistence API provider Hibernate. If this provider was not used, explicit mapping of large character objects has to be specified for each database type and Entity Bean. The automatic mapping is not a fully specified feature of Java Persistence API so this will lock in the solution to Hibernate. Simple Java types like integers were easy to convert to their Java Persistence API counterpart. Java Database Connectivity queries were also easily converted to helper methods with type safety. 22 6.3 Stateless Session Beans Each Stateless Session Bean has a common, a local and a remote interface. Some of the existing remote interfaces in EJBCA currently have nonserilizable method parameter objects. These methods can never have been used and was removed from the test application. Transaction metadata was applied to the implementing Stateless Session Bean. The remote interface of an Stateless Session Bean is accessed through Java Naming and Directory Interface (JNDI). Different application servers uses different naming schemes to use the Stateless Session Bean remotely. Additional metadata has to be used in the @Statelessannotation to be able to use the same look up pattern on different application servers. 6.4 JavaServer Faces 1.2 Injection of a Stateless Session Bean's local interface with the @EJBannotation in a JavaServer Faces Managed Bean was tested. The necessary libraries were available on all the application servers where the injection with JavaServer Faces 1.2 was working. 6.5 Test application structure The project layout of the deployed test application is very similar to how a deployed Enterprise Application is packaged. This will hopefully make it simpler for anyone who have not worked on this specific project before, but are familiar with Java Enterprise Edition packaging to navigate the project. 6.6 Web Services The preferred way to integrate with EJBCA is through the Web Service interface. In EJB 3.0, the server side Web Services can be backed by a Stateless Session Bean instead of Servlets. The Web Services Description Language (WSDL) file is generated automatically at runtime and will not change even though the implementation changes. The implementing Stateless Session Bean has to use the @WebServiceannotation with all the necessary metadata used for the WSDL generation. 6.7 Conclusion A summary of the EJB 3.0 support is shown in table 2 on page 24. Of the tested application servers, EJBCA can be expected to work in full with Geronimo 2.1.3, Glassfish v2 and JBoss 5.0.0.GA. 23 Application Server Enterprise JavaBeans 3.0 and JavaServer Faces 1.2 support Geronimo 2.1.3 full with proprietary configuration Glassfish v2 full JBoss 4.2.3.GA not supported JBoss 5.0.0.GA full JOnAS 5.1M2 work in progress OC4J 10.1.3.4.0 not supported WebLogic 10.3 Express works with proprietary configuration except remote EJB invocation WebSphere 7.0 Express certified, but not working Table 2: Summary of EJB 3.0 and JSF 1.2 support on different application servers 24 7 Final discussion In this chapter the tested workflow management systems are dismissed as insufficient for use with EJBCA. A Java framework migration strategy for EJBCA is presented together with some suggestions for future work. 7.1 The lack of executable workflow solutions The first half of this report has shown that there is no good open source workflow management system that can be used for implementing Public Key Infrastructure work flows with EJBCA at the time of evaluation. jBPM under Seam in a Web Application The problems observed during testing could depend on two things as I see it: • Technical issues due to the combination of Seam Pageflows and jBPM workflow in a Web Application. This might not have been properly tested before since I have not been able to find any explicit examples or documentation of this combination. • Lack of proper documentation, causing me to misinterpret or miss important usage or configuration. The resulting web application revealed signs of concurrency issues in the underlying framework and would therefore be useless in production. Since jBPM workflow execution engine is complex to use, it would take another Java developer quite some time before he or she becomes productive. This is hardly acceptable in an open source community where many different developers improve the code according to their requirements. Having a simplified graphical representation that gives an overview of a workflow was much easier to interpret than trying to read a textual description. However, this impression was a bit inaccurate, since the complexity of the underlying implementation took far more time than regular code to get a grip of. Since the resulting web application does not work, there is not much need for deeper analysis or speculation on how much one would gain from using jBPM and Seam. Pageflows All of the Pageflows could easily have been modeled easier using JavaServer Faces. It is difficult to justify the extra requirements in the form of dependencies on jBPM, Seam and the JBoss Tools package for editing Pageflows in the Eclipse IDE for the Pageflows used in the proof of concept application. 25 Conclusion I would definitely recommend looking closer into this field in a couple of years and hope for improvements in the frameworks, documentation or both. If such a survey is undertaken, I would also recommend looking into the possibility of implementing a highly customizable pure Javabased solutions that can handle different workflows as plugins. 7.2 EJBCA migration strategy This report has shown that Enterprise JavaBeans 3.0 is a good choice as the new Java framework for EJBCA, if the application server support is acceptable. EJBCA can, after a migration to Enterprise JavaBeans 3.0, be expected to work fully on Geronimo 2.1.3, Glassfish v2 and JBoss 5.0.0.GA. I believe that Glassfish v2 would be the most suitable application server to use during the migration since it is not as forgiving as JBoss and comes with an EAR verification tool that can detect standard violations. Since Sun's support for Java Standard Edition 5 ends 20091030 [38], the new version of EJBCA only has to support Java Standard Edition 6 and later. There are no design decisions that are affected by the upcoming Java Enterprise Edition 6 standard (described in appendix D) as far as I can see. It only confirms that there will be an upgrade path from Enterprise JavaBeans 3.0 to Enterprise JavaBeans 3.1 and that the standard is getting more portable between application servers and makes life easier for developers. A strategy to migrate EJBCA from Enterprise JavaBeans 2.0 to 3.0 was developed. Details of the migration strategy are described in appendix C. 7.3 Future work There are some issues that have come to my attention during this work and in discussions with others. Java Contexts and Dependency Injection It is probably a good idea to avoid introducing any new web frameworks until Java Contexts and Dependency Injection described in Java Specification Request 299 is investigated further. A study of this standard should be initiated as soon as the migration is finished. Future workflow management system evaluation Workflow management systems have some potential benefits and should be reevaluated in the future. 26 8 Abbreviations API Application programming interface BPEL Business Process Execution Language BPMN Business Process Management Notation CLOB Character Large Object EJB Enterprise JavaBeans EJBCA Enterprise JavaBeans Certificate Authority GNU GNU is Not Unix GPL GNU Public License HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment J2EE Java 2 Platform Enterprise Edition JAR Java Archive JAXRPC Java API for XMLbased Remote Procedure Call JAXWS Java API for XMLbased Web Service jBPM A product/project name. Java/JBoss (?) Business Process Modeling JDBC Java Database Connectivity JNDI Java Naming and Directory Interface JPDL jBPM Process Definition Language JTA Java Transaction API LDAP Lightweight Directory Access Protocol LGPL Lesser GNU Public License POJO Plain Old Java Object SOAP Simple Object Access Protocol SQL Structured Query Language UML 2.0 AD Unified Modeling Language 2.0 Activity Diagrams URL Uniform Resource Locator UTF Unicode Transformation Format WAR Web Application Archive 27 WSBPEL Web Service Business Process Execution Language WSDL Web Services Description Language XDPL XML Process Definition Language XML Extensible Markup Language 28 References [1] A.F. Vojdani, Tools for RealTime Business Integration and Collaboration, IEEE Transactions on power systems, vol. 18, no. 2, May 2003 [2] Bill Burke & Richard MonsonHaefel, Enterprise JavaBeans 3.0, 2006, O'Reilly, ISBN 9780596009786 [3] Budi Kurniawan, JavaServer Faces Programming, 2004, Tata Mcgraw Hill, ISBN 9780070586871 [4] Chris Schalk, Ed Burns, James Holmes, JavaServer Faces: The Complete Reference, 2007, McGrawHill, ISBN 9780072262407 [5] Christian Bauer and Gavin King, Java Persistence with Hibernate, 2007, Manning, ISBN 1932394885 [6] Craig Walls and Ryan Breidenbach, Spring in Action 2nd ed, 2007, Manning, ISBN 1933988134 [7] Debu Panda, Reza Rahman, Derek Lane, EJB 3 in Action, 2007, Manning, ISBN 1933988347 [8] Jim Farley, Practical JBoss Seam Projects, 2007, Apress, ISBN 9781590598634 [9] Joseph Faisal Nusairat, Beginning JBoss Seam, 2007, Dreamtech Press, ISBN 9788181286451 [10] IBM and SAP. WSBPEL Extension for People – BPEL4People, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws bpel4people/BPEL4People_white_paper.pdf, Visited 20091030 [11] Nada Kapidzic Cicovic, Extended Certificate Management System: Design and Protocols, Stockholm Univerity/Royal Institute of Technology, Department of Computer and System Sciences, 1997, http://daisy.dsv.su.se/fil/visa?id=26012, Visited 20100129, ISBN 9171536175 [12] Workflow Patterns Initiative. On the Suitability of BPMN for Business Process Modelling, http://www.workflowpatterns.com/documentation/documents/BPMNeval BPM06.pdf, Visited 20091030 [13] The Server Side. Java EE 6 Overview, http://www.theserverside.com/tt/articles/content/JavaEE6Overview/article.html, Visited 20090225 [14] The Server Side. New Features In EJB 3.1 part 1, http://www.theserverside.com/tt/ articles/content/NewFeaturesinEJB31/article.html, Visited 20090116 29 [15] The Server Side. New Features In EJB 3.1 part 2, http://www.theserverside.com/tt/ articles/content/NewFeaturesEJB31/article.html, Visited 20090116 [16] The Server Side. New Features In EJB 3.1 part 3, http://www.theserverside.com/tt/ articles/content/NewFeaturesEJB313/article.html, Visited 20090116 [17] The Server Side. New Features In EJB 3.1 part 4, http://www.theserverside.com/tt/ articles/content/NewFeaturesinEJB3Part4/article.html, Visited 20090116 [18] The Server Side. New Features In EJB 3.1 part 5, http://www.theserverside.com/tt/ articles/content/NewFeaturesinEJB31Part5/article.html, Visited 20090116 [19] Sun Microsystems. Using Generics with Java Persistence, https://blueprints.dev.java.net/bpcatalog/ee5/persistence/generics.html, Visited 200907 01 [20] Sun Microsystems. Naming Conventions for Java Persistence, https://blueprints.dev.java.net/bpcatalog/ee5/persistence/namingconventions.html, Visited 20090701 [21] Seth Ladd, Darren Davison, Steven Devijver, Colin Yates, Expert Spring MVC and Web Flow, 2006, Apress, ISBN 9781590595848 [22] Object Management Group. Process Modeling Notations and Workflow Patterns, http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf, Visited 20100129 [23] Internet Engineering Task Force. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://www.ietf.org/rfc/rfc3280.txt, Visited 20100114 [24] Internet Engineering Task Force. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://www.ietf.org/rfc/rfc3280.txt, Visited 20100114 [25] Internet Engineering Task Force. Privacy Enhancement for Internet Electronic Mail Part I: Message Encryption and Authentication Procedures, http://www.ietf.org/rfc/rfc1421.txt, Visited 20100129 [26] Internet Engineering Task Force. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, http://www.ietf.org/rfc/rfc2560.txt, Visited 20090817 [27] Java Community Process. JSR000220 Enterprise JavaBeans 3.0 (Final Release), http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html, Visited 20090817 [28] Object Management Group. Business Process Modeling Notation V1.1, http://www.omg.org/spec/BPMN/1.1/PDF, Visited 20100114 [29] Object Mangement Group. Unified Modeling Language 2.0: Superstructure specification, http://www.omg.org/spec/UML/2.0/Superstructure/PDF/, Visited 2010 0129 30 [30] Oracle. Getting started after installing Oracle Application Server, http://download.oracle.com/docs/cd/B25221_04/core.1013/b25209/getting.htm#i10252 13, Visited 20090625 [31] Oracle. OTN Forum: OC4J 11g tp replaced by 10.1.3.4, http://forums.oracle.com/forums/thread.jspa?messageID=2839467, Visited 20090625 [32] Oracle. OTN Forum: Toplink and MySQL problem with BLOB, http://forums.oracle.com/forums/thread.jspa?messageID=2453919, Visited 20090625 [33] Organization for the Advancement of Structured Information Standards. Web Services Business Process Execution Language Version 2.0, http://docs.oasisopen.org/ wsbpel/2.0/OS/wsbpelv2.0OS.pdf, Visited 20100129 [34] Red Hat Middleware. jBPM jPDL 3.2 User Guide, http://docs.jboss.com/jbpm/v3.2/userguide/pdf/jbpmjpdl.pdf, Visited 20100129 [35] Red Hat Middleware. JBPMBPELLicense, http://www.jboss.org/community/wiki/JBPMBPELLicense, Visited 20100129 [36] RSA Security Inc. RSA Laboratories' Frequently Asked Questions About Today's Cryptography, Version 4.1, http://www.rsasecurity.com/rsalabs/faq/files/rsalabs_faq41.pdf, Visited 20100129 [37] Sun Microsystems. Core J2EE Patterns Data Access Object, http://java.sun.com/ blueprints/corej2eepatterns/Patterns/DataAccessObject.html, Visited 20100114 [38] Sun Microsystems. Java SE & Java SE for Business Support Road Map, http://java.sun.com/products/archive/eol.policy.html, Visited 20090701 [39] Sun Microsystems. JavaBeans concept, http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html, Visited 200910 25 [40] Sun Microsystems. Project Conventions for Enterprise Applications Early Access 1, http://java.sun.com/blueprints/code/projectconventions.html, Visited 20090701 [41] The Server Side. Bonita v2 Series: Part One, http://www.theserverside.com/tt/articles/content/BonitaPart1/article.html, Visited 2009 0625 [42] The Server Side. The State Of Workflow, http://www.theserverside.com/tt/articles/content/Workflow/article.html, Visited 2009 0701 [43] XDoclet. XDoclet News, http://xdoclet.sourceforge.net/xdoclet/status.html, Visited 20090615 [44] Workflow Management Coalition. XPDL, http://www.wfmc.org/xpdl.html, Visited 20100114 [45] Workflow Management Coalition. XPDL Implementations, http://www.wfmc.org/xpdlimplementations.html, Visited 20090612 31 Appendix A: Tasklist application implementation details This section will describe some of the implementation details of the tasklist application for one of the implemented Public Key Infrastructure workflows to elaborate on problems with using jBPM and Seam's Pageflow for workflow management. This will also show some of the complexity with using the framework. Later in this section the different approaches to modeling human tasks with Pageflow is exemplified and compared with regular JavaServer Faces. Dependencies and Requirements This section describes dependencies to build and use the tasklist application. Server side components JBoss JPDL 3.3.0.GA: for workflow and Pageflow execution. EJBCA External Registration Authority client library 3.8.0 (with custom mod): For communication with the Certificate Authority. This is a modified version to support certificate requests in the Certificate Request Message Format. JBoss Seam 2.1.0.SP1: Framework used for injection, web and Pageflow and jBPM integration. Hibernate 3.0: Used for persistence. Apache Commons Configuration 1.5: For reading configuration files. Apache Log4J 1.2.7: For logging from static methods. BouncyCastle Security Provider 1.41b04: Crypto library. EJBCA Utils 3.8.0: Used by External Registration Authority Client Library EJBCA Online Certificate Status Protocol Client library 3.8.0: For checking validity of administrators certificates. A properly configured EJBCA installation with a running External Registration Authority Service. An additional JBoss application server running the web application in it is embedded Tomcat server. The build uses libraries from the JBoss installation but is portable to a simple Servlet container. 32 Client side components A browser with JavaScript enabled. Mozilla Firefox 3.x is required to be able to use Workflow3 (described on page 15), since client generation of asymmetric keys in browsers are vendor specific. It is not important for this evaluation how the certificate signing request is generated, since we only want to know how clientside generated keys affects the workflow compared with serverside generated keys. Support for additional browsers or a custom client could easily be added later. Structure and special files The tasklist application is packaged as web archive (WAR) web application called “extragui.war”. The used framework requires the following special files to exist: • extragui.war/WEBINF/pages.xml: Used for login and security declarations. • extragui.war/WEBINF/components.xml: Declaration of Java objects used in Expression Language tags and Pageflows. • extragui.war/WEBINF/pages.xml: Configuration of coupling between URLs and a Pageflows. Basic functionality The goal for the first version of the tasklist application was to create a simple tasklist and an implementation of Workflow2 (described on page 15). The tasklist is accessed by an administrator with a valid X509 certificate [24]. Mappings of roles to certificates are stored in a configuration file. By declaring a page as loginpage, Seam will run an Authenticator each time this page is accessed. Any page declared to require login will redirect the user to this page. Using <page view-id="/secure/*" login-required="true"/> <page view-id="/login.jsp" action="#{identity.login}"> <navigation> <rule if="#{!s:hasRole('public')}"> <redirect view-id="/secure/taskList.jsp"/> </rule> </navigation> </page> in extragui.war/WEBINF/pages.xml and <security:identity authenticate-method="#{authenticator.authenticate}"/> in extragui.war/WEBINF/components.xml will make sure that anyone accessing any page under /secure/ will be redirected to the login. At the login, a custom authenticator will validate the user's X509 certificate with the Online Certificate Status Protocol [26] and login the user with the correct roles. The user is then redirected to the tasklist if not 33 given the role 'public'. The user experiences that accessing the webapplication will instantly display the task list in the user's browser. Creation of new processes is done programmatically by manipulating an injected org.jboss.seam.bpm.BusinessProcess object, since the Seam annotation for this does not work for unknown reasons. Tasks are started or resumed by using the Seam org.jboss.seam.annotations.bpm.StartTask and BeginTask annotations. To enable a user to abort a business process in a single request (one click in the tasklist web user interface), annotations and code have to be combined: @StartTask @EndTask public void removeProcess() { ProcessInstance.instance().end(); } or @BeginTask @EndTask public void removeProcessWithStartedTask() { ProcessInstance.instance().end(); } Without using the annotations, the BusinessProcessContext will not be available and the ProcessInstance will be unaccessible. Reserving or yielding a task is done using the built in Seam methods assignToCurrentActor() and unassign(), from org.jboss.seam.bpm.PooledTask. Priority of tasks can be changed by directly manipulating the priorityfields of the tasks, that are exposed to the user as shown in illustration 6 on page 18. To simplify the implementation, the name of any human task is restricted to be the same as the name of the corresponding Pageflow. The first task of Workflow2 (described on page 15) would look like this in JDPL: <task-node name="registerEntity"> <task name="registerEntity" ... </task> ... </task-node> This task definition will, when executed, initialize the Pageflow registerEntity.jdpl.xml: <pageflow-definition ... name="registerEntity"> <start-page view-id="/secure/registerEntity.jsp" ... </start-page> ... </pageflow-definition> 34 Seam is made aware of the Pageflow by defining it in the Seam configuration file extragui.war/WEBINF/components.xml: <bpm:jbpm> <bpm:process-definitions> <value>process-definitions/enrollEntity/enrollEntity.jpdl.xml</value> ... </bpm:process-definitions> <bpm:pageflow-definitions> <value>pageflows/registerEntity.jpdl.xml</value> ... </bpm:pageflow-definitions> </bpm:jbpm> The Pageflow is coupled to a web page in the Seam configuration file extragui.war/WEBINF/pages.xml: <page view-id="/secure/registerEntity.jsp"> <begin-conversation join="true" pageflow="registerEntity" nested="false"/> </page> When a user clicks on a task in the tasklist the name of the task is used to resolve which page to send the user to. Since the name of the initial page of each Pageflow is set to “/secure/nameofthetask.jsp” Seam will be able to find the correct Pageflow to use from the extragui.war/WEBINF/pages.xml configuration file. Combining Seam Pageflow and jBPM There exists several different contexts that can store references to objects in the Seam framework such as the BusinessProcessContext, ApplicationContext, EventContext and ExecutionContext. There are three ways of accessing a process or task in the current Seam context. • Injection using the In annotation which requires the variable to be present in the current context of the Seam component: @org.jboss.seam.annotations.In private org.jbpm.taskmgmt.exe.TaskInstance taskInstance; This requires that org.jboss.seam.bpm.TaskInstance object is available for all uses of the Seam component where this injection is declared. This might be a problem if a component is used from different Seam contexts. • Using the Seam jBPM wrapper classes that return the org.jbpm.taskmgmt.exe.TaskInstance object in this org.jboss.seam.contexts.EventContext's org.jbpm.JbpmContext with the id of the task found in the current org.jboss.seam.contexts.ConversationContext: 35 org.jbpm.taskmgmt.exe.TaskInstance taskInstance = org.jboss.seam.bpm.TaskInstance.instance(); This requires that the wrapper classes in org.jboss.seam.bpm has been properly initialized, which is not always possible. • Programmatically using the org.jbpm.graph.exe.ProcessInstance from the ApplicationContext. All existing org.jbpm.taskmgmt.exe.TaskInstances can be accessed through processInstance.getTaskMgmtInstance().getTaskInstances(). Since this returns the list of all tasks, iteration over this list is required to find the task of interest. Direct usage of the jBPM context like JbpmConfiguration.getInstance().getCurrentJbpmContext() does not work, not even through the Seam wrapper component org.jboss.seam.bpm.ManagedJbpmContext. NonString Business Process Variables requires special attention. To increase compatibility between different databases each nonString Business Process Variable is broken down to a number of blocks of bytes called a org.jbpm.bytes.ByteArray that is easier to store. Unfortunately the reverse conversion is not done when a task is fetched back from persistence, so a workaround is needed to restore Business Process Variables before they are used in a task. This is especially problematic for human tasks using a Pageflow or mail tasks, where the first interaction with a variable is a getter expression. Instead of using Expression Language access of the form #{processVariableName} we have to resort to reinitializing the variables each time the task is started programmatically or using a helper method like #{helperComponent.processVariables['processVariableName'].value}. The helper method public Map<String, Object> getProcessVariables() would loop through all Business Process Variables, restore the original value for any nonString Business Process Variables and return a Map with references to the corrected Business Process Variables. Accessing the Business Process Variables can be just as complicated as accessing tasks or processes. There are several ways of accessing the same variables. As an example, an ActionHandler can be invoked during a transition between two states. Setting a value of a Business Process Variable in an ActionHandler can be done in the following ways: //Usable later in the process definition, from other tasks and actions: Contexts.getBusinessProcessContext().set(BPV_MESSAGEID, messageId); //Usable later from other actions (executionContext is Action-specific): executionContext.setVariable(BPV_MESSAGEID, messageId); //Usable later from other tasks: org.jbpm.taskmgmt.exe.TaskInstance taskInstance = TaskInstance.instance(); taskInstance.setVariable(BPV_MESSAGEID, messageId); //Usable later in the process definition and from other tasks: org.jbpm.graph.exe.ProcessInstance processInstance = ProcessInstance.instance(); processInstance.getContextInstance().setVariable(BPV_MESSAGEID, messageId); Only the first way, by using the BusinessProcessContext directly, works in the ActionHandler for accessing the variable later from all possible scenarios like 36 MailTasks, other ActionHandlers or Pageflow tasks. However, the other methods work in their limited context. As mentioned in the beginning of this section, a reference to a Process and Task can also be injected instead of using the instance()pattern. The scheduler service does not work properly when mixing Pageflow with regular jBPM workflow. An easy way to recreate this problem is to create a reminder for a task and then end the task from the Pageflow with <page name="showIncompleteTasks" view-id="/secure/taskList.jsp"> <end-task/> <redirect/> </page> This will prevent the scheduler's timer in the jBPM execution engine from being canceled properly. My theory is that the Pageflow hides the original JbpmContext (according to the source code, it looks like the creation of a new context pushes the old context on a stack), which makes the original scheduler service unavailable, but I have not been able to confirm this. It might be possible to work around this by ending the task in some other way. A similar problem occurs when a task is used with the property async="true". Without asynchronous operations the user ending the task has to wait for any automated node or decision between the current task and the next task. A typical use of this property is shown in illustration 7 on page 38. The task waitForResultDecision executes a loop that regularly polls the incoming message queue for a response from the Certificate Authority and uses the property async="true". Without asynchronous execution the user approving the action (ending approveEntitytask) would have to wait for the Certificate Authority to reply and the workflow to reach the next task (fetchResult) before the web browser returned to the tasklist. Unfortunately, the use of the property async="true" to end a task from a Pageflow causes an error about jBPM not to be able to locate the 'message' service used for asynchronous operations. By replacing the waitForResultDecision Decision with the waitForTimerEvent Task assigned to a new “system” actor, the problem with asynchronicity can be avoided. A special timer Servlet that runs in a Seam context was created and the Servlet executes all pending tasks assigned to the “system” actor at regular intervals. Illustration 8 on page 38 shows what the modified process looks like. The described workaround for asynchronous tasks revealed another problem. Simultaneous operations on a business process cause a wide range of different problems. For example, tasks might disappear or the entire process definition might disappear from Seam's contexts so no new workflow processes can be started. 37 Illustration 7: Screenshot of a workflow with an asynchronous waitdecision Illustration 8: Screenshot of a workflow with the asynchronous operation workaround The revealed problem was not related to the timer Servlet implementation, since manually starting two processes within a small timeinterval often leads to the exact same problems. Due to the spontaneous nature of these errors and since they have only been observed during concurrent operations, this leads me to believe that they are related to lack of synchronization in either Seam or jBPM, but the exact cause has not been proven. PageFlows Pageflows are used for human tasks in the workflow. The same functionality can some times be modeled in several different ways. The human task used to exemplify this is the “registerEntity” task. A Registration Authority registrator enters information about an entity (end user or server) in a web page. The administrator can switch between several templates that can be used for different type of entities. The entered information is later used in the workflow to create a certificate request. The Pageflow for registration of an entity can for example be modeled with Pageflow as shown in both illustration 10 and 9 on page 39 or implemented using standard JavaServer Faces. 38 Illustration 9: Screenshot of the Pageflow registerEntity Illustration 10: Screenshot of the Pageflow registerEntityAlternative In the version shown in illustration 9, the registrator is first presented with a web page to select template and then a second web page where the entity fields are filled in. Changing template sends the registrator back to the first page and a reset reloads the web page to fill out. Validation of the submit is not shown to the user unless it fails. In the version shown in illustration 10, the registrator is presented with a single web page where the required values for the default entity template can be entered or the template changed. A change of template reloads the web page with a different set of fields to fill out. A reset is the same as changing template to the default. Validation of the submission is not shown to the registrator unless it fails. Using JavaServer Faces, a “h:form” tag and “h:selectOneMenu” tag (drop down box) could be used to select the template. A second “h:form” and “h:dataTable” could be used to render the available fields to fill out. Custom validators could be used for input validation and displaying errormessages if the submit failed. I am not convinced that using Pageflow is motivated for such simple human tasks as the ones that are used in the different implemented workflows. I find regular JavaServer Faces less complex and it requires no extra tools than the Java Enterprise Edition development version of the Eclipse IDE and no extra libraries to deploy for any of the working application servers listed in section 7.2. 39 Appendix B: Enterprise JavaBeans 3.0 evaluation details This chapter describes the details of the Enterprise JavaBeans 3.0 framework evaluation. A reader that is not familiar with Java Enterprise Edition 5 should read appendix D or other literature on the subject to gain a full understanding of the evaluation. Scope of evaluation and methodology From the theoretical study of Spring 2.0 and Enterprise JavaBeans (EJB) 3.0, the EJB 3.0 standard looks like a superior candidate for the next generation of EJBCA. To evaluate this technology a small Enterprise Application (referred to as EAR or ejb3probe from now) was created. The goal further down the road was to give recommendations for the migration of EJBCA, so the components in the evaluation EAR should represent components in EJBCA while still being simple enough for easy construction and testing. Specification of the test application Suitable components to include in the first round of tests are: • An Entity Bean that should: • use Java Persistence API instead of EJB 2.1 ContainerManaged Persistence. • store a large object for portability testing of different databases. • A Stateless Session Bean for accessing the Entity Bean. • Another Stateless Session Bean providing a service. • A bundled Web Applications (referred to as WAR from now), containing: • a Servlet that can access a Stateless Session Bean locally in the Servlet initialization. • a Servlet that can access a Stateless Session Bean locally from a Servlet request. • a Servlet that can access a Stateless Session Bean remotely from a Servlet request. 40 • a simple web page for invoking the Servlets. One of the main points of testing this is also to see how Java Persistence API Entity Beans can be used as POJOs and how this will affect the existing code. Every Stateless Session Bean in EJBCA has more than one dependency on other Stateless Session Beans or Entity Beans, but one Stateless Session Bean stands out as an easy point of attack: LocalAuthenticationSessionBean The LocalAuthenticationSessionBean is a Stateless Session Bean with a local interface. This Stateless Session Bean references LogSessionBean, LocalUserAdminSessionBean and the Entity Bean UserDataBean. The Stateless Session Bean is very small with a total of only 267 lines of code including comments and imports. It is easy to create a simplified LogSessionBean implementation using a simple console logger. The 3 methods that are used in LocalUserAdminSessionBean can also be implemented in a simplified way by ignoring any authorization checks. The UserDataBean contains persistence mappings of ints, longs, searchable strings and a nonsearchable string. Outline of solution The test application will be built against a compiled version of EJBCA, so all nonJava Enterprise Edition classes that the application might depend on are present. These classes are also included as a library in the test application. Currently all Stateless Session Beans extend BaseSessionBean for marginally simpler logging and reference to a EJB 2.x ServiceLocatorpattern helper. It also stores the current session context. None of these services are required any longer so the BaseSessionBean will not be used. EJBCA does not use any Stateful Session Beans or Message Driven Beans. By minimizing the number of changes, it is easier to distinguish between required and optional migration work and avoid introducing new bugs. Piecebypiece conversion of Stateless Session Beans The LocalAuthenticationSessionBean is only named so for historic reasons and exposes both remote and local methods. It will be renamed AuthenticationSessionBean. Since it has both remotely and locally exposed methods, the following interfaces will be used: • AuthenticationSession is the interface for common methods. • AuthenticationSessionLocal extends AuthenticationSession and contains methods that are only exposed locally. The interface is annotated with @Local. 41 • AuthenticationSessionRemote extends AuthenticationSession and contains methods that are only exposed remotely. The interface is annotated with @Remote. The AuthenticationSessionBean is annotated with @TransactionAttribute(TransactionAttributeType. ...) on both the class and method level if required. For the other Stateless Session Beans we only need to expose a local interface since these beans are invoked locally from the AuthenticationSessionBean. To save effort, the interfaces are copied from the XDoclet generated EJB 2.1 interfaces in an EJBCA build and then modified. The Stateless Session Beans that AuthenticationSessionBean depends on must also be converted. To avoid conversion of every single Stateless Session Bean in EJBCA, simplified implementations are created for these dependencies. Entity Bean conversion UserDataVO is a value object used to represent the old UserDataBean in for example the graphical user interface. It would be nice to be able to replace this value object with the Entity Bean UserData that could be used for both persistence and as a value object. But since the UserDataVO object is used from many of the EJBCA classes referenced by the test application, a simple converter will be used instead so the referenced classes do not have to be changed for this simple test. UserData will however still be used in converted Stateless Session Beans. NamedQueries vs. Helper methods vs. Data Access Object Entity Beans can have something called Named Queries, which are predefined database queries. For our UserData Entity Bean they would look like this: @NamedQueries({ @NamedQuery(name="findBySubjectDNAndCAId", query="from UserData a WHERE a.subjectDN=:subjectDN AND a.caId=:caId"), @NamedQuery(name=... ... }) And used in the following way: Query query = entityManager.createNamedQuery("findBySubjectDNAndCAId"); query.setParameter("subjectDN", subjectDN); query.setParameter("caId", caId); UserData userData = (UserData) query.getSingleResult(); No parameter type validation is performed and it requires about 4 lines of code for a simple search. Another thing to take into consideration is that you have to know how the query is defined in order to be able to set the right parameters. Therefore it makes more sense to implement a helper method: 42 public static UserData findBySubjectDNAndCAId(EntityManager entityManager, String subjectDN, int caId) { Query query = entityManager.createQuery("from UserData a WHERE a.subjectDN=:subjectDN AND a.caId=:caId"); query.setParameter("subjectDN", subjectDN); query.setParameter("caId", caId); return (UserData) query.getSingleResult(); } The query is right next to the parameter names and it is obvious of what type the arguments should be (String and int) and proper JavaDoc can be added. The method could be used both from a Stateless Session Bean or a standalone application: UserData.findBySubjectDNAndCAId(entityManager, subjectDn, caId); The simplicity is striking and the query is still confined to the UserData class so all objectrelational mapping only exists in one place. The book EJB 3 in Action [7] suggests the use of an Entity Access Object pattern that is an updated version of the Data Access Object pattern [37] for the Java Persistence API. The goal of using Entity Access Object is to remove all dependencies from the business logic layer of an application on the persistence implementation. This is accomplished by adding a new persistence implementation object that is accessed through a new interface, where the interface has no dependency on the persistence framework. In my opinion, the added complexity of adding an additional object and interface for each Entity Bean to maybe be able to change persistence technology easier in the future does not motivate the use of this pattern right now. Storing large amounts of data in a single column All databases work a bit differently. Basic mapping of integers and other simple Java types to the databases native column types works well on all databases. However, for large binary objects and character columns the mappings differ more. EJBCA stores any large object or binary data as a string. This can be an XMLserialized object or base64 encoded binary data. In table 3 on page 44 the currently supported databases and their limits for large textcolumns are shown. 43 Database Data type name Size limit DB2 CLOB 2 GiB Derby CLOB 2 GiB – 1 byte Hypersonic VARCHAR N/A, has a 2 GiB table limit. Informix TEXT 2 GiB Mysql LONGTEXT 4 GiB MS SQL 2k TEXT 2 GiB – 1 byte Oracle 8i & 9i CLOB 4 GiB PostgreSQL TEXT 1 GiB SapDB LONG 2 GiB Sybase CLOB 4 GiB Table 3: Properties of large textcolumns on different databases According to the JavaDoc of @javax.persistence.Column, the lengthproperty can be specified on string valued columns. The idea here would be to try to specify a common length (1 GiB) that would work for all the databases above except the nonproduction database Hypersonic and let the Java Persistence API do the required mapping instead of specifying it manually. Knowing this limit is useful even without using the automated mapping, since no object should be allowed to grow larger than this. For EJBCA, 1 GiB of space can really be considered unlimited, since the largest objects stored in the database are Certificate Revocation Lists [23] with a size of about 30 MiB for 500 000 revoked certificates. Practical evaluation using JBoss Application Server 4.2.3.GA and 5.0.0.GA shows that the Hibernate Java Persistence API provider handles mapping when @Lob and @Column are combined without any problems. However, using Glassfish v2 and the TopLink Java Persistence API provider this fails. On the Derby database a @Lob annotated string maps to the column type “CLOB(64000)” that can hold 64 KB, which is much less than the required 30 MiB. According to a forum post [32] using the length parameter for large datatypes is not supported in TopLink as the practical tests has shown. This means we have to either use separate XML mapping corresponding to the annotation @Column(columnDefinition=”...”) or bundle Hibernate with the application. The drawback of bundling Hibernate is that we might not follow the correct interpretation of the standard and have a dependency on a specific provider. Mapping 44 each Entity Bean however requires a large amount of XML and we lose some of the simplicity of coding entity beans. A typical mapping file for Derby would look like this: <?xml version="1.0" encoding="UTF-8"?> <entity-mappings version="1.0" xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"> <entity class="org.ejbca.development.TestData" access="PROPERTY"> <table name="TestData"/> <attributes> <id name="id"> <column name="id" nullable="false"/> </id> <basic name="extendedInformationData"> <column name="extendedInformationData" column-definition="CLOB(1073741823)"/> <lob/> </basic> </attributes> </entity> </entity-mappings> The <entity>tag is repeated for every new class and columndefinitions have to be specified for each database type. Since most of the metadata is defined in the actual Entity Bean, it is only necessary to override the large types. A typical mapping file template would then look like this: <?xml version="1.0" encoding="UTF-8"?> <entity-mappings ...> ... <column name="extendedInformationData" column-definition="@database.lobcoldef@"/> ... </entity-mappings> The columndefinition can be injected during the build, based on the configured data base in a property file in the test application. So the databasetype has to be configured and we have to keep a mappingfile for all supported databases. Bundling Hibernate is as simple as adding 11 libraries to the EAR's “lib”directory and explicitly specifying the provider in the Java Persistence API configuration file: <?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" > 45 <persistence-unit name="ejbca" transaction-type="JTA"> <provider>org.hibernate.ejb.HibernatePersistence</provider> ... </persistence-unit> </persistence> With Hibernate the extendedInformationData column is created as a “CLOB(1073741823)” (that can hold 1 GiB – 1 byte) for Derby, without the application being explicitly configured for Derby and any need for explicit object relational mapping. Conclusion: The tradeoff is between configuring manual support for every supported database or using a not fully specified feature of Java Persistence API locking in the solution to the Hibernate framework. Deploying the test application In the first test iteration the goal was to deploy the Enterprise JavaBeans, try out EJB injection and see how Java Persistence API was handled by the different providers bundled with different application servers. Initial tests showed that the location of the Java Persistence API configuration file persistence.xml mattered. In the deployed test application persistence.xml was kept in ejb3probe.ear/lib/ejbprobeentity.jar/METAINF/persistence.xml. No SQL dialect was specified whenever Hibernate was used as the persistence provider. No ClassPath was specified in the EAR's METAINF configuration file. Glassfish v2 with Derby GlassFish v2 uses TopLink as Java Persistence API provider. This combination works flawlessly with both the bundled Hibernate provider or with the default TopLink provider together with explicit objectrelation mapping for large columns. JBoss Application Server 4.2.3.GA with MySQL EJB injection in Servlets does not work with JBoss Application Server 4.2.3.GA. JBoss Application Server 4.2.3.GA with MySQL seems to be unable to handle Java Persistence API properly. Since this application server is not Java Enterprise Edition 5 certified, no more effort was spent on trying to get this working. JBoss Application Server 5.0.0.GA with MySQL EJB injection in Servlets works for JBoss Application Server 5.0.0.GA and persistence with MySQL works flawlessly with the native Hibernate Java Persistence API provider and without using explicit objectrelational mapping. 46 JOnAS 5.1.0M2 with MySQL The final release of JOnAS 5.1.0 will be Java Enterprise Edition 5 certified. The tested version has a bit random and unpredictable behavior. EJB injection in Servlets works. The default Java Persistence API provider is Hibernate, so nothing special has to be done to deploy the testapplication and create the tables when it was tested with MySQL. The JOnAS application server is currently not officially supported by EJBCA. Oracle WebLogic Server 10.3 with Oracle 10 Oracle WebLogic Server 10.3 deploys the ejb3probe application, and complains about nonserializable method parameters on remote interfaces. This is a valid error and should be corrected in EJBCA. Weblogic 10.3 uses Oracle Kodo (based on the OpenJPA project) as Java Persistence API provider. Trying to use the persistence as for the previously tested application servers does not work very well, even with Kodo specific Java Persistence API configuration, manual precreation of the database table and explicit objectrelational mapping. Bundling the Hibernate Java Persistence API provider works, as long as <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WeblogicTransactionManagerLookup" /> is specified in the Java Persistence API configuration. Oracle OC4J 10.1.3.4.0 with Oracle 10 Even though OC4J 10.1.3.4.0 includes the necessary libraries to build an EJB 3.0 application, the test application could not locate the annotated Stateless Session Beans for EJB injection. According to the getting started guide [30] “Oracle Containers for J2EE (OC4J) is a complete Java 2 Enterprise Edition environment.” which means that it cannot be expected to work with EJB 3.0. According to Steve Button at Oracle the OC4J 11g release that would support Java Enterprise Edition 5 has been discontinued, since Oracle has acquired Weblogic from BEA [31]. WebSphere 7.0 Express with DB2 EJB injection does not work for WebSphere 7.0. The default Java Persistence API provider OpenJPA is not able to handle container managed transactions and requires explicit object relational mapping configuration for the proper creation of large columns. Bundling Hibernate gets rid of the transactionrelated errors, but does not create large object columns of the specified size as with other databases and application servers without explicit object relational mapping configuration. By successfully running the 47 test application on JBoss 5.0.0.GA with DB2 it is clear that the @Column annotation's attribute “length” is somehow filtered by WebSphere. After spending a long time reading documentation and searching for a solution to the problems mentioned above, I conclude that the Java Enterprise Edition 5 support in WebSphere 7.0 is incomplete, difficult to configure right or poorly documented. Websphere 7.0 will therefore be excluded from further testing. Apache Geronimo 2.1.3 with PostgreSQL Apache Geronimo 2.1.3 is Java Enterprise Edition 5 certified. Geronimo requires application server specific configuration in ejb3probe.ear/META INF/geronimoapplication.xml to make the configured DataSource available to the test application: <?xml version="1.0" encoding="UTF-8"?> <app:application xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2" xmlns:app="http://geronimo.apache.org/xml/ns/j2ee/application-2.0"> <dep:environment> <dep:dependencies> <dep:dependency> <dep:groupId>console.dbpool</dep:groupId> <dep:artifactId>EjbcaDS</dep:artifactId> <dep:version>1.0</dep:version> <dep:type>rar</dep:type> </dep:dependency> </dep:dependencies> </dep:environment> </app:application> EJB injection in Servlets works, but the default Java Persistece API provider OpenJPA is unable to create the required database tables in PostgreSQL. Bundling Hibernate as Java Persistence API provider currently requires a custom implementation for looking up the Geronimo Java Transaction API Transaction Manager. With the custom lookup, persistence works flawlessly and large objects were correctly mapped to “text”column type in the database. Test summary Table 4 lists the Java Persistence API support on the tested application servers. Bundling or using the native Hibernate implementation will allow the creation of complete database schemes using only annotation metadata without specifying the data base type in the application. All the server administrator would have to know is the name of the DataSource and where the application server resides on the file system. 48 Application server Native Java Comment Persistence API Geronimo 2.1.3 OpenJPA Works with bundled Hibernate and some extra configuration. Glassfish v2 TopLink Works with explicit objectrelational mapping or Hibernate. JBoss 4.2.3.GA Hibernate Works. JBoss 5.0.0.GA Hibernate Works. JOnAS 5.1M2 Hibernate Works. OC4J 10.1.3.4.0 TopLink To unstable to test. Discontinued application. WebLogic 10.3 Exp Kodo Works with bundled Hibernate. Call by value. WebSphere 7.0 Exp OpenJPA Works with bundled Hibernate and explicit object relational mapping. Table 4: Java Persistence API support on different application servers The platforms that work with the current layout are the following: JBoss 5.0.0.GA, JOnAS 5.1M2, Geronimo 2.1.3, Glassfish v2 and Weblogic 10.3. The only application specific configuration (except to bundle or use native Hibernate) is the declaration of the DataSource on Geronimo. Weblogic's proprietary callbyvalue configuration was ignored and Weblogic users can expect slightly worse performance than with the other application servers. Using JavaServer Faces 1.2 The goals for the tests described in this section are to add a JavaServer Faces presentation layer and: • Display a text and a value from JavaServer Faces Managed Bean through an injected EJB that performs a database fetch. • Invoke an action method on the JavaServer Faces Managed Bean through the Expression Language. • Verify if there is a need to bundle JavaServer Faces libraries. The JavaServer Faces Managed Bean must be declared in ejb3probe.ear/ejb3probe.war/ WEBINF/facesconfig.xml: 49 <managed-bean> <managed-bean-name>testManagedBean</managed-bean-name> <managed-bean-class>org.ejbca.development.TestManagedBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean> Working application servers JavaServer Faces Managed Bean invocation works flawlessly for Geronimo 2.1.3 with PostgreSQL, Glassfish v2 with Derby and JBoss 5.0.0.GA with MySQL for both lookup and EJB injection. There is no need to bundle JavaServer Faceslibraries. JOnAS 5.1.0M2 with MySQL The JOnAS 5.1.0M2 application server tries to access a local home interface during EJB injection. Since there are no such home interfaces in EJB 3.0 this fails. The conclusion is that it is noticeable that JOnAS is not yet Java Enterprise Edition 5 certified and no further effort was spent on this application server. WebLogic 10.3 with Oracle JavaServer Faces is not deployed by default on WebLogic, but the library to deploy it is bundled with the application server and can be deployed using the application server's web based user interface. To use this library from the test application, Weblogicspecific configuration is needed in ejb3probe.ear/ejb3probe.war/WEBINF/weblogic.xml: <?xml version="1.0" encoding="UTF-8"?> <weblogic-web-app> <library-ref> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2</implementation-version> <exact-match>false</exact-match> </library-ref> </weblogic-web-app> When this is added the application EJB injection works flawlessly. Test summary Table 5 shows the JavaServer Faces support on the tested application servers. 50 Application server JavaServer Faces support Geronimo 2.1.3 No need to bundle libraries. Can use EJB injection. Glassfish v2 No need to bundle libraries. Can use EJB injection. JBoss 4.2.3.GA Not tested. JBoss 5.0.0.GA No need to bundle libraries. Can use EJB injection. JOnAS 5.1M2 Incomplete support and/or documentation. OC4J 10.1.3.4.0 Not tested. WebLogic 10.3 Exp No need to bundle libraries. Can use EJB injection. Requires proprietary configuration. WebSphere 7.0 Exp Not tested. Table 5: JavaServer Faces support on different application servers Deployed test application structure The project layout of the deployed test application is very simple where the files for each module are clearly separated. This will hopefully make it simpler for anyone who have not worked on this specific project before, but are familiar with Java Enterprise Edition packaging. I have not been able to find any recommendations for Java Enterprise Edition 5 projects, like there are for Java 2 Platform Enterprise Edition projects [40]. It would also be really easy to extend the current project with additional buildscript targets that would build a subset of the modules or a tool that depended on some of the modules. The project structure is shown in illustration 11 and the packaging of the ejb3probe application is shown in illustration 12 on page 52. 51 Illustration 11: ejb3probe project structure Illustration 12: ejb3probe EAR structure 52 Adding Web Services So far we have only looked at the inner workings of the test application, but interfaces to the outside world is just as important for those that integrate with EJBCA. The preferred way to integrate with EJBCA is through the Web Service interface. Creating Web Services with standard Java annotations has been possible since Java Standard Edition 5.0 using the Java API for XML Web Services and the current EJBCA implementation relies on this feature backed by Servlets. In EJB 3.0, the server side Web Services can be backed by a Stateless Session Bean instead. The main benefit is that all the necessary XML files like the Web Services Description Language (WSDL) file is generated automatically at runtime. This makes configuring and making changes to the Web Services much easier. The code generation on the client side can be kept intact for those that rely on the current EJBCA Web Services client library. The tool com.sun.tools.ws.ant.WsGen that ships with the Java Development Kit and can be used for generation of the WSDL file from the @WebServiceannotated Stateless Session Bean. This generated WSDL file can then be used to generate client classes without requiring the Web Services to be deployed. The ejb3probe application was modified to use a mock implementation of the methods from the EJBCA Web Service interface. The interface was annotated with @WebService. @WebService public interface Ejb3ProbeWs { ... public abstract boolean isAuthorized(String resource) throws EjbcaException; ... } The implementing Stateless Session Bean is also annotated with Web Services properties: @Stateless @WebService(name="EjbcaWS", serviceName="EjbcaWSService", targetNamespace="http://ws.protocol.core.ejbca.org/", portName="EjbcaWSService") public class Ejb3ProbeWsSessionBean implements Ejb3ProbeWs { ... public abstract boolean isAuthorized(String resource) throws EjbcaException { ... } } If seamless migration is possible the old EJBCA Web Service client that is bundled with EJBCA should be able to access the new Web Services backed by a Stateless Session Bean. A small client application using generated classes based on the annotated Stateless Session Bean was created to make sure that generation was successful. 53 The Glassfish v2 EJB 3.0 validation tool found a potential issue where several of the Web Service methods throws java.rmi.RemoteException. This is not required and illegal in EJB 3.0 since the implementing Stateless Session Bean will use locally injected Stateless Session Beans. The changes in the Web Service interface by removing java.rmi.RemoteException has no effect on old clients. On Weblogic 10.3 the Stateless Session Bean name is ignored when the WSDL was created. The resulting default WSDL URLs for the tested application servers are shown in table 6. Application server WSDL URL JBoss 5.0.0.GA http://localhost:8080/ejb3probeejb3probe ejb/Ejb3ProbeWsSessionBean?wsdl Glassfish v2 http://localhost:8080/EjbcaWSService/EjbcaWS?wsdl Geronimo 2.1.3 http://localhost:8080/EjbcaWSService/EjbcaWS?wsdl WebLogic 10.3 Exp http://localhost:7001/Ejb3ProbeWsSessionBean/EjbcaWSService? WSDL Table 6: Test application's WSDL URL on different application servers Remote Enterprise JavaBean invocation An Enterprise JavaBeans can have a remote interface. Invocations of methods defined in the remote interface are invoked on a reference (a “stub”) that is looked up and downloaded from the application server. Method parameters are serialized and the invocation is sent over the Remote Method Invocation Internet InterOrb Protocol or another protocol supported by the application server. On the server the parameters are deserialized and the method of the implementing Stateless Session Bean is invoked. Looking up remote references Both the EJBCA command line interface and system tests use a EJB 2.1 ServiceLocator pattern to lookup references to remote objects. The lookup is performed using Java Naming and Directory Interface (JNDI). Access to the JNDI is application server specific and specified in a jndi.propertiesfile somewhere in the client's classpath. The JNDI names will be standardized in EJB 3.1, but in EJB 3.0 the names are still application server specific. LogMockSessionBean was chosen at random as a test subject for remote EJB invocation. 54 To see if there was an informal consensus or if explicit naming is required the default naming was investigated. JBoss, Glassfish and Geronimo generated proper objects in the JNDI when the test application was deployed. The JNDI names are shown in table 7. Weblogic crashes with a stack overflow exception when trying to view the JNDI content from the server's web based user interface. After implementing a custom JNDI content reader I was able to see that there was a stubbinding for the remote interface. This stub did however not implement the remote interface when it was used by the remote client. Application server Java Naming and Directory Interface name JBoss 5.0.0.GA ejb3probe/LogSessionMockBean/remote Geronimo 2.1.3 LogSessionMockBeanRemote Glassfish v2 org.ejbca.core.ejb.log.LogSessionRemote Table 7: Default Remote EJB JNDI name on different application servers As described in appendix D, EJB 3.1 will use the following JNDI naming convention: java:global[/<applicationname>]/<modulename>/<beanname>#<interfacename> It might be a good idea to introduce this naming convention right away. In this case the annotation @Stateless(mappedName=”ejb3probe/ejb3probe ejb/LogSessionMockBean#org.ejbca.core.ejb.log.LogSessionRemote”) would be a suitable choice for the LogMockSessionBean. When the test application was deployed, JBoss and Glassfish responded directly by changing their remote mappings, but Weblogic responded with several errors during deployment. Geronimo requires proprietary configuration in the file ejb3probe.ear/ejb3probeejb/METAINF/openejbjar.xml: <openejb-jar> <properties> openejb.jndiname.format = ejb3probe/ejb3probe-ejb/ {ejbClass.simpleName}#{interfaceClass} </properties> </openejb-jar> Using these mapping we can accomplish the EJB 3.1 style JNDI naming shown in table 8 on page 56. 55 Application server Java Naming and Directory Interface name JBoss 5.0.0.GA ejb3probe/ejb3probe ejb/LogSessionMockBean#org.ejbca.core.ejb.log.LogSessionRemote Geronimo 2.1.3 ejb3probe/ejb3probe ejb/LogSessionMockBean#org.ejbca.core.ejb.log.LogSessionRemote Glassfish v2 ejb3probe/ejb3probe ejb/LogSessionMockBean#org.ejbca.core.ejb.log.LogSessionRemote Table 8: Custom Remote EJB JNDI name on different application servers Even though this might seem unnecessarily complicated, the EJB 3.1 syntax is for a good reason. An application server should be able to deploy (different versions of) the same EJB in different EARs. In this case we know that there will only exist one deployment of each bean inside the EAR and it will either be the remote or local interface that is invoked through JNDI lookup. We even know that the Stateless Session Bean interface will only have one implementing Stateless Session Bean inside the application and the naming schema will guarantee that the interface's short classname is unique. Therefore a name like “ejb3probe/LogSessionRemote” would be sufficient to distinguish between different EJB stubs and still guarantee uniqueness on the server level. The client code for this JNDI lookup would be: LogSessionRemote logSession = (LogSessionRemote) context.lookup("ejb3probe/" + LogSessionRemote.class.getSimpleName()); The Stateless Session Bean annotation would be: @Stateless(mappedName="ejb3probe/LogSessionRemote") It would be even better if the prefix is taken from a common source for all Stateless Session Beans, if the application is ever renamed in the future: @Stateless(mappedName=(GlobalConstants.APP_JNDI_PREFIX + "LogSessionRemote")) Geronimo's proprietary configuration would change to: <openejb-jar> <properties> openejb.jndiname.format = ejb3probe/{interfaceClass.simpleName} </properties> </openejb-jar> With this approach we could use a general lookup pattern for all remote references: public static <T> T getRemoteSession(Class<T> remoteInterface) { String jndiName = GlobalConstants.APP_JNDI_PREFIX + remoteInterface.getSimpleName(); try { return (T) getContext().lookup(jndiName); } catch (ClassCastException e) { 56 log.error("JNDI object " + jndiName + " is not if type " + remoteInterface.getName()); } catch (NamingException e) { log.error("", e); } return null; } Serialization of Stateless Session Bean method parameters The most common nonserializable method parameter in EJBCA is probably java.util.Collection. It might be the case that these methods are never used in practice over the remote interfaces or it could be that some application servers are able to serialize a Collection if the objects contained in the Collection are serializable. A simple test that invokes a remote method with a Collection as parameter would show if this is handled automatically. A second test where a remote method with a regular nonserializable object as parameter would serve as a reference that such invocation will fail. Application server Serialization test result JBoss 5.0.0.GA Using Collections of serializable objects work. Simple nonserializeable object fails. Glassfish v2 Using Collections of serializable objects work. Simple nonserializeable object fails. Geronimo 2.1.3 Using Collections of serializable objects work. Simple nonserializeable object fails. Table 9: Serialization behavior on different application servers Implementing serialization of a Collection is not difficult, so it seems reasonable that this is supported in general. The results and reasoning implies that exposed methods that uses other nonserializable objects in one form or another is never used remotely and should be removed from the remote Stateless Session Bean interfaces of EJBCA. 57 Appendix C: Migration strategy details This chapter will outline a possible way to migrate EJBCA from Enterprise JavaBeans 2.0 to 3.0. The most important tasks based on the findings in this report will be described in more detail. Illustration 13 on page 59 shows a possible workflow for the migration. Darker boxes in the illustration require more work and the large area with darker background shows the tasks that have to be done during a feature freeze. Remove XDoclet XDoclet is the framework for automatic generation of Enterprise JavaBeans 2.1 interfaces and XML configuration files. These files should be generated one last time and then added to version control. Creating a new project layout As with the ejb3probeproject, new directories for Enterprise JavaBeans 3.0 interfaces, Entity Beans and Stateless Session Beans should be created. Each Web Application should also get its own directory. New Apache Ant build scripts will be created for building each module. Setting up automated tests The existing JUnit tests should be divided into two parts. One for testing helper objects and one for system tests that invoke remote Enterprise JavaBeans interfaces or other protocols. The helper object tests should run right away and the system tests should be modified as soon as the new remote interfaces are in place. The system tests will of course fail until the tested implementation is in place, but since we should not change the behavior of the application all the test should eventually succeed. Entity Beans Move each Entity Bean to its new folder and rename it to XxData, where “Xx” is taken from its current name. The Naming Conventions for Java Persistence [20] suggest using just Xx, but for historic reasons this would lead to naming collisions. Since Enterprise JavaBeans 3.0 entity beans can also be used as detached value objects, XxDataBean would not really make sense for all usecases. 58 Illustration 13: Migration overview 59 Annotate the former Entity Bean class, make sure it implements Serializable and Clonable and that it has a basic constructor: @Entity @Table(name="XxData") public class XxData implements Serializable, Cloneable { private static final long serialVersionUID = 1L; public XxData() {} Change abstract getters and setters public abstract String getXx(); public abstract void setXx(String xx); to normal getters and setters private String xx; public String getXx() { return xx; } public void setXx(String xx) { this.xx = xx; } for all values in values in the file. Also change XDoclet comments * @ejb.pk-field * @ejb.persistence column-name="xx" to annotations @Id @Column(name="xx") Getters that are not commented with * @ejb.interface-method should be annotated @Transient. The Enterprise JavaBeans 2.1 mandatory methods public PkClass ejbCreate(Xx xx, ...) throws CreateException { ... public void ejbPostCreate(Xx xx ...) { ... are replaced by a regular constructor public XxData(Xx xx) { ... For large objects commented with * @ejb.persistence jdbc-type="LONGVARCHAR" we need to use the Hibernate proprietary Java Persistence API implementation feature where we define the length of the column as @Column(name="yy", length=1024*1024*1024-1) @Lob where length should never be more than 1 GiB – 1 byte since this is the largest common value for the most common databases. Using this max is probably not desirable if the actual storage requirement is less than 1 GiB, so it would be better to set this on a case by case basis. Looking in the old mapping files under ejbca/src/deploy/ejb/merge/ in the EJBCA 3.9 branch source code repository will give a hint of the currently used sizes. Queries defined as comments should also be converted from 60 * @ejb.finder * description="findByXx" * signature="org.ejbca.xx.XxDataLocal findByXx(Xx xx)" * query="SELECT OBJECT(a) from XxDataBean a WHERE a.xx=?1" to public static XxData findByXx(EntityManager entityManager, Xx xx) { return (XxData) entityManager.createQuery("SELECT a from XxData a WHERE a.xx=:xx") .setParameter("xx", xx).getSingleResult(); } The “SELECT a” is mandatory in the Java Persistence API Query Language [5], but not in the Hibernate Query Language. It will still work without the “SELECT a” since we only rely on Hibernate as Java Persistence API provider, but it seems like a really bad practice to add additional dependencies on the framework. Queries that return more than one object should be converted from XDoclet comments like * @ejb.finder * description="findByYy" * signature="java.util.Collection findByYy(Yy yy)" * query="SELECT OBJECT(a) from YyDataBean a WHERE a.yy=?1" to public static List<YyData> findByYy(EntityManager entityManager, Yy yy) { return entityManager.createQuery("SELECT a from YyData a WHERE a.yy=:yy") .setParameter("yy", yy).getResultList(); } where the generics gives extra type safety [19]. Onetomany AdminGroupDataBean has a onetomany relationship with both AccessRulesDataBean and AdminEntityDataBean that requires special attention. Java Persistence API requires onetomany relationships that uses a foreign key (like AdminGroupDataBean does) to be bidirectional [7]. So AdminGroupData would have @OneToMany(mappedBy="AdminGroupData_adminEntities") public Collection<AdminEntityData> getAdminEntities() { return adminEntityDatas; } public void setAdminEntities(Collection<AdminEntityData> adminEntityDatas) { this.adminEntityDatas = adminEntityDatas; } @OneToMany(mappedBy="AdminGroupData_accessRules") public Collection<AccessRulesData> getAccessRules() { return accessRulesDatas; } public void setAccessRules(Collection<AccessRulesData> accessRulesDatas) { this.accessRulesDatas = accessRulesDatas; } 61 and both AccessRulesData and AdminEntityData would also have the required reference @ManyToOne(fetch=FetchType.LAZY) private AdminGroupData adminGroup; To avoid loading all access rules until they are used, lazy loading is used by default using the @OneToMany annotation. If AdminGroupData were ever to be used in a detached state we will not be able to use lazy loading this way. Removing a single AccessRuleData from an AdminGroupData using the onetomany association will (lazily) load the entire collection of access rules. It would be better to implement a custom Java Persistence API Query Language query to take care of this and to handle the borderline case where no access rules are left. Stateless Session Bean interfaces The old Stateless Session Bean source code should be used for creating the new local, remote and common interfaces. All the XDoclet comment tags in XxSessionBean should be converted to their Enterprise JavaBeans 3.0 counterpart. The XDoclet comments look like this: * @ejb.bean view-typ="both" * @ejb.interface-method view-type="both" The common interface is extended by both the remote and local interface. Methods with viewtype “both” should reside in the common interface, “remote” in the remote interface and “local” in the local interface. If the Stateless Session Bean name is for example XxSessionBean, the interfaces should be named XxSession, XxSessionLocal and XxSessionRemote. The local interface should be annotated with @Local and the remote interface with @Remote. All Collection, List and Set parameters should use Java generics. Methods that have object parameters that do not extend Serializable should not be a part of the remote interface even if they are declared that way today. Stateless Session Beans XDoclet comments on Stateless Session Beans should be transformed from * @ejb.bean type="Stateless" into the @Stateless class annotation. XDoclet comments like * @ejb.transaction type="Required" should be transformed into the @TransactionAttribute(TransactionAttributeType.REQUIRED) class annotation or simply nothing since REQUIRED is the default transaction attribute. Other transaction attributes have to be converted to their Enterprise JavaBean 3.0 counterpart. The Java Naming and Directory Interface name comment 62 * @ejb.bean ... * jndi-name="YySession" translates into @Stateless(mappedName=(GlobalConstants.APP_JNDI_PREFIX + "YySessionRemote")) where GlobalConstants.APP_JNDI_PREFIX is “ejbca/” and declared in the interface JAR file. Any other bean that is used from within the bean should be injected using @EJB private YySessionLocal yySession; instead of using any form of manual lookup. XDoclet method level comments like * @ejb.transaction type="Supports" also have to be transformed. This means that the same method in XxSessionBean should be annotated with @TransactionAttribute(TransactionAttributeType.SUPPORTS). If the Session Bean contains references to Entity Beans, additional development is required. Instead of working on the Enterprise JavaBeans 2.1 Entity Bean interface, Enterprise JavaBeans 3.0 uses the EntityManager, so Stateless Session Beans that use persistence have to inject this object: @PersistenceContext(unitName="ejbca") EntityManager entityManager; where “ejbca” is defined in ejbca.ear/ejbcaentity.jar/METAINF/persistence.xml. Since the fetched object stays managed as long as the transaction is running, it might sometimes be useful to covert it to a value object that is detached from the EntityManager. There is no way of detaching a single object, so cloning or using converters to existing value objects is recommended. Existing value objects should not be replaced with their Java Persistence API equivalents during the migration process, since it would require a large amounts of extra work and changes to the Stateless Session Bean interfaces. The EntityManager is also used to persist (create new) objects in the database and merge (replace) existing object with a detached one. Merge can always be used even if the entity does not already exist, but the developer has to be aware that it is only the returned object that is part of the persistence context. Remote Enterprise JavaBeans command line interface The EJBCA command line interface should be updated to use remote Enterprise JavaBeans 3.0 interfaces and lookup. The lookup pattern from the ejb3probe application can be reused here. 63 Web Services The EJBCA Web Services should be moved from it is current Servlet based implementation to a Stateless Session Bean based implementation. This process is described in depth in the ejb3probe Web Services iteration. Scheduling ServiceTimerSessionBean can still implement javax.ejb.TimedObject and use an ejbTimeoutmethod just as it currently does. It would however be more appropriate to use the Enterprise JavaBeans 3.0 standard for all parts of EJBCA. Instead of using the TimedObject interface, the ejbTimeoutmethod should be annotated with @Timeout. Java Database Connectivity replacement The Java Persistence API Query Language in Enterprise JavaBeans 3.0 can handle paging, JOINs, DISTINCT, LIKE, ORDER BY, GROUP BY, HAVING, subqueries, bulk UPDATEs and bulk DELETEs. This should be enough to replace most of the Java Database Connectivity code in EJBCA. For example the getLastExport method (21 rows) in ProtectedLogSessionBean: public ProtectedLogExportRow getLastExport() { ... con = JDBCUtil.getDBConnection(JNDINames.DATASOURCE); DESC"; String sql="SELECT * FROM ProtectedLogExportData ORDER BY exportEndTime ps = con.prepareStatement(sql); ps.setFetchSize(1); ps.setMaxRows(1); rs = ps.executeQuery(); if (rs.next()) { protectedLogExportRow = new ProtectedLogExportRow(rs); } ... } could be replaced by something like this (only 1 row): public ProtectedLogExportRowData getLastExport() { return ProtectedLogExportRowData.getLastExport(entityManager); } The getLastExport method in ProtectedLogExportRowData would then look like this (only 5 rows): public static ProtectedLogExportRowData getLastExport(EntityManager entityManager) { return (ProtectedLogExportRowData) entityManager.createQuery( "SELECT a FROM ProtectedLogExportData a ORDER BY a.exportEndTime DESC") .setMaxResult(1).getSingleResult(); 64 } I think it is best to decide the most suitable Java Database Connectivity transformation on a casebycase basis instead of giving general advice on this issue since Java Database Connectivity is used for custom database access and most use cases are different. However, it would still be good to use the pattern above with a static helper method on the Java Persistence API entity to keep all custom SQL in one place and make reuse easier. Graphical user interface There is a large amount of legacy JavaServer Pages code in EJBCA. Any Enterprise JavaBean references should be pushed to a JavaBean and converted to use Enterprise JavaBeans 3.0 injection. It might also make sense to convert the affected webpages to JavaServer Faces if major restructuring is required. Standalone Online Certificate Status Protocol responder build EJBCA can be built as a standalone Online Certificate Status Protocol responder with a Servlet entry point. This code should be updated to use Enterprise JavaBeans 3.0 injection. Java Persistence API in the External Registration Authority library The EJBCA subproject “External Registration Authority” currently uses pure Hibernate. Since the Java Persistence API class used for the database access is already available, switching to Java Persistence API should be simple. The benefit would be that we use a single database access technology for the entire EJBCA project. 65 Appendix D: Java frameworks This chapter describes the two evaluated frameworks Spring 2.0 and Enterprise JavaBeans 3.0 in detail. The main features of the upcoming Enterprise JavaBeans 3.1 standard are described in brief. Spring 2.0 Spring (short for Spring Framework) is an open source Java framework backed by VMware Inc. designed to ease development of enterprise applications. Spring 1.0 was released in 2004 and version 2.0 was released in 2006. This section is based on [6]. Architecture Spring was designed to simplify the development of enterprise applications that requires services like distributed computing, transactions and security. These services are already available with Enterprise JavaBeans 2.1, but are complicated to use and test. Spring uses a loose definition of conventional JavaBeans simply referred to as Beans. The entire framework is built on welldefined modules, on top of the core container module. Modules can be replaced by external modules from other frameworks or libraries if needed. Spring's lightweight core container module takes care of configuring, creating and managing Bean instances. The application context module makes Spring a framework by supplying services like Java Naming and Directory Interface access, Enterprise JavaBeans integration, remoting, scheduling and internationalization. Some available modules are the AspectOriented Programming module, Data Access Objects module, Objectrelational mapping integration module, Java Management Extension module, Java Enterprise Edition Connector API module, Spring Model ViewController framework, Spring Portlet ModelViewController, Spring Web module, Remoting module and Java Message Service module. The Spring distribution does not contain an executable like application servers do and is more like a library. Features This section describes the main features of Spring 2.0. 66 Dependency Injection Dependency Injection (also known as Inversion of Control) means that Beans are given their dependencies instead of having to look them up. Since the Bean only accesses an interface of the injected resource the actual implementation can be a local, remote or a dummy object. This loosely coupled architecture simplifies testing since each Bean can be tested in a fully controlled environment and typically has no Springdependent code. A dependency can be a Bean, a primitive value or a collection of the first two. AspectOriented Programming AspectOriented Programming allows application objects to concentrate on business logic. Services like transactions and logging can be applied as an aspect without the object being aware of it. The Aspect can be split into Advice (what to do and when to do it) and Pointcut (where to apply the Advice). All potential Pointcuts are called Joinpoints. Spring's proxybased builtin AspectOriented Programming module can be applied before, after and around methods. The Aspect is a plain POJO and the Pointcut methods are defined with regular expressions in Spring's XMLbased configuration. Bean Wiring and Creation A Spring application is created by configuring in XML how the container should inject dependencies into other Beans at runtime. This runtime linking is known as Bean Wiring and is performed at creation by the container's BeanFactory instance. Autowiring can be used to keep the configuration smaller and is especially useful when there are few object of the same type. The container then tries to match the different setters of an object with available Beans. Normally when multiple Beans are found an exception is thrown, but if no match is found “null” will be injected instead. Auto wiring might also make it more difficult to study and debug the coupling between Beans for both developers and tools. Scripts from Ruby, Groovy and BeanShell can be incorporated as any other Bean and the underlying script can be hotswapped or changed almost instantly. Persistence Spring encourages a model with a Data Access Object hidden behind an interface and accessed through a Service Object. By using templates for the desired persistence provider that is injected into the Data Access Object, only “execute in transaction” and “return data” callbacks have to be implemented. This mean that most of the underlying persistence layer is hidden and that a hierarchy of unchecked database exceptions can be used for better handling of data base errors. The DataSource for the persistence layer is either injected from a Java Naming and Directory Interface lookup when running inside an application server or configured 67 separately. To have a pooled DataSource in a nonapplication server environment, Jakarta Commons Database Connection Pools can be used. Java Database Connectivity Using Java Database Connectivity is greatly simplified by hiding all the code for managing connections, cleaning up resources and handling exceptions in parent classes. Hibernate Both version 2 and 3 of Hibernate are supported. Hibernate's mapping files or annotations can be used. The Hibernate specific code is minimized to using template specific methods for saving, loading or finding objects. An alternative is to use an injected Hibernate session. This removes dependence on Spring, but requires Hibernate specific errorhandling. Java Persistence API Java Persistence API is a POJObased persistence mechanism using annotations, based on ideas from both Hibernate and Java Data Objects. Spring templates takes care of managing the Java Persistence API EntityManager, transactions and exceptions. The EntityManager can be managed by the application or by the container in a Java Enterprise Edition environment. The actual choice is abstracted away by the template, but the choices are configured differently. iBATIS iBATIS is a objectquery mapping solution that allows more fine grained control than Hibernate and Java Persistence API. Objectrelation mapping and queries are specified with XMLformatted configuration and iBATIS can then be used through a template class. Transactions Transactions should be atomic (all or nothing), consistent (defined state after the transaction), isolated (the data involved is not affected by other processes during the transaction) and durable (all changes must be persisted before the transaction is complete). Spring's transaction manager delegates all transaction handling to the underlying persistence mechanism or to the used Java Transaction API implementation. When using Java Transaction API, mixing Java Database Connectivity and Java Persistence API might not always work. Both programmatic and declarative transactions can be used. A declarative transaction is a form of Aspect Oriented Programming that can handle propagation behavior (scope of transaction), isolation level (locking behavior), readonly hints (to optimize database access), timeout, and rollback rules (which exceptions triggers a rollback). 68 Cache Data Access Objects can be intercepted by a caching proxy. No such proxy is supplied with Spring, but several third party caching solutions are supported. Caching can be applied with annotations. Other Java Enterprise Edition features Java Naming and Directory Interface Wiring Any object in the Java Naming and Directory Interface can easily be wired into Beans. If the soughtafter object is not found, a default object can be wired instead. Mail service By configuring a MailSender with wiring or Java Naming and Directory Interface lookup, Beans can send email. The MailSender is based on the JavaMail API. Timer Service There are two kinds of timer services available. One is only able to run at intervals and another based on the Quartz project can be configured to run at specific times using the same kind of configuration as the cronutility. Security Spring Security is based on Aspect Oriented Programming proxies and injected Servlet filters. It can handle authentication and authorization for both web requests and Bean methods. When an invocation is intercepted by the Security Interceptor all or some of the Authentication Manager, Access Decision Manager, RunAs Manager and After Invocation Manager are invoked. The Authentication Manager verifies principals and credentials and can use several different authentication providers, including database/LDAP verification, Java Authentication and Authorization Service, web container verification, X509AuthenticationProvider and many more. The Access Decision Manager checks authorization to a resource by polling one or more objects for votes. The result depends on if the voting is Affirmative, ConsensusBased or UnanimousBased and if the allowIfAllAbstain property is set. An interface for implementing voters is available. The RunAs Manager applies a new role and AfterInvocation Manager checks authorization on returned data. Access control for Bean methods can be controlled by using wildcards in the Spring configuration or by using special metadata tags. For example all methods with a name starting with “get” can have different access control requirements than methods with a name starting with “set”. 69 Requesting secure web content requires several steps. First a session filter tries to identify the request to an existing session, then authentication filters processes the request, security related exceptions (if any) are translated by another set of filters. Finally the security interceptor filter processes the request by invoking the Authentication Manger and Access Decision Manager. A special taglib allows dynamic generation of page content depending on the security role of the requester. Remoting Five remote protocols are supported in Spring: Remote Method Invocation, Hessian, Burlap, Spring's HTTP Invoker and Java API for XMLbased Remote Procedure Call. A remote service is injected into other Beans as any local Bean and the remote service throws unchecked exceptions for problems related to the connection. Writing a Remote Method Invocation service is simplified to writing a simple interface and a POJO that are configured dynamically to be exposed. Hessian or Burlap are two lightweight HTTPbased protocols. These services are exposed with the help of regular Servlet mappings. Spring's HTTP Invoker works similar to Hessian or Burlap, but only between two Spring applications. Spring does not include a default implementation for contractlast Web Services, but can use the XFire package. This allows a Bean to be exposed as Web Services through a Servlet with some minor configuration (for each Bean to expose). The Java API for XML Web Services annotations can also be used with an additional XFire package and some more configuration. Consuming a contractlast Web Service is best done with the XFire client package that requires minimal configuration. Setting up contractfirst Web Services requires more configuration. First a contract is defined by typically converting a sample message into a Simple Object Access Protocol schema that is manually modified. When using HTTPbased Web Services a special Servlet can be configured to dispatch incoming Simple Object Access Protocol requests to a Web Service endpoint. The Web Services Description Language contract for the service can be automatically generated and supplied through the same Servlet as the service. On the clientside a templatepattern is used together with a marshaller to simplify the Web Service invocation as much as possible. Enterprise JavaBeans Integration Both Enterprise JavaBeans 2.x and Enterprise JavaBeans 3.0 Stateless Session Beans can be wired and injected into Spring Beans by using a special proxy object that looks up the correct reference from Java Naming and Directory Interface. This works just like remoting. Enterprise JavaBeans 2.x Beans can be Springenabled by extending a specific class. This allows lookup of Spring Beans through the Java Naming and Directory Interface. 70 Support for some of the Enterprise JavaBeans 3.0 annotations for injecting resources (from both Java Naming and Directory Interface and the Spring container) and using interceptors are available by using the Springfork addon project. Servlet filters Servlet filters are applied by using a proxy that chains the selected filters for each desired URLpattern. Besides filters for secure requests, there are filters that handles sessions. ModelViewControl In Spring's ModelViewControl (MVC) module each request is handled by a DispatcherServlet. The DispatcherServlet asks a HandlerMapping what controllers the request should use. The request is sent to each controller and a ModelandView object is returned. When all controllers have handled the request the DispatcherServlet asks a ViewResolver for a suitable View for the result and forwards the ModelandView object. The View generates the resulting data that is sent back to the client (for example using HTML). Requests can be mapped to Controllers in several different ways, including finding a controller with a name corresponding to the requested URL. There are several different types of basecontrollers to allow minimal parameter validation and binding in the business logic: View, Simple, Throwaway, MultiAction, Command, Form and Wizard. Declarative validation of requests can be performed using Commons Validator from Apache. The View that is used to render the response can either be an internal resource (JavaServer Pages or similar) or a Bean for more complex content. It also possible to render different responses based on the configuration for the user's locale. Spring has a JavaServer Pages taglib that allows incorrect forms to be repopulated with the entered data so the user does not have to start over from scratch. Both messages and errormessages can be externalized and internationalized. Spring supports a combination of JavaServer Pages and Tiles from the Apache Struts Framework, Apache Velocity and FreeMarker. Velocity, a less powerful and complex language than JavaServer Pages, can be extended by Spring to support internationalized messages. FreeMarker is more powerful then Velocity, but there is no real difference when they are both used together with Spring. Spring MVC can produce output in different formats. Excel content is produced with Apache Poor Obfuscation Implementation, Portable Document Format content with the iText library and Really Simple Syndicationflows with the Rome utility. Spring Web Flow Spring has a special type of controller to allow web applications to keep a conversational state and follow a defined page flow. Six different states exist: Action, Decision, End, Start, SubFlow and View. The page flow is defined in XML and can 71 invoke any Bean method as an Action and use any kind of ModelViewControl View to display information or receive submitted information in the Viewstate. Both Apache Struts and JavaServer Faces can be customized to use Spring Web Flow. Integration with other Web frameworks Integration with Struts 1.x is accomplished by delegating all requests to StrutsActions declared inside Spring application context as any other Bean. Struts 2.x is prepared for integration with Spring and only minimal configuration is required to declare Struts actions inside the Spring application context. Spring Beans can be injected and used by Tapesty 4 by using an integration module from the Diaphragmaproject. Integration of Spring with JavaServer Faces is accomplished by adding a Resolver that lets the JavaServer Faces pages resolve variables from the Spring application context. By using the Asynchronous JavaScript and XML library Direct Web Remoting, any Bean or Beanmethod can be exposed to be used from JavaScript in webclients. This allows highly dynamic content to be created. Java Management Extension Java Management Extension can be used to notify Java Management Extensionenabled listeners of events or changing properties at runtime by invoking exposed methods. The basic component in Java Management Extension is a special type of JavaBean called Managed Bean. Springs makes interactions with the Managed Bean easier by proxying them. Testing Spring can simplify testing in several ways: • Database tests can run inside a transaction that is rolled back after the test is done. • Values of returned ModelAndView objects can be validated. • Special application contexts for integration testing exists. EasyMock works well with Spring for creating mockobjects that can be injected during testing instead of the objects injected in the full application. Configuration Due to the immense amount of configuration required for an application, the author of [6] recommends splitting the XMLconfiguration into one file for each layer: Security, Web, Services and Persistence. 72 Enterprise JavaBeans 3.0 Enterprise JavaBeans is a standardized Java framework from the Java Community Process. Enterprise JavaBeans allows the creation of reusable components in a distributed environment where transactional integrity is ensured. Version 1.0 of the standard was announced in 1998, version 2.1 was released in 2003 and version 3.0 was released in 2006. This section is mainly based on [2]. Architecture Each Enterprise JavaBeans (EJB) class must have one or more of the following interfaces: ● A local interface: allows access from other EJBs in the same EJB Container. ● A remote interface: allows access from components outside the EJB Container. ● An endpoint interface: allows access to the EJB by the Java API for XMLbased Remote Procedure Call protocol. ● A Web Service interface: allows access to Stateless Session Beans by the Java API for XMLbased Web Services protocol. Interfaces can be generated at runtime by using annotations. This allows simpler code in scenarios with a single implementation. Methods that are invoked through a local interface use callbyreference (where a reference to the object is used as parameter) and methods using the other interfaces use callbyvalue (where a copy of the object is used as parameter). Enterprise JavaBeans Container The EJB Container provides services such as transaction, security, concurrency and run time naming for different EJBs. An EJB interacts with the container by registering methods it wants to have invoked during runtime. The registered method(s) will be invoked when a relevant event occurs. By using the model where all clients access interfaces, the real invocations can use container generated stubs. This enables transparent remote invocation and allows the container to apply security and transaction functionality to the invocation. EJBContext All Session Beans implement a subclass of the EJBContext interface. The methods of this interface provide some security functionality, transactional functionality and a Java Naming and Directory Interface wrapper for fetching resources. 73 Getting references to resources Java Naming and Directory Interface is the service used by EJBs to locate distributed objects or resources. Each Session Bean has it is own registry called Enterprise Naming Context. Enterprise Naming Context is implemented on top of Java Naming and Directory Interface with the URI “java:comp/env” and is populated from either annotations, XMLconfiguration or both. Examples of resources that can populate the Enterprise Naming Context are EJB interfaces, DataSources, EntityManagers, Timer Service and primitive values. These resources can be injected into a Session Bean by using annotations. Persistence Java Persistence API EJB 3.0 uses Entity Beans, representing data, that are POJOs. These Entity Beans do not require an application server and can be sent over a network. To make the Entity Beans interact with a database an EntityManager is used. The EntityManager can create, update, find, query and remove Entity Beans from the database. The objectrelational mapping is extensive and makes persistence more portable between different vendors. Every table and column can be defined by annotating the corresponding class, settermethod or variable. Java Persistence API supports all different relationship types between Entity Beans. Three types of Entity Inheritance are supported: single table per class, one table per concrete class and one table per subclass. A single table per class has the best performance and is easiest to implement. The Enterprise JavaBeans Query Language (also known as Java Persistence API Query Language) is used to do more advanced database queries than finding an Entity by its primary key. This query language is a limited and portable version of regular SQL, adapted to suit Java. Native SQL code can be used for nonportable tasks like running stored procedures. Entity Beans can have callback listeners to get notifications of object specific events, which can be used for logging database access. Persistence Context The persistence context is a set of Entity Beans managed by an EntityManager. As long as an Entity Bean is a part of a persistence context all changes are tracked and flushed to the database according to the current configuration. A transactionscoped persistence context lasts during a transaction and can only be used when the EntityManager is injected. Using an extended persistence context, the Entity Beans are managed even after a transaction has finished. 74 Transactions Transactions involving EJBs should be atomic (all or nothing), consistent (defined state after the transaction), isolated (the data involved is not affected by other processes during the transaction) and durable (all changes must be persisted before the transaction is complete). It is not recommended to use explicit transaction management, instead Declarative Transactions can be added with annotations or XMLconfiguration. All the EJBs involved in a transaction are together known as the Transaction Scope. Support for transactions can be modified for each beanmethod and is one of: • NotSupported: An active transaction will not be propagated. • Supports: An active transaction will be propagated. • Required: An active transaction will be propagated. A new transaction will be started if no transaction is available. • RequiresNew: A new transaction will always be started. • Mandatory: An active transaction will be propagated. If no transaction is active the method invocation will fail. • Never: If an transaction is active the method invocation will fail. The isolation level of transactions depends on configuration and the database implementation and is controlled in a vendor specific way. Transactions are rolled back by system exceptions and application exceptions where rollback behavior is specified. Other application exceptions allows the invoking business method to try to recover. Session Beans Session Beans contain business logic and are usually used for accessing data through Entity Beans. Stateful Session Beans Stateful Session Beans can be viewed as an extension of the client, performing tasks on behalf of the client and maintaining a conversational state. This also means that a Stateful Session Bean is dedicated to a specific client until the client times out or explicitly terminates the session. This type of bean is suitable for scenarios where each task depend on the result from previous invocations. To avoid clogging up to much resources during it is lifetime, a Stateful Session Bean can be passivated when the connection is idle. This means that the client keeps its connection, but the bean is temporarily evicted from memory. When another request arrives the bean is activated. Passivation and activation requires special care from the developer to avoid problems with special data types. 75 Stateless Session Beans Stateless Session Beans do not maintain a state and can for that reason be reassigned to different clients for every request or task. This also means that they are very efficient and do not require any activation or passivation. A drawback is that all input to methods must come from the method parameters or the environment. A Stateless Session Bean can never assume that a client will ever use the same Bean from the EJB server's pool during the following invocations. For that reason, it can only cache generic variables. Other Java Enterprise Edition features Timer Service The EJB Container provides a Timer Service API that allows a Stateless Session Bean to set a timer that results in a callback to a bean method when the time expires. Specific dates, intervals or a combination of these can be used. Interceptors Interceptors are objects that can be attached to lifecycle events of EJBs. This is usually common code that should not be mixed with the business logic. Examples of interceptors are time profiling code, debug code or security. Interceptors can be applied with both annotations or XMLconfiguration. Security The available security functions are authentication and authorization for Session Beans. How authentication is performed is however not a part of the standard. Some vendors use a system based on passing credentials through Java Naming and Directory Interface, others use Java Authentication and Authorization Service. Securing connections using cryptography is vendor specific. Authorization is rolebased and can be applied with both annotations and XML configuration. By using the RunAs annotation the invokers role can be overridden. There are also some limited functionality for programmatic security. The mapping between users and roles are set during deployment. Web Services Web Services in EJB 3.0 are based on a combination of XML, Simple Object Access Protocol (SOAP) 1.1 and Web Services Description Language (WSDL) 1.1, called Basic Profile 1.1 from Web Service Integration Organization. SOAP is a network agnostic, distributed object protocol defined by an XML Schema. EJB 3.0 supports SOAP over HTTP 1.1. WSDL is a programming language, platform and protocol agnostic XMLdocument that describes Web Services. EJB 3.0 uses WSDL for SOAP 1.1 and 1.2. 76 The Web Service implementation used in EJB 3.0 is Java API for XMLbased Web Services (JAXWS) 2.0. JAXWS is designed for simplicity and a Stateless Session Bean can be exposed as a Web Service and fully configured using annotations. It is also possible to expose a special Web Service interface that is implemented by a Stateless Session Bean. Servlets Servlets are serverside components used for generating responses to web requests. A Servlet is similar to a Stateless Session Bean in the way that resources can be accessed including injection, but it cannot contain business methods or use container managed transactions. JavaServer Pages JavaServer Pages is a language for dynamically generating web pages, by allowing embedded server parsed Java code in HTMLpages. JavaServer Pages pages are compiled at runtime and run as Servlets [4]. JavaServer Faces JavaServer Faces is a Java framework built on top of JavaServer Pages and Servlets [4]. A ModelViewControl model enforces use of framework components, so no business code is embedded in pure JavaServer Faces pages. JavaServer Faces comes with many standard user interface components, such as input fields, that can easily be added using taglibraries. These user interface components can interact with Managed Beans using the Expression Language. Validators can be added to user interface components for validating input. Using JavaServer Faces' output components makes it easier to avoid crosssitescripting attacks than with pure JavaServer Pages since script tags are escaped by default and will not be processed by the client's web browser. There is also a plethora of thirdparty plugin tag libraries with support for Asynchronous JavaScript And XML, output encoding and additional user interface components. Packaging The Java ARchive (JAR) file format is used to package Java classes and associated metadata. Web components are packaged with a deployment descriptor and libraries as a Web application ARchive (WAR or .war) file. WARs can be packaged together with EJB JARs and an optional deployment descriptor into a Enterprise ARchive (EAR or .ear) file called a Java Enterprise Edition Application. Special attention has to be paid to the directory structure of the included components. Both WAR and EARfiles are themselves in the JAR file format. 77 Configuration EJB 3.0 supports the concept of “configuration by exception” and the default values are chosen to minimize the need for any configuration. To minimize the need for XML configuration files, most configuration can be applied as annotations directly on the class, method or variable. The annotations can be used as the default configuration and still be overridden by XMLconfiguration files in specific deployment scenarios. Enterprise JavaBeans 3.1 and Java Enterprise Edition 6 This summary is based on the ongoing standardization work for Java Enterprise Edition 6 and Enterprise JavaBeans 3.1 presented in 6 articles ([14], [15], [16], [17], [18], [13]) by Reza Rahman on theserverside.com. Rahman is a member of the Java Community Process Java Specification Requests 318 expert group. Optional interfaces for Enterprise JavaBeans Session Beans no longer need interfaces. This is accomplished by directly annotation the Session Bean with @Stateless or @Stateful. Singleton Beans The Singleton Bean is a middleware version of the Singleton pattern. Its primary use is to store applicationwide shared data, like for instance a database cache. Annotating a Plain Old Java Object with @Singleton makes it a Singleton Bean. By using @ConcurrencyAttribute(READ_LOCK) on methods we can allow concurrent reads. The specification will not include clustered Singleton Beans. Time Service with scheduling Using the @Schedule(second=.., minute=.., hour=.., dayofmonth=.., month=..., year=...) annotation on a method, we can determine when to execute the method. There might also be support for a more compact expression like @Schedule(expression=”0 0 0 1 * * *”). New methods will also be added to the TimerService interface to allow programmatic setting of timers and when in the future the first execution should occur. Asynchronous invocation of Session Beans Instead of using Message Driven Beans, a simple @Asynchronous annotation on a method will make the invocation asynchronous. The return type java.util.concurrent.Future<V> (and javax.ejb.AsyncResult<V>) will be supported, so it is possible to check for completion, exceptions and return values. Enterprise JavaBeans Lite One of the Java Enterprise Edition 6 profiles is Enterprise JavaBeans Lite. This profile will support synchronous Stateless, Stateful and Singleton Session Beans using local or 78 no interface. It will also support interceptors, declarative security and both declarative and programmatic transactions. Enterprise JavaBeans classes could be added directly to the WEBINF/classes directory of a WAR file. It is expected that Servlet containers like Tomcat and Jetty will implement the EJB Lite profile. Java Contexts and Dependency Injection The Java Specification Requests 299 for Java Contexts and Dependency Injection was inspired by JBoss Seam and Google Guice frameworks. By annotation a Plain Old Java Object with @Component it is registered with the container as a bean. @Named(“beanName”) assigns a name to the component that the container can reference this bean by. The bean can then be referenced from JavaServer Pages or JavaServer Faces using Expression Language expressions. The @In annotation can be used for injecting other components in the current context. A Entity Bean can for example be annotated as a component and injected to the Session Bean so it can be persisted. This type of injection can also be used for any other Plain Old Java Object, allowing even looser coupling between objects. Standardized global Java Naming and Directory Interface names The name under which Enterprise JavaBeans are registered in Java Naming and Directory Interface will be standardized. The standardization will benefit components that cannot use dependency injection. The format is java:global[/<applicationname>]/<modulename>/<beanname>#<interfacename> where the applicationname is not used if the Enterprise JavaBean is deployed in a simple web application. The interfacename can be omitted if there only exists a single interface or no interface. Enterprise JavaBeans Embeddable Container An embeddable container will allow unittesting, batch processing and similar tasks utilizing Enterprise JavaBeans Lite services in a Java Standard Edition environment. Removal of dead meat Java API for XMLbased Remote Procedure Call, Enterprise JavaBeans 2.x Entity Beans, Java API for XML Registries, Java Service Request 88 for Java Enterprise Edition Application Deployment and the Java Service Request 77 for Java Enterprise Edition Management features will all be dropped in Java Enterprise Edition 6. Java Persistence API 2.0 The ability to model Collections, Lists and Maps as well as Unidirectional onetomany relationships are introduced in Java Persistence API 2.0. Queries can be used to fetch the first or a limited number of results. More advanced dynamic queries can be used. Pessimistic locking, standardizing Java Database Connectivity properties and configurable time outs are other new features. 79 Servlet 3.0 In the Servlet 3.0 specification, annotations like @WebServlet, @ServletFilter and @WebServletContextListener are introduced to reduce configuration in the web.xml file. Fragments of web.xml can be included in libraries to perform for example boot strapping. In the previous Servlet versions, frameworks such as JavaServer Faces required manual configuration in the web.xml file. Java API for RESTful Web Services 1.1 Java API for RESTful Web Services 1.1 aims at reducing Representational State Transfer (REST) programming to the annotation of Plain Old Java Objects. The library includes integration with Servlets, Weld and Enterprise JavaBeans. 80 TRITA-CSC-E 2010:047 ISRN-KTH/CSC/E--10/047--SE ISSN-1653-5715 www.kth.se

A workflow based architecture for Public Key Infrastructure

Related documents

Products

Support

A workflow based architecture for Public Key Infrastructure

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib