service description languages

(1)

Internet Engineering

Tomasz Babczyński, Zofia Kruczkiewicz Tomasz Kubik

Information systems modelling – UML and

service description languages

(2)

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

(3)

Design patterns used to build the Business Tier

1. The definition of the Business Tier – a five-

tiered model of logical separation of tasks

(4)

Multitiered Information System

by D.Alur, J.Crupi, D. Malks, Core J2EE. Desin Patterns

Client Tier

Customer applications, applets, elements of the graphical user interface

Presentation Tier

JSP Pages, servlets, and other user interface elements

Business Tier

EJB components and other business objects

Integration Tier

JMS, JDBC, connectors and connections with external systems

Resource Tier

Databases, external systems and other resources

Interacting with the user, device and user interface

presentation

Login, session management, content creation and delivery,

formatting and validation Business logic, transactions,

data and services

Resource adapters, external systems, mechanisms for

resource, control flow Resources, data and external

services

(5)

Business Tier (Tutorial Java EE 5)

Business Tier Application Client

And Optional JavaBeans Components

Web Browser, Web Pages, Applets, and Optional JavaBeans Components

Client Tier

Java EE Server

EIS Tier Database and

Legacy Systems Java Persistence Entities Session Beans

Message-Driven Beans

Web Tier Web Pages

Servlets JavaBeens

Components (Optional)

(6)

Design patterns used to build the Business Tier

1. The definition of the Business Tier – a five-

tiered model of logical separation of tasks

2. Basic Business Tier design issues

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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

(12)

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.

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

(13)

Design patterns used to build the Business Tier

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

(14)

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

• Mapping relational model to components model of the Entity component

(15)

Bad practices (2)

• 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

(16)

Bad practices (3)

• 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

(17)

Other bad practices (4)

• 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

(18)

Design patterns used to build the Business Tier

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

(19)

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

(20)

Problem 1 – Conceal from the client program the complexity of remote communication with business service component

Servlets, JSP Client

Business

Delegate 1 Code of Data Database

Access Servlets and JSP presentation

logic and Business Delegate for separating layers but searches of

business services

Session Component with business logic of

services

Logic of Data Acces

Session Component

Client Tier

Servlets, JSP

Business Tier Client

Database

Resource Tier Code of

Data Access

Integration Tier Presentation

Tier

Servlets and JSP with presentation logic and: many searches and calls of business

services, error services of other

layers ect

services

Logic of Data Acces

Session Component

Client Tier

Business Tier

Resource Tier Integration

Tier Presentation

Tier

(21)

Refactorization by using Business Delegate

component

Client

Client and Presentation

Tier

Client and Presentation Tier

Session Component

1

Business Delegate 1

Business Tier Client

Entity

Component 1

Entity Component

2

3

1

2

3 Session

Component 2

Session Component

3

Session Component

1

Session Component

2

Session Component

3

(22)

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

(23)

Implementation of the pattern

• The representative of an intermediary (Proxy Delegate)

• Representative adaptable (Delegate Adapter)

The components of the pattern

• ServiceLocator

• BusinessService

(24)

EJB, JMS components,

or part of SessionFacade pattern

(25)

Business service call

(26)

Business service call and store the business handle

(27)

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

(28)

Problem 2 – Transparent and uniform way to search services and business components Service Locator

Servlets, JSP Client

Service Locator

Database Code of Data

logic and Business Delegate for separating layers and Service Locator for searches of business

services

services Logic of Data Acces

Session Component

Client Tier

Tier Servlets,

JSP Client

Business

Delegate 1 Code of Data Database

logic and Business Delegate for separating layers but searches of

business services

services

Logic of Data Acces

Session Component

Client Tier

Tier

Business Delegate 1

(29)

Requirements

• It should use the JNDI (Java Naming and Directory 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

(30)

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

(31)

Business Delegate, DAO

EJB, JMS components A component or a service of Business or the

Integration Tier: EJB, JMS, DataSource

(32)

Search business services components

(33)

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

(34)

Problem 3 – Sharing components and business services to remote clients (take control of the business objects

and reduce network traffic, or improve efficiency)

Client

Business logic

Component Entity A

Transaction logic

Client or Presentation

Tier

Client

Business logic Session Facade as

Session Facade

Transaction Logic managed by Session

Component, special components

or Contener

Component Entity B

Component Entity C

Client or Presentation

Tier Business Tier

Component Entity A

Component Entity B

Component Entity C

(35)

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

(36)

The components of the pattern

• Client

• SessionFacade

• BusinessComponent

• ApplicationService

• DataAccessObject (DAO)

Implementation of the pattern

• Stateless session component

• Stateful session component

(37)

Business Delegate pattern

(38)

Providing business services to clients by hiding access to business components

(39)

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

(40)

Problem 4 – Centralization of business logic components and business services Application Service

Client and presentation

Session Component

2 Session Component

1

1 Client 1

Client 2

Client 3

Service Application Component

B Service Application Component

A Client 1

Client 2

Client 3

Session Component

3

Session Component

2 Session Component

1

Session Component

3 Entity

Component 2

3

1

2

3 Client and

presentation

(41)

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)

(42)

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

(43)

(44)

(45)

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)

(46)

Problem 5 – The object model is an implementation of the conceptual model as the domain model, containing

relationships and business logic Business Object

Client

Client Tier

Servlets, JSP

Business Tier Client

Code of Access Data Presentation Tier

Business

Delegate 1 Data

Base

Resource Tier Code of

Data Access

Integration Tier Presentation Tier

Servlets and JSP with presentation and small business logic without

consolidation for other clients – small application

Servlets and JSP with presentation logic and controller to separate layers

Session Component with

business logic

Data Acces logic with direct

accesss to databases

Data Base Resource

Tier

Session Component

(47)

(48)

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.

• The object model is an implementation of an abstract model (Domain)

• The data model is used to describe a model of the implementation of such a model ER

(49)

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.

(50)

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)

(51)

a GOF facade

implement their own rules and business logic.

(52)

(53)

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

(54)

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.

(55)

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

(56)

BusinesObject, ApplicationService,

SessionFacade components

Serializable interface

DataAccessObject pattern Business

Delegate

(57)

(58)

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