InternetInternet EngineeringEngineering TomaszBabczyTomaszBabczy ńński,ski, ZofiaZofia KruczkiewiczKruczkiewicz TomaszKubikTomaszKubik InformationInformation systemssystems modellingmodelling –– UMLUML andand serviceservice descriptiondescription languageslanguages Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

1. A definition of the Business Tier – a five-tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier 4. Analysis of basic design issues Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

1. The definition of the Business Tier – a five- tiered model of logical separation of tasks Multitiered Information System by D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

Client Tier Interacting with the user, device and user interface Customer applications, applets, elements of presentation the graphical user interface

Presentation Tier Login, session management, content creation and delivery, JSP Pages, servlets, and other user form atting and validation interface elements

Business Tier Business logic, transactions, EJB components and other business data and services objects

Integration Tier Resource adapters, external systems, mechanisms for JMS, JDBC, connectors and connections resource, control flow with external systems

Resource Tier Resources, data and external Databases, external systems and other services resources

Business Tier (Tutorial Java EE 5)

Application Client Web Browser, And Optional Web Pages, JavaBeans Applets, and Client Tier Components Optional JavaBeans Components

JavaBeens Web Pages Components Servlets Web Tier (Optional)

Java EE Java Persistence Entities Business Tier Server Session Beans Message-Driven Beans

Database and EIS Tier Legacy Systems Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues Basic issues of Business Tier design

1. Using session components 2. Use of Entity components 3. Caching references and handles to remote enterprise bean components Using session components (1) The session component (EJB specification) is characterized as follows: • It is used by one customer or user • There is only for the duration of the session • It is destroyed during the failure of container • It is not a permanent object • There is a time limit of its life • It may participate in transactions • It can be used to modelling communication such as stateful or stateless between the Client and Business Tier components Using session components (2) – Component stateless session: • Do not store customer session data • Can be allocated any instance of the stateless session component for each customer from a pool of stateless session components • They are used in case of a service that requires only one method call – Component stateful session: • Stores session state • Components are returned into a pool of session stateful component only when the client has completed its session • If the service requires a number of method calls to complete the transaction, which is a conversational process. This choice improves the scalability of the system Using session components (3) • Storing session state: – Web Applications store the session state of clients in the Presentation Tier – Applications, with different types of clients, are keeping the session state in the Business Tier • Managing session state is dependent on: – Hardware – Network Traffic Management – The use of clustering for Web container – The use of clusters for the EJB container – Linking client session to a particular server in the cluster – Session Replication – Session Persistence Using Entity components – EJB specification (1) • Entity components are distributed, shared and persistent transactional objects, which work inside EJB containers • Entity components are used as the data of some business services • EJB containers provide additional infrastructure to support scalability, security, performance, clustering • Specification of Entity components (EJB specification): – They represent an object-oriented view of life – They participate in transactions – They are shared by multiple users – They have a long life – They are resistant to a failure of the container. This type of system crashes are usually invisible to customers Using Entity components – EJB specification (2) The Entity component must contain the business logic associated with the providing of services, which is self-sufficient in terms of handling their own data and data objects belonging to the dependent objects (POJOobjects) . Keys in Entity components (for databases services): • A complex primary key requires a definition of class that implements the Serializable interface. Attributes of this class are the key attributes of the main complex key • The primary key class must redefine the hashCode and equals methods • If the primary key consists of a single attribute, then you can use the built-in type of the key Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier Bad practices (1) • Mapping an object model directly on the model of Entity components – Impact: • Large container load • Generating high traffic – Solution: • Reducing the number of components - an application of the Composite Entity pattern • Creating a tier of access to services - the use of the Session Facade pattern Bad practices (2) • Mapping the relational model directly on the model of Entity components – Impact: • Large number of Entity components • Complex relalationships between Entity components – Solution: • Reducing the number of components - an application of the Composite Entity pattern • Moving the business logic to the Seession components - the use of the Session Facade pattern Bad practices (3)

• Mapping each use case at a one session component – Effects • A large number of session components - high complexity applications – Solution • Session Facade pattern • Sharing all the attributes of components by the method of setting and collecting: set and get – Impact: • Large network traffic – Solution: • Transfer Object pattern Bad practices (4) • The client stores data of business components – Impact: • Large network traffic • Dependence on the model of client applications • Difficulties in modifying the software – Solution: • Transfer Object Assembler pattern • Embedding search services on the client side – Impact: • Visualization of the complexity of an application to the client • Redundant code - in case of changes to modify the code in many places in the application – Solution: • Business Delegate pattern • Locator Service pattern Other bad practices (5)

• The use of components of the Entity as read-only objects • Using the Entity objects as a minor component • Saving an entire graph of related Entity components • Disclosure of the exceptions relating to EJB to customers outside the EJB Tier • Stateless session component restores session state for each call • Searching data using the methods, that return references to remote objects Design patterns used to build the Business Tier D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

1. The definition of the Business Tier – a five- tiered model of logical separation of tasks 2. Basic Business Tier design issues 3. Bad practices when designing the Business Tier 4. Analysis of basic design issues Design cases 1. Conceal from the client program the complexity of remote communication with business service component 2. Transparent and uniform way to search services and business components 3. Sharing components and business services to remote clients (take control of the business objects and reducing network traffic, or improve efficiency) 4. Centralization of some business logic components and business services 5. The object model is an implementation of the conceptual model, which is the domain model, containing relationships and business logic 6. Use of Entity components to implement the conceptual domain model 7. Transferring data between tiers of application (reducing network traffic by reducing the number of remote calls, or improve efficiency) 8. Making lists of objects for remote clients applications Problem 1 – Conceal from the client program the complexity of remote communication with business service component

Servlets and JSP with Session Logic of Data presentation logic Acc es Component with and: many searches business logic of and calls of business s ervices services, error services of other layers ect

C lien t Se ssion Code of S er vlets, Co m po n en t Data Access D atabase JS P

Client Tie r Presentation Inte gration R eso ur ce B u sine ss Tier Tie r Tie r T ier

Servlets and JSP presentation Session Logic of Data logic and Business Delegate for Component with Ac ces separating layers but searches o f business logic of business services services

C lient C ode of Data Se rvlets , B u sin ess Session Datab ase Acce ss Component JS P Deleg ate 1

Client T ier Presentation Integ ration B u sin ess R esourc e Tier Tier Tier T ier Refactorization by using Business Delegate component

Session Entity Business Session Entity Component Component Delegate 1 Component Component 1 1 1 1

Session Entity Business Session Entity Client Client Component Component Component Delegate 1 Component 2 2 2 2

Session Entity Business Session Entity Component Component Delegate 1 Component Component 3 3 3 3

Client and Client and Presentation Presentation Business Tier Business Tier Tier Tier Requirements

• It should have access to the Business Tier components from the presentation components and clients, which can be any device, web services and rich clients • Linking should be minimized relationship of clients and business services • It should avoid unnecessary calls of business services • Exceptions of the network and business services should change on exceptions of the Presentation or Client Tier • It should hide in the Presentation or Client Tier the details of the use of services, their configuration, and repeated attempts to call The components of the pattern • ServiceLocator • BusinessService

Implementation of the pattern

• The representative of an intermediary ( Proxy Delegate ) • Representative adaptable (Delegate Adapter ) EJB, JMS components, or part of SessionFacade pattern Business service call Business service call and store the business handle Result • Reduction of dependency between the Presentation Tier and Business Tier, hiding the implementation of the Business Tier • Transforming the exception of business services onto exceptions easily handled in the Presentation Tier • Increased availability of services • Making the Business Tiers simpler for the Presentation Tier • Caching ability of results and references to remote services, which reduces network traffic and improves application performance • Placing an additional tier - it can sometimes be a disadvantage Problem 2 – Transparent and uniform way to search services and business components Service Locator

Servlets and JSP presentation Session Logic of Data logic and Business Delegate for Component with A c ce s separating layers but searches of business logic of business services s e rv ic e s

C li e n t C ode of Data Se rvlets, B u sin e ss Sessio n Acce ss D atab ase Component J S P Deleg ate 1

Clien t T ier Presentation In teg ration B u s in e s s R esou rc e T i e r T i e r T i e r T ie r

Servlets and JSP presentation Session logic and Business Delegate for Component with separating layers and Service business logic of Locator for searches of business s e rv ic e s Logic of Data ser v ic e s A c ce s

C li e n t B u sin e ss Deleg ate 1 C ode of Data Se rvlets , Sessio n D atab ase S e rv ic e Acce ss J S P L o ca t o r Component

Clien t T ier Presentation B u s in e s s In teg ration R esou rc e T i e r T i e r T i e r T ie r Requirements

• It should use the JNDI interface to search for business components (eg. EJB or JMS) or services (eg. data sources) • It should centralize searches of business services in the Client Tiers • It should hide implementation details and complexity of search components • It should avoid the loss of efficiency associated with the creation of context and search services • It should be allowed to re-use found handles of business services The components of the pattern • Client • Service Locator • Cache • Initial Context • Target • RegistryService Implementation of the pattern • EJB Service Locator • JDBC Data Source Locator • JMS Service Locator • Locator JMS queues • JMS Topics Locator • Web Service Locator BusinessDelegate,DAO

EJB,JMScomponents Acomponentor aservice of Business orthe IntegrationTier:EJB,JMS,DataSource Search business services components Result

• Hiding complexity • Providing uniform access to data • Facilitate the addition of EJB business components • Improving network performance in providing services • Improving performance through caching handles of services Problem 3 – Sharing components and business services to remote clients (take control of the business objects and reduce network traffic, or improve efficiency)

Component Component E ntity A Session Entity A Client Client Facade as Session Business Component Facade Co m ponent logic E ntity B Entity B B usiness logic

Component Component Transaction E ntity C Entity C logic Transaction Logic managed by Session Component,

special components

or Cont ener Client or Client or Business Presentation Tier Presentation Tie r Tier Business Ti er Requirements – Session Facade

• It should prevent clients from direct access to components of Business Tiers to prevent the establishment of too many dependencies between clients and the Business Tier (1) • It should provide the tier of remote access to Business Object components (issue 5), or other business objects • Application services should be grouped and provided to remote clients (ie Application Service pattern) and any other services • It should centralize and combine all of the shared business logics to remote clients • It should hide the complex interactions and interdependencies between the components and business services The components of the pattern

• Client • SessionFacade • BusinessComponent • ApplicationService • DataAccessObject (DAO) Implementation of the pattern • Stateless session component • Stateful session component Business Delegate pattern Providing business services to clients by hiding access to business components Result • Introduction of a tier that provides services to remote clients • Providing a uniform interface • Reduce dependency between tiers • Promoting the tiered model , increasing flexibility and ease of management • Reduce the complexity of the session facade services , if applied with Application Service components • Improving productivity , reducing the number of fragmented remote methods • Centralization of Safety Management • Centralized management transactions • Sharing a smaller number of remote customer interfaces Problem 4 – Centralization of business logic components and business services Application Service

Session Entity Session Entity Client 1 Component Component Client 1 Component Service Component 1 1 1 Application 1 Component A Session Entity Session Entity Client 2 Component Component Client 2 Component Co mponent 2 2 2 2

Service Session Entity Session Application Entity Client 3 Comp onent Component Client 3 Component Component Component 3 3 3 B 3

Client and Client and presentation Business Tier presentation Tier Tier Business Tier Requirements

• It should limit the amount of business logic in the facades of services. • The business logic operates on a number of business objects or services . • It should be used to create a integrated services interface for the existing components and business services. • It should place the logic associated with the specific use cases outside the Business Objects components (issue 5) The components of the pattern

• Client • Application Service • BusinessObject (issue 5) • Service • DataAccessObject Implementation of the pattern

• Application Service Command • Application Services using the GOF Strategy pattern • Application service tier

Result

• The centralization of business logic used repeatedly • Increasing the multiple use of business logics • Prevention of code duplication in client components • Simplifies the implementation of session facades • The introduction of additional tiers within the business tier (centralized of common business logic) Problem 5 – The object model is an implementation of the conceptual model as the domain model, containing relationships and business logic Business Object

Servlets and JSP with presentation and small business logic without consolidation for other clients – small application

C lie n t Servlets, Code of D ata JS P A ccess D ata B a se

Client Ti e r R esourc e Presentation Tier T ie r

Data Acces Servlets and JSP with Se ssio n logic with direct presentation logic and Component with controller to separate layers business logic accesss to d atab as es

C lie nt Session C ode of Se rvlets, B u sin ess Component D a ta Data A ccess JS P Delegate 1 B ase

R eso urc e Client Tier Integration Presentation Tier Business Tier Tie r T ie r

Servlets and JSP with Session Data Acces presentation logic and Component with logic with direct accesss to controller to separate layers business logic databases

Client Session Code of Servlets, Business Component Data Data Access JSP Delegate 1 Base

Resource Client Tier Integration Presentation Tier Business Tier Tier Tier

Session Component with business Data Acces Servlets and JSP with logic, Entity Components as logic with JPA presentation logic and persistence transaction objects accesss to controller to separate layers databases

Client Session Code of Servlets, Business Component Data JSP Data Access Delegate 1 Base Entity Component

Client Ti er Integration Resource Presentation Tier Tier Tier Business Ti er Business model, business use case model, business object model, domain model, object model, data model (The Unified Software Development Process [Jacobson]) • The business model consists of two models: business use case model describing actors and business processes and business objects model , used to describe entities in the various use cases • Domain model or otherwise conceptual model is an abstract model that describes the main types of objects in the system. Domain objects represent events and "things" that exist in an environment where the system works. Domain model is treated as business model. Requirements

• There is a conceptual model containing structural complex interrelated objects . • There is a conceptual model with strictly defined business logic and business rules restrictions (1). • State business of the application and the related behaviour from the rest of the application should be separated, improving the consistency and ease of reuse application components . • It should centralize business logic and states of business applications in one place. • It should enhance their ability to reuse business logic and avoid the code duplication of . The components of the pattern • Client • ParentBO • DependentBO

Implementation of the pattern • Business Objects as ordinary Java objects (POJO Business Objects ) • Business object in the form of a complex Entity component (issue 6) implementtheirownrulesandbusinesslogic.

a GOF facade

Result • Promote of object-oriented approach to the implementation of the business model • Centralization of business logic and the state and the promotion of reusable components • Avoiding code duplication and make it easier to care • The separation of persistence logic from business logic • Promoting service-oriented architecture • The use of ordinary Java objects can lead to outdated information, if they are not implemented their own mechanisms for synchronization and data integrity • Adding an additional tier - it is not necessary in cases of simple logic, or directly benefit from the business model realized as a relational database schema. However, this may be the result of an error • Danger of creating very complex objects Problem 7 – Transferring data between application tiers (reducing network traffic by reducing the number of remote calls, or improving efficiency) Transfer Object

Requirements • Independence of implementation of the Presentation Tier from Business Tier objects and the Business Tier from the tiers of integration • It should clients allow access to components from other tiers and the ability to download and modify their data. • It reduces the number of remote calls - it should avoid the performance degradation caused by the large number of remote calls. The components of the pattern • Client • Component • PresComponent • BizComponent • IntComponent • TransferObject Implementation of the pattern • Transfer object with modification ability • Many of the transfer objects • Entity component inherited from a Transfer Object Serializable interface

BusinesObject, Business ApplicationService, DataAccessObject pattern Delegate SessionFacade components

Result

• Reducing network load • Simplifying remote objects and interfaces • Sending more data with fewer remote calls • Reduce duplication of code by inheriting the Entity object from the Transfer Object component • The possibility of exist of obsolete transfer objects • Increased complexity due to synchronization and version control for objects with modification