Title: Integrating The Enterprise With J2EE, Patterns And RUP By Jacques Dubuisson This paper propose to demonstrate the fundamental concepts relating to EAI within the architecture of Java 2 Platform, Enterprise Edition (J2EE) which offers technologies that enable the development of large and scalable applications in a layer of abstraction that can be applied on top of an enterprise system; promoting a standards-based approach to development and promotes the creation of multi-tier applications, in which developers can break down the mammoth undertaking of enterprise-scale integration into specific, self-contained, tasks. This paper provide a comprehensive study of the choices and strategies available using the design principles and patterns associated with the J2EE architecture and RUP.

Introduction Common Problem I know the data is there, but I can't get the information I need. The data is in the computers, but cannot be located readily or it is not in a format that is suitable for use by the users. Inability to instantly access vital information that may be stored in a variety of different information systems which may influence the success of a company. . The presence of an effective information infrastructure that avoids the need for employees to perform numerous manual tasks like filling in paper forms, switching between different applications to get their work done, re-entering the same data more than once in different applications, or waiting for data to be processed and other bureaucracy, is of utmost importance. A well-integrated system should offer instant access to information, no matter which part of the system is used, thus by definition, an information system is only as effective as the integration between the different applications [11].

Introduction Solution: EAI - Enterprise Application Integration The unrestricted sharing of data and business processes among the connected applications and data sources in an enterprise. EAI is basically a new name for the integration processes that computer scientist have been working on for years. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding or migrating to a new set of applications that exploit the Internet, e-commerce, extranet, and other new technologies. EAI involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new view, and then devising ways to efficiently reuse what already exists while adding new applications and data. Any reasonably large company will have many applications probably written using many different technologies which is a common occurrence from mergers, acquisitions of businesses and/or as a company grows. It is vital to tie these existing systems together since the cost of maintaining many disparate systems is large, and the benefits of doing so will surely diminish over time.

Introduction Integration is organized into four parts: Integration through data Business method integration (otherwise known as application-to-application integration), Presentation integration Business-to-business (B2B) integration. Each of these sections will be discuss for the strategies, methods and patterns available, and then focus on the technologies used to implement the integration. I will cover the following: Integration through data; JDBC, JDO, and other ways to access data. Using XML for data exchange (JAXP). Message brokers (JMS). Business method integration; RMI-IIOP and Java IDL for CORBA integration. Using EJBs for integration. The J2EE Connector Architecture (JCA). COM bridges for Windows integration. Transaction (JTA) and security (JAAS) management Presentation integration; Servlets, JSF and JSP pages for client integration B2B integration; XML technologies and vocabularies. XML/XSLT for building user interfaces. SOAP, UDDI, and WSDL. E-Marketplaces and portals

Integration Infrastructure And Architecture Consists of a set of middleware technologies that provide the interoperability services necessary to establish communication between applications and provides the foundation to define the integration architecture. Integration Architecture Lies on top of the integration infrastructure to specify the overall structure, logical components and logical relationships between all the different applications. When the integration infrastructure provides these services it frees the developers from these tasks and they can focus on the actual integration itself.

Integration Infrastructure And Architecture Middleware Technologies: Database access technologies Message-oriented middleware Remote procedure calls Transaction processing monitors Object request brokers Application servers Several hybrid and proprietary products Effective integration infrastructure should address all relevant middleware services that are required by EAI.

Integration Infrastructure And Architecture Database Access Technologies The technologies differ in the form of the database interfaces with most well known are: Open Database Connectivity (ODBC) JDBC and Java Data Objects (JDO) in the Java platform Active Data Objects (ADO) in the Microsoft platform. Database access technologies provide access to the database through an abstraction layer, which enables us to change the actual DBMS without having to modify the application source code. In other words, it enables us to use the same or similar code to access different database sources.

Integration Infrastructure And Architecture Message Oriented Middleware Message oriented middleware is a client/server infrastructure that increases interoperability, flexibility and portability of applications. It enables communication between applications over distributed and heterogeneous platforms, and reduces complexity because it hides the communication details and the details of platforms and protocols involved; the functionality of MOM is accessed via APIs. The applications can therefore exchange data without needing to understand the details of the other applications, architectures and platforms involved.

Integration Infrastructure And Architecture Remote Procedure Calls Remote procedure calls are also a client/server infrastructure intended to enhance interoperability between applications over heterogeneous platforms. Similar to MOM, it enables communication between software on different platforms and hides almost all of the details of communication. RPC is based in procedural concepts — developers use remote procedure or function calls. First implementations date back to the early 1980s. The main difference between MOM and RPC is the manner of communication. While MOM supports asynchronous communication, RPC promotes synchronous, request-reply communication (sometimes referred to as "call/wait"), which blocks the client until the server fulfils its requests. The next figure shows two applications communicating using RPC. To achieve remote communication, the applications use procedure calls. RPC middleware hides all of the communication details, which makes using remote procedure calls appear very similar to local procedure calls:

Integration Infrastructure And Architecture Transaction Processing Monitors Transaction processing (TP) monitors are important middleware technology in mission-critical applications. They represent the first generation of application servers. TP monitors are based on the concept of transactions; they monitor and coordinate transactions among different resources. Although the name suggests that this is their only task, they have at least two other very important additional roles: Performance management Security services

Integration Infrastructure And Architecture Object Request Brokers Three major standards of ORBs: OMG CORBA ORB compliant Java RMI and RMI-IIOP Microsoft COM/DCOM/COM+ Object request brokers (ORBs) are a middleware technology that manage and support the communication between distributed objects or components. ORBs enable seamless interoperability between distributed objects and components without the need to worry about the details of communication. The implementation details of the ORB are not visible to the components. ORBs provide location transparency, programming language transparency, protocol and operating system transparency. The communication between distributed objects and components is based upon interfaces, and is usually synchronous, although it can also be deferred synchronous communication or asynchronous communication. ORBs are often used with component location services. ORBs are complex products but they manage to hide almost all of the complexity. More specifically, they provide the illusion of locality — they make all of the components appear to be local, while in reality they may be deployed anywhere in the network. This simplifies the development considerably but can have negative influence on performance.

Integration Infrastructure And Architecture Application Servers Handle interactions between client tier and the data persistence tier. Provide middleware services, Container management environment for business logic components. Support for ORBs, MOM, transaction management, security, load balancing and resource management. Most important aspects of a platform: Technical aspects, Openness, Interoperability, Cost, Maturity Application servers provide a comprehensive solution to enterprise information needs. They are also an excellent platform for integration. Today, vendors often position their application servers as integration engines, or specialize their common purpose application servers by adding additional functionality (such as connections to back-end and legacy systems) so that they can position their products as integration servers. Although such servers can make the configuration of different middleware products relatively easy, it is still worth bearing in mind what is beneath the surface.

Integration Infrastructure And Architecture Most important aspects of a platform: Application servers should support a standardized, open and generally accepted platform. Technical aspects Openness Interoperability Cost Maturity Technical Aspects software technologies and the architecture of the applications developed. It also includes interoperability, scalability, portability, availability, reliability, security, client contracts, the ability to grow and accommodate new solutions, and so on. Openness enables vendors and third party companies to influence the development of a particular software platform. Interoperability among platform implementations is crucial for the adoption of a particular platform. Cost the application server and other development software, the cost of hardware, the training, and the cost of the maintenance of the applications throughout their life-cycle. Maturity The more mature the platform is, the more it has been tested in a real-world environment, proving that it is suitable for large-scale applications.

Integration Infrastructure And Architecture The horizontal layer services: Communication Brokering and routing Business intelligence The vertical layers services: Transactions Security Lifecycle Naming Scalability Management Rules Horizontal Services Communication provide the abstraction for communication details. It provides the transparency for accessing different remote system and unifies the view of them. This ensures that developers do not have to deal with low-level communication details. Brokering and Routing takes care of implementing the technical side of integration. No matter what type of integration we use, this layer should adapt the communication between applications in such way that all participating applications will be able to interoperate. Brokering and routing are essential for integration and actually have a number of responsibilities. Business Intelligence is responsible for presenting a high-level interface that allows access to business information for other applications and to the users. This layer presents data to users in an understandable form. With the growth of e-commerce the business intelligence layer also takes some responsibilities for B2B integration.

Integration Infrastructure And Architecture The relations between the services are shown on the figure: Vertical Services Transactions provide the means for carrying out the business operations in a transactional manner. means that any operation performed on one or more application that causes a state change, or changes to permanent data, has to be performed as an atomic operation that guarantees that the consistency of the system is preserved. Security constrain access to the system and include all three horizontal layers. Lifecycle control the lifecycle of all applications involved. enable existing applications to be replaced one by one, without influencing the other applications in the integrated system. Naming allow for the implementation of location transparency and will enable the replacement of one resource with another if this is required. Scalability, Management, Rules

Integration Infrastructure And Architecture Infrastructure services can be realized by different middleware technologies. Java 2 Platform, Enterprise Edition (J2EE) CORBA Microsoft .NET J2EE and CORBA both have associated specifications, and different vendors offer products that comply with these specs. In this sense they are open platforms, J2EE controlled by Sun and the Java Community Process, CORBA by the Object Management Group (OMG). In fact, the J2EE and CORBA specs have been converging in the last few years. On the other hand, Microsoft .NET is proprietary and directed specifically towards a Windows platform. All three platforms provide a large set of technologies, and are more or less appropriate for integration.

Integration Infrastructure And Architecture The Integration Broker An integration broker abstracts a set of technologies that should provide an efficient infrastructure for integration. It effectively presents the infrastructure technologies through a technology abstraction layer. The integration broker solves the point-to-point problem by providing a common mediator for applications connect to, reducing the n-to-n multiplicity to 1-to-n: The integration broker solves the point-to-point problem. It provides a common mediator, to which all applications connect, thus reducing the n-to-n multiplicity to 1-to-n:

Integration Infrastructure And Architecture Point-to-point integration disadvantages: The number of connections between applications can become very high A large number of dependencies between applications requires a lot of effort for maintenance Maintenance of links between applications can become more costly than the maintenance of the applications themselves, which will make the benefits of integration less obvious To get a feeling of the number of connections necessary, let us presume that each application will have to be connected with every other, where we will count unidirectional connections (application A has to be connected to B and B to A — these are two connections). The following graph shows the number of necessary connections in relation to number of applications that have to be integrated: We can see that if we integrate fifty applications on point-to-point basis we would need 2450 connections! In practice, in the real world we will probably not need to connect each and every application with all the others. But this does not change the fact that we will have to manage and maintain a large number of individual connections.

Integration Infrastructure And Architecture Integration Broker/Interoperability Interface: Interoperability interfaces define relations between applications on which applications depend. Interfaces are effectively long living contracts that define the coupling between integrated applications. They provide a façade through which client applications access the interoperability services and encapsulate the applications. As long as the interfaces stay unchanged we can replace parts or whole server applications without influencing any client application. Therefore great effort has to be put into the definition of interoperability interfaces

Integration Infrastructure And Architecture Integration Broker Advantages: The number of connections between application is reduced, thus reducing the level of coupling between integrated applications The dependencies between applications are defined as contracts in the form of interoperability interfaces Maintenance effort and costs are reduced to an acceptable level If the interfaces are carefully designed we can replace parts or whole applications without influencing other involved applications

Integration Infrastructure And Architecture Primary Goals Two goals must be supported by the integration infrastructure and architecture Single data input Low latency information access Single data input ensures that data is entered into the information system only once. Low latency information access assures that the changes made in one part of the information system become visible in all related parts immediately (or in the shortest possible time).

Integration Infrastructure And Architecture Virtual Components Encapsulate the details and methods that existing applications use to satisfy requests. Component Wrapping Powerful technique to address the problem of existing systems that have often been constructed from low-level statements that have nothing to do with the business and its processes.

Integration Infrastructure And Architecture Virtual Components/Component Wrapping

Integration Infrastructure And Architecture Multi-tier Architecture Separates the roles into tiers: User interface Business logic Data persistence Existing applications will be located on the data persistence tier. In the first three integration levels (data, application interface, and business method) we will build the virtual components that will provide interfaces to the existing applications. These virtual components will be deployed the on the business logic tier, which we'll look at in greater depth shortly. In the presentation level integration we will add the newly developed presentation layer and deploy it on the user interface tier. For the communication between the tiers and inside the tiers we will use the integration infrastructure abstracted as the integration broker.

Integration Infrastructure And Architecture Multi-tier Architecture If organized the right way, the composite information system approach can lead to a highly successful project. Without good organization, however, such efforts are likely to fail; those who have failed will try to convince you that the composite information system is a dream that cannot be implemented in the real world — at least not yet with the current technologies. In this and in the next chapter we will present the methods, techniques, and patterns that will help to make a composite information system a reality.

Using RUP For The Integration Process Time and Content Dimensions of RUP The relative emphases of the disciplines change over the life of the project. For example, in early iterations more time is spent on Requirements, and in later iterations more time is spent on Implementation. Configuration and Change Management, Environment, and Project Management activities are performed throughout the project. Keep in mind, however, that all disciplines are considered within every iteration.

Using RUP For The Integration Process An Iterative Life Cycle illustrates how the focus of a project shifts across successive iterations. The size of the boxes within each of the disciplines illustrates the relative time spent performing the activities within that discipline. Each discipline is addressed during every iteration, but the relative emphasis shifts as the project progresses from Requirements to Analysis and Design to Implementation to Test, and finally to Deployment. The some important characteristics of a successful iteration. The iteration has clear evaluation criteria. The iteration has a planned capability that is demonstrable. The iteration is concluded by a minor milestone, where the result of the iteration is assessed relative to the objective success criteria of that particular iteration. During the iteration, artifacts are updated (artifacts evolve with the system). During the iteration, the system is integrated and tested.

Using RUP For The Integration Process RUP Phases and Milestones There is more to an iterative development process than a stream of iterations. There must be an overall framework in which the iterations are performed that represents the strategic plan for the project and drives the goals and objectives of each of the iterations. Such a framework is provided by phases. Phases provide well-defined business milestones that ensure that the iterations make progress and converge on a solution, rather than just iterating indefinitely. Phases and iterations together provide the foundation for iterative development. The objectives of each phase are achieved by executing one or more iterations within the phase. Each phase concludes with a major milestone and an assessment to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase. Iterations are time-based (they are of a fixed duration), whereas phases are goal-based. A phase cannot be time-boxed since the completion of a phase is assessed based on the state of the project. In RUP, the software development life cycle is decomposed into four sequential phases: Inception, Elaboration, Construction, and Transition.

Using RUP For The Integration Process Activities and Phases Relationship between the phases and the activities Technical activities include: Requirements gathering; Analysis of existing applications; Selection of the integration infrastructure; Problem domain analysis; Design; Implementation; Testing; Deployment. Support activates are: Project management; Configuration and change management; Communication with the environment. Technical activities will be performed by analysts, architects, designers, developers, programmers, and testers. Integration is usually achieved in four phases: Data level integration; Application interface level integration; Business method level integration; Presentation integration These four integration phases are usually done sequentially, although not always. Sometimes we can skip a phase. For example, we could skip data level integration and proceed with application interface level. The question is how to connect the activities and the phases of an integration process. The answer is that we will perform these activities for each of the integration phases.

J2EE As An Integration Platform J2EE Platform Framework that provides technologies for the design and development of multi-tier business applications Provides services such as database access, security, transaction support, resource management, and so on. Ease the development enabling the developer to concentrate on the business functions he has to implement, not on the technologies involved.

J2EE As An Integration Platform J2EE Multitier Architectures 3-Tier Architecture:

J2EE As An Integration Platform The J2EE Platform and Technologies Shows a multitier deployment configuration

J2EE As An Integration Platform J2EE Technology Summary

J2EE As An Integration Platform J2EE Application Component Technologies Applets. An applet is primarily used to provide some form of rendering in the user interface, where performance is key. Application clients. An application client is a standalone Java application that provides an alternate means of accessing a J2EE application, other than through the use of a markup language such as Hypertext Markup Language (HTML). Java Servlets ("servlets"). A servlet defines how a request from the client is processed and how a response is generated. JavaServer Pages (JSPs). A JSP is a text document that, like a servlet, describes how a request is processed and a response generated. JSPs provide an alternative to servlets when the generation of statements in a markup language (such as HTML) is required. Enterprise JavaBeans (EJBs). An EJB is responsible for implementing an aspect of the business logic of a J2EE application. The application component technologies are those that we use to build the components of the solution. Each of these technologies is discussed in detail later in this chapter. The J2EE application component technologies are described in the following list.

J2EE As An Integration Platform J2EE Services Java API for XML Parsing (JAXP). JAXP provides a standard service that supports the parsing and manipulation of XML documents. JAXP provides a further abstraction when using an external standard such as the Simple API for XML Parsing (SAX), the Document Object Model (DOM) and eXtensible Stylesheet Language Transformations (XSLT). Java DataBase Connectivity (JDBC). JDBC provides programmatic access to a relational database. Java Message Service (JMS). JMS provides a standard interface to reliable asynchronous messaging implementations (such as IBM's MQSeries or Tibco's Rendezvous). Java Authentication and Authorization Service (JAAS). JAAS allows J2EE applications to authenticate users (to reliably and securely determine who is currently executing Java code) and authorize users (to ensure that they have the permissions required to perform the necessary actions). Java Transaction API (JTA). In circumstances where programmatic control of transactions is required, JTA provides a standard interface to the transaction services. JavaMail API (JavaMail). The JavaMail API allows application components to send mail using a standard interface. Typical implementations of the JavaMail API interface to a number of protocols and specifications, such as the Simple Mail Transfer Protocol (SMTP), Multipurpose Internet Mail Extensions (MIME) and Post Office Protocol 3 (POP3). J2EE Connector Architecture (JCA). One of the common requirements of an enterprise application is the ability to connect to enterprise information system (EIS) resources. Some of these resources may be external applications that are accessed using a vendor-specific protocol. JCA provides a standard means for providing resource adapters (more commonly known as "connectors"). J2EE services, as the name implies, are the services made available by the J2EE platform. They are described in the following list.

J2EE As An Integration Platform J2SE Services Hypertext Transfer Protocol (HTTP) API. The HTTP API is a client-side API that supports interaction with server-side presentation tier elements using HTTP, the standard protocol for communication on the Web. In many applications, this API is not used since the use of HTTP is handled entirely by the client device and requires no programmatic involvement. For example, the submission of an HTML form to a Web server is handled entirely by the Web browser. HTTPS API. HTTPS is the use of HTTP over the Secure Socket Layer (SSL). SSL is a security protocol used by Web servers and client devices (such as a Web browser) to establish a secure communication channel over HTTP. This API is the secure equivalent of the HTTP API. Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP). RMI is a Java standard for providing distributed object communication between two Java objects. In order to provide maximum interoperability between elements that may not be written in Java (such as an EJB container), the J2EE platform stipulates that the language-independent Internet Inter-Orb Protocol (IIOP) be used. IIOP is an element of the CORBA (Common Object Request Broker Architecture) standard that is defined by the Object Management Group (OMG). Java Naming and Directory Interface (JNDI). JNDI provides a uniform interface to a number of directory and naming services, which support the locating of resources on a network. For example, JNDI can be used to obtain a reference to the home interface of a remote EJB. The J2EE platform is dependent upon services provided by the Java 2 Platform, Standard Edition (J2SE)[4]. The J2SE services include support for collections, internationalization (support for multiple human languages), input/output, Java Archive (JAR) files, user interfaces, math, networking, object serialization, Remote Method Invocation (RMI), security, and sound. The J2SE technologies in the following list are considered essential parts of the J2EE platform.

J2EE As An Integration Platform Multitier Deployment Configuration The multitier deployment configuration includes both a Web container and an EJB container. Presentation logic is handled by elements in the Web container, with business logic handled by EJBs in the EJB container. In this configuration, clients aren't affected by changes to EIS resources since these resources aren't accessed directly by the clients. It is also possible to redeploy the entire application without requiring any rollout to clients, since the application resides wholly on the server. From a scalability perspective, the EJB container is responsible for ensuring efficient use of limited resources, such as database connections. From an application evolution and maintenance perspective, this configuration encourages a clean separation of responsibilities. The presentation logic is decoupled from EIS resources, and the business logic is decoupled from the look and feel. This separation helps when allocating work to developers with different skills. It also allows for concurrent development, testing, and deployment of presentation logic and business logic elements. The decoupling of presentation logic and business logic also increases the reuse potential of the business logic elements.

J2EE As An Integration Platform J2EE Pattern Tiered approach Experts define a pattern as a recurring solution to a problem in a context Since this catalog describes patterns that help you build applications that run on the J2EE platform, and since a J2EE platform (and application) is a multitiered system, we view the system in terms of tiers. A tier is a logical partition of the separation of concerns in the system. Each tier is assigned its unique responsibility in the system. We view each tier as logically separated from one another. Each tier is loosely coupled with the adjacent tier. We represent the whole system as a stack of tiers.

J2EE As An Integration Platform Presentation Tier Patterns Intercepting Filter (144)Facilitates preprocessing and post-processing of a request. Front Controller (166)Provides a centralized controller for managing the handling of a request. Context Object (181)Encapsulates state in a protocol-independent way to be shared throughout your application. Application Controller (205)Centralizes and modularizes action and view management. View Helper (240)Encapsulates logic that is not related to presentation formatting into Helper components. Composite View (262)Creates an aggregate View from atomic subcomponents. Service to Worker (276)Combines a Dispatcher component with the Front Controller and View Helper patterns. Dispatcher View (288)Combines a Dispatcher component with the Front Controller and View Helper patterns, deferring many activities to View processing. The presentation tier patterns contain the patterns related to servlets and JSP technology.

J2EE As An Integration Platform Business Tier Patterns Business Delegate (302)Encapsulates access to a business service. Service Locator (315)Encapsulates service and component lookups. Session Façade (341)Encapsulates business-tier components and exposes a coarse-grained service to remote clients. Application Service (357)Centralizes and aggregates behavior to provide a uniform service layer. Business Object (374)Separates business data and logic using an object model. Composite Entity (391)Implements persistent Business Objects (374) using local entity beans and POJOs. Transfer Object (415)Carries data across a tier. Transfer Object Assembler (433)Assembles a composite transfer object from multiple data sources. Value List Handler (444)Handles the search, caches the results, and provide the ability to traverse and select items from the results. The business tier patterns contain the patterns related to the EJB technology.

J2EE As An Integration Platform Integration Tier Patterns Data Access Object (462)Abstracts and encapsulates access to persistent store. Service Activator (496)Receives messages and invokes processing asynchronously. Domain Store (516)Provides a transparent persistence mechanism for business objects. Web Service Broker (557)Exposes one or more services using XML and web protocols The integration tier patterns contain the patterns related to JMS and JDBC.

J2EE As An Integration Platform Refactor Architecture by Tiers Increasing architectural sophistication requires changing the localization of data access logic and processing logic. Move data access code logically and/or physically closer to actual data source. Move processing logic out of client and presentation tiers into business tier. The J2EE platform offers clear separation of concerns into the roles of servlets, JSP, and EJB components to provide maximum benefits in terms of scalability, flexibility, transactions, security, and so forth. As business requirements become more sophisticated, the design needs to better address issues related to persistence, transactions, security, and scalability of business services. At some point in this increasing complexity, session beans and entity beans are introduced to provide centralized business processing for all clients and to leverage the benefits of the EJB container. Some designers use heavyweight components like enterprise beans without ensuring that the application requirements warrant their use. Some sophisticated application requirements that influence this decision are transactions, security, scalability, and distributed processing.

J2EE As An Integration Platform Refactor Architecture by Tiers Separate data access code from control and entity objects into data access objects. Separate presentation and business processing. Introduce session beans for business processing. Retain presentation processing in servlets and JSP. Introduce entity beans to model-shared, transactional, coarse-grained persistent business objects. If requirements do not warrant using entity beans, then skip this step. Decouple presentation tier and business tier components, using business delegates. Separate data access code from control and entity objects into data access objects. See "Separate Data Access Code" on page 102. Separate presentation and business processing. Introduce session beans for business processing. Retain presentation processing in servlets and JSP. Apply this step when application requirements become more sophisticated, and as business logic consolidation is required at the business tier to offer the same business service to all clients (i.e., not only to presentation clients). Introducing session beans as business service processing components enables this functionality. Session beans access the persistent storage via the data access objects. Container-managed or bean-managed transaction demarcation can be utilized as appropriate for the session beans. See Session Façade (341). Introduce entity beans to model-shared, transactional, coarse-grained persistent business objects. If requirements do not warrant using entity beans, then skip this step. See next page for additional notes

Data Level Integration Data level integration focuses on moving data between applications with the objective of sharing the same data among these different applications. Sequence of tasks: Notes from previous slide Apply this step when the persistent business components become increasingly complex and you wish to leverage the entity bean benefits, including container-managed transactions and container-managed persistence (CMP). Entity beans offer container-managed transaction for transaction demarcation. This allows declarative programming for transaction demarcation without hardcoding the transaction logic into the enterprise beans. See Transfer Object (415) and Composite Entity (391) Decouple presentation tier and business tier components, using business delegates. Business Delegate (302) decouples the presentation-tier components from business-tier components and hides the complexity of lookup and other implementation details. See Business Delegate (302).

Data Level Integration Identifying the Data Identify the data that already exists. Create data models of each application Differences from actual implementation in attributes and fields Fully understand the semantics

Data Level Integration Identifying the Database Types Relational Object-oriented Universal Multidimensional Hierarchical and Network Legacy systems might use some proprietary file structures database formats like CODASYL — a standardized format to store data and access them from COBOL The second step in data level integration is physical implementation — the data model and the way in which we can actually access the database.

Data Level Integration Defining the Enterprise Data Model High-level enterprise data representation In a consistent way Focusing on relations between the data in the enterprise Identify which datasets support which business areas throughout the enterprise and how. The situation before integration can have the following characteristics: Some data may be redundant Applications are independent, unconnected, and have separated processes Many steps are required for data transfers Transfers are packet based Systems are physically and logically independent

Data Level Integration Implementing Data Level Integration The solution to implement data level integration more efficiently is use the integration broker. Instead of implementing point-to-point connection between the applications, we implement one or more virtual components for each application database. The final step of the data level integration is implementation. Always try to avoid point-to-point integration due to the associated disadvantages resulting in many connections that become very difficult to manage, control integrity and maintain as the number of databases increases over time. The rules of individual databases guarantee integrity and the description of the rules depends on the database model. For example in the relational model the integrity rules can be expressed using formal methods or with database-provided constructs. Problems of integrity arise because the database is accessed directly in data level integration bypassing the business logic which implements integrity-checks and business rules. Accessing the database directly is simpler than accessing then application interfaces, although in long term the business rules will have to be re-implemented which negates this simplicity because of maintenance.

Data Level Integration Implementing Data Level Integration Using virtual components and an integration broker key advantages of defining virtual components with public interfaces for data synchronization as follows: The architecture for application integration is given a solid starting point Reduced maintenance effort because of the simplified relationships Communication can be event driven

Business Level Integration: Business level integration focus on sharing functionality and data, not only pure data as in data level integration Consists of two parts: Application interface level integration Business method level integration

Business Level Integration: Application Interface Achieved through the use of APIs. Need to satisfy one of three requirements: APIs are already built into the existing application Add a wrapper through the modification of existing application source code Add a wrapper by accessing the functionality of the existing application through the simulation of user interaction In the past, developers did not realize the usefulness of APIs, therefore most older applications do not have them. Since then newer applications have accepted the idea that an application can provide services to other applications. Thus, we are more likely to find APIs in newer applications. Fortunately, application level integration does not require that the existing applications have the API implemented. If it does not implement the API, we will have to wrap it. We will build wrappers that will add the required interfaces to existing applications.

Business Level Integration: Application Interface Achieved by following the steps shown in the diagram below: Analysis of Functionality Available through Interfaces, existing applications that provide access to limited functionality, all functions or data only through business rules. Analysis of Technologies to Access the Interfaces, existing applications since the technology use to implement the interfaces differs. Interfaces can provide synchronous or asynchronous means of communication, and applications that use standardized interfaces will often utilize middleware to provide this communication [11]. Adding Interfaces through Existing Application Wrapping, iis to use the existing application wrapping to add the interfaces to existing application. An assessment can determine whether it is worth the invested Masking the Technology Differences, is the task of masking the technology differences [11]. The APIs cannot be used directly since not all applications uses the same technology to access the interfaces; the differences between the technologies can be masked by using virtual components. The integration broker pattern makes this a relatively easy task, similar to developing virtual components for data level integration.

Business Level Integration: Application Interface Integration broker pattern Build virtual components that will mask differences between the technologies. Define the same (or slightly modified) interfaces for the virtual components. We will use the integration broker technology to achieve interoperability, and we will simply delegate the requests from the virtual components to the application specific interfaces of existing applications. This will provide access to APIs that is based on a single technology and will mask the differences between the protocols and technologies used for APIs by existing applications. It will also put the whole code that takes care of adapting the technologies (the bridge code) in one place — in the virtual component — where it can be used by all clients. There will be no need for each client to bother with the conversion of protocols, and this will simplify the maintenance considerably. Such virtual components will still present relatively low-level interfaces; therefore we will refer to them as lower level application interface level virtual components. The architecture of application interface integration with virtual components is shown schematically in the following figure:

Business Level Integration: Business Method The goal of business level integration is to develop virtual components that will provide interfaces with high-level business methods that can be considered as business services. To achieve proceed in three steps: The definition of high-level business interfaces is the first step in business method level integration. In the second step we have to map the business operations to the lower level virtual components that represent the existing applications. Implementing the Higher Level Virtual Components With the mapping of high-level business operation from the interfaces we have been faced with three possible scenarios: We could map a high-level business method entirely to a set of lower level virtual component operations We could map them partially We could not map them at all

Business Level Integration: Business Method The result of the method level integration is the virtual components that expose high-level business interfaces. It is important to realize that the higher level virtual components use lower level virtual components that we developed with application interface level and data level integration. This is shown schematically in the next figure:

Presentation Level Integration The Final Step Solve the problems of the user interface is not unified and users need to make several steps to perform a certain business operation and have to switch between different applications. Define and implement a common user interface for the business method level integrated system. Such a user interface will provide the illusion of a new system, and add the missing piece to the multi-tier integration architecture.

Presentation Level Integration The Final Step Sequence of activities shown in the figure below We will have to select which user interfaces we need in the integrated information system. We have to be pragmatic and select first those parts that are in greatest need of the user interfaces. Sometimes, particularly if we use some large existing applications, like ERP systems, we will not even renew the whole user interface. Users of ERP systems only, for example, will continue using their existing user interfaces. We will have to map the user interface operations to business methods on the business logic tier. This mapping will be quite straightforward, because all the required functionality already exists on the middle tier. Finally, we will have to implement the new presentation tier. For user interface implementation we can choose different approaches, including:

Presentation Level Integration Basic principle of separation of user interface, business logic, and data persistence tiers

Business-to-business (B2B) integration Web services are loosely coupled components that encapsulate functionality targeted to B2B collaborations. Hence, we can add another tier — the web services tier — to our architecture that will provide some of those services to business partners. These B2B web services will be modeled similar to the business methods for the EAI integration. However, their purpose and meaning will be different, in accordance with the needs and goals of B2B integration. Web services are a set of technologies that enable us to define interfaces, which describe a collection of operations that are network accessible through standardized XML messaging, using standardized Internet protocols. Conceptually, web services represent an architecture where tasks within B2B processes can be distributed among the partners that have access to them through the Internet. Technically, web services are a set of technologies and standards that enable the service-oriented and component- based architecture of B2B applications.

Conclusions Solution: EAI - Enterprise Application Integration The unrestricted sharing of data and business processes among the connected applications and data sources in an enterprise. EAI is basically a new name for the integration processes that computer scientist have been working on for years. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding or migrating to a new set of applications that exploit the Internet, e-commerce, extranet, and other new technologies. EAI involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new view, and then devising ways to efficiently reuse what already exists while adding new applications and data. Any reasonably large company will have many applications probably written using many different technologies which is a common occurrence from mergers, acquisitions of businesses and/or as a company grows. It is vital to tie these existing systems together since the cost of maintaining many disparate systems is large, and the benefits of doing so will surely diminish over time.

References [1] Enterprise application integration using a component-based architecture by Maheshwari, P.; Computer Software and Applications Conference, 2003. COMPSAC 2003. Proceedings. 27th Annual International , 3-6 Nov. 2003, Pages:557 - 562 [2] Architectures and technologies for enterprise application integration by Gorton, I.; Liu, A.; Software Engineering, 2004. ICSE 2004. Proceedings. 26th International Conference on , 23-28 May 2004, Pages:726 - 727 [3] Modeling EAI [Enterprise Application Integration] by Losavio, F.; Ortega, D.; Perez, M.; Computer Science Society, 2002. SCCC 2002. Proceedings. 22nd International Conference of the Chilean , 6-8 Nov. 2002, Pages:195 - 203 [4] The role of services in enterprise application integration by Kontogiannis, K.; Smith, D.; O'Brien, L.; Software Technology and Engineering Practice, 2002. STEP 2002. Proceedings. 10th International Workshop on , 6-8 Oct. 2002, Pages:103 - 113

References [5] Integration Technology Adoption in Healthcare Organisations: A Case for Enterprise Application Integration by Khoumbati, K.; Themistocleous, M.; Irani, Z.; System Sciences, 2005. HICSS '05. Proceedings of the 38th Annual Hawaii International Conference on , 03-06 Jan. 2005, Pages:149a - 149a [6] Enterprise Architecture Integration in E-Government by Janssen, M.; Cresswell, A.; System Sciences, 2005. HICSS '05. Proceedings of the 38th Annual Hawaii International Conference on , 03-06 Jan. 2005, Pages:118b - 118b [7] Developing E-Government Integrated Infrastructures: A Case Study by Themistocleous, M.; Irani, Z.; Love, P.E.D.; System Sciences, 2005. HICSS '05. Proceedings of the 38th Annual Hawaii International Conference on , 03-06 Jan. 2005, Pages:228 – 228

References [8] Building J2EE Applications with the Rational Unified Process by Peter Eeles, Kelli Houston, Wojtek Kozaczynski, Addison-Wesley 2003 [9] Core J2EE Patterns Best Practices and Design Strategies by Deepak Alur, John Crupi, Dan Malks. Prentice Hall 2003 [10] Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Interative Developement; by Graig Larman, Prentice Hall 2005 [11] Professional J2EE EAI by Matjaz Juric et al., Apress © 2004 [12] Data Quality: The Accuracy Dimension by Jack E. Olsen, Morgan Kaufmann Publishers ©

References [13] Building Corporate Portals with XML by Clive Finkelstein and Peter Aiken McGraw-Hill © 2000 [14] Cocoon 2 Programming: Web Publishing with XML and Java by Bill Brogden, Conrad D'Cruz and Mark Gaither Sybex © 2003 [15] Corporate Portals Empowered with XML and Web Services by Anura Guruge Digital Press © 2003 [16] Data Quality: The Accuracy Dimension by Jack E. Olsen Morgan Kaufmann Publishers © 2003 [17] Enterprise Java Development on a Budget: Leveraging Java Open Source Technologies by Christopher Judd and Brian Sam-Bodden Apress © 2004 [18] Developing Secure Web Applications; available at http://java.sun.com/developer/Books/certification/scwcd_9.pdf

References [19] Struts: The Complete Reference, by James Holmes, Publisher: McGraw-Hill Osborne Media; 1 edition (April 30, 2004), ISBN: 0072231319 [20] A Guide to Building Secure Web Applications; available at http://www.cgisecurity.com/owasp/html/ [21] Transforming Legacy Web Applications to the MVC Architecture, by Yu Ping; Kontogiannis, K.; Lau, T.C. Software Technology and Engineering Practice, 2003. Eleventh Annual International Workshop on, Vol., Iss., 19-21 Sept. 2003, Pages: 133- 142 [22] Reengineering legacy application to e-business with modified Rational Unified Process, by Jeyaraman, G.; Krishnamurthy, K.; Raveendra, V.V.S. Software Maintenance and Reengineering, 2003. Proceedings. Seventh European Conference on, Vol., Iss., 26-28 March 2003, Pages: 143- 150