Telecurs Message

8/11/2019 Telecurs Message

1/14

1. COMMON DEFINITIONS


2/14

2. ARCHITECTURE VIEW POINTS

2.1 BUSINESS ARCHITECTURE

2.2 ONLINE ARCHITECTURE

2.2.1 CONSIDERATIONS

The following are some of the considerations for the online architecture:

a) Service Oriented vs. monolithic:

The architecture will be n-tier where i-th tier provides services to i+1-th tier. Each tier can access theunderlying tier via well-defined interfaces/service points.

b) Conversational vs. Non Conversational Services:

The services offered will be non-conversational. It will be based on request-response model. Oncerequest is serviced, there is no foot print of request on the server. Non-conversational services willmake the architecture scalable.

c) Coarse Grained vs. Fine Grained Server:

Each server will offer a set of services. It should be coarse-grained server and not a fine-grainedserver where it offers one service only. The coarse-grained server is deployed, scheduled by CPUand can be cached when deployed; thus improving the scalability.

Apart from performance benefits, coarse-grained server also helps in de-coupling of clients andserver. As the fine-grained interfaces (services) are exposed through the server to the client, achange to the former will have minimal impact on the client.

d) Modular Design

The product architecture should follow a modular design e.g. Architecture component, businessobject, database calls etc. Each component itself should similarly follow modular design. Each

module should have a clearly defined purpose, provide abstract interfaces (hide implementationdetails) and promote reusability.

The Architecture component will be divided into various sub-components where each sub-componentis providing a well-defined functionality over a well defined interface, e.g.

Controller Protocol Handler Message formatter Security Manager


3/14

Business Object Locator Exception handling

e) Separation of interface and implementers of services.

We envisage the use of inheritance as a mechanism to differentiate SI (System Integration) versionand the product version. Both versions will have the same interface, but the actual implementation willvary. The client of the services will access the operation via interface only.

This applies to all components including architecture, business etc.; all access to the other objects isvia their interfaces only.

f) Usage of Design Patterns

We propose to use the following design patterns at various layers

MVC-2, business object delegate, factory at presentation layer Session Facade, controller, command object, object locator, factory at business layer

g) Others

Messages from one tier to other tier (but for the DB tier) should be application server independentand should be in XML/IIOP objects.

Application server/protocol specific code should be encapsulated in its own classes. Theseclasses should be concrete implementation of abstractions. Caller should use the interfacesprovided by abstractions.

2.2.2 THE ARCHITECTURE

Online Architecture of products is a layered one, with the various layers being:

Browser Layer Presentation Layer

Business Layer DB Layer

Various components at these layers are depicted inFigure 1.


4/14

At the web server layer, MVC2 pattern is used. All the requests from the browser are received

by controller. Controller provides the common functionality needed by each request like

message de-formatting, security, look up for command object. Individual requests are

implemented by command implementers. To decouple controller and request implementers,

command pattern is used.

Figure 1: Components at various layers

Command implementer may need to call business layer to get the data. It uses businessdelegate for the same. To decouple command implementers from nitty-gritty of service calls and

different types of servers, business delegate pattern is used. After getting the data from

business layer, command implementer returns control back to controller. Controller then

forwards the request to view which will generate the page using GUI technologies like JSP/JSF

etc.

Controlle

Request

Implementer

Controlle

BusinessBusiness

Delegate

Data LayerBusiness Logic LayerPresentation la erClient Browser

View Command

Object

Command

Object

forward

execute

forward

uses

execute

forward


5/14

Business delegate calls the server at business layer. The server implements faade pattern and

has two major components: controller & business objects. Controller acts as a central point and

receives all service requests. It reads the message, de-formats the message, looks up for

command objects. Service requests are implemented by business object. To decouple

controller and business objects, command pattern is used. Business objects access DB via

native DB calls.

Presentation Layer

As mentioned above, presentation layer implements MVC2 pattern. The function of various

components at presentation layer is described below.

Controller, at presentation layer, associates with various other objects to provide common

functionalities. The associations between controller and other objects are depicted inFigure 2.

It receives all the requests from browser layer, calls message de-formatter to convert the

message from protocol specific format to language objects. Then it calls security manager to

validate the session. Once request is validated, it calls command object locator. Command

object locator reads the configuration file, instantiates the command objects and returns it to

controller. Controller executes the command.


6/14

Figure 2: Controller and its associated classes at Presentation Layer

Request implementer class can service various requests. These are implemented as fine

grained methods on request implementer class. There will be one command object

corresponding to one request implementer class. Command Object implements an execute

interface that forwards the request to fine grained request implementers.

Request implementer does the actual work for a request. It accesses the application server

layer and gets the data, builds the visual model based on data that will be used by view

component, does page level validations etc. To access application server, it uses business

delegate.

Business delegate, at presentation layer, associates with various other objects to locate the

service provider, format the message and request the service provider for the service. The

associations between business delegate and other objects are depicted in Figure 3. It firstinvokes service locator. Service locator will return application server adaptor object

corresponding to application server that is providing the service. Adaptor encapsulates the

application server specific API for communication and provides a generic interface that business

delegate can call. As described in channel architecture, application server will accepts

message in IIOP/XML format. If application server is accepting messages in XML, adaptor

associates with message formatter to construct a XML for the objects. If application server is

Message

Security

Command

Object Locator

View Object

Locator

Controller associates


7/14

accepting messages in IIOP, message formatter will not be used. Application server adaptor

then communicates with application server in its protocol specific language.

Figure 3: Business delegate and its associates at Presentation Layer

Once command object returns control back to controller, it calls view object locator to find the

next view. View object locator just reads configuration file to find out the class implementing the

view.

View component can be implemented in various technologies. It can be JSF, JSP... Underlying

principle is that there will be various control classes for GUI controls like SLE, combo etc.

These controls will encapsulate the logic for rendering in browser specific language e.g. for

HTML browser, control will output HTML and for hand-held devices it will output WML. Thus a

page is just a collection of these controls. Page generation engine e.g. servlet engine will

instantiate these controls, get the browser specific response and send it back to browser.

Application Server Layer

The server implements faade pattern and has two major components: controller & business

objects.

Message

Service

Application Server

Adaptor/Protocol Handler

Business

Delegate

associates


8/14

Controller at business logic layer associates with other objects to provide common functionality.

These associations are depicted in theFigure 4.

As discussed in channel architecture, application server can listen over IIOP and other protocol.

If server is listening over non-IIOP protocol, request from client will be received by a native

protocol handler. This handler encapsulates protocol and application server specific details,

reads the request and forwards it to controller which is a protocol/application independent.

Figure 4: Controller and its associates at Business Logic Layer

Controller receives all the requests from presentation layer/protocol handler, calls message de-

formatter to convert the message from XML format to language objects. Then it calls security

manager to validate the session and authorize the request. Once request is validated and

authorized, it calls command object locator. Command object locator reads the configuration

file, instantiates the command objects and returns it to controller. Controller executes the

command.

Application Server/

Protocol Handler

Message

(De)formatter

Security

Manager

Controller

Command

Object Locator

forwards

associates


9/14

Business objects publish various methods. These methods implement business logic.

Corresponding to each business object, there is one command object. Command object

implements the execute interface. This is a coarse grained interface. It instantiates business

object and invokes the fine grained methods. Business method performs the business logic and

returns the result to command object that in turn returns to controller. If needed, controller will

then call message formatter to convert result into XML. Controller will, then, return the responseto presentation layer.

2.2.3 SEQUENCE DIAGRAM

The Figure 5 and Figure 6 portray as to how a typical request for a page from browser is

serviced.


10/14

Response

Create

Instance

Build View

Formatted Msg

Client

Applicat

Server

Specific

calls

Model

Execute

Call

Deformatted

Msg

Return

Response

Return Command Object

Create

Instance

Format Msg

Server

Adaptor Object

Locate command

Object

Authenticate

the request

Call

Service

with

objects in

Native

Format

Locate

Service

Authenticated

Request

Message as

Objects

Deformat

Msg

Message

(De)Format

ter

Security

Manager

Message

Deformatter

ControllerBusiness

Delegate

Service

Locator

Applicatio

n Server

Adapter

Command

Object

Request

Command

Object

LocatorView


11/14

Figure 5: Sequence Diagram - Presentation Layer


12/14

Format Message

Authenticate

the re uest

DeformatRe uest

Request

Authenticated Request

Controller

Msg as

vector of

SecurityMessage

Command

Object

Locate Command object

Business

ObjectMessage

CreateInstance

Return Command Object

Response

Command

Object

Execute Create

Call

Method

Business

Object

Response Objects

Formatted Message

A

A

Figure 6: Sequence Diagram - Business Layer


13/14

2.3 CHANNEL ARCHITECTURE

2.3.1 CONSIDERATIONS

The following are some of the considerations for the Channel Architecture:

a) Native Message format: Objects vs XML

Native message format defines the format in which the online application server accepts

service requests from GUI clients. Since online server implements a session faade, its

interface will be generic for clients. Options for generic interface are

Vector of IIOP Objects for input and output. XML for input and output.

If application server supports IIOP, then to increase the performance for IIOP clients sitting

in the same application server process space, it is recommended to go by option one. For

other clients, there will be a std. XML in SOA format only. Channel handlers will convert the

message into IIOP format.

If application server does not support IIOP, then go by option two. It can have native XML

for internal clients and standard XML in SOA format for external clients.

b) Abstraction of protocol specific code

Protocol specific code should be abstracted out in a layer. It should not have footprint all over theplaces. This layer will read the message from a channel, convert the message into standard nativeformat (if needed) and call the lower layers.

c) Abstraction of message (de)formatter code

Conversion of message from XML to objects (or from extraction of objects from vector)

should be abstracted in a layer.


14/14

d) Number of transformations

Keep the number of transformations, which a message has to undergo before the service is invoked,to a maximum of two. The first one being client format (preferably SOA) to standard native formatand second one from standard native format to actual objects implementing the request.

Telecurs Message

Documents

Transcript of Telecurs Message