1.

COMMON DEFINITIONS

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 the
underlying 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. Once
request is serviced, there is no foot print of request on the server. Non-conversational services will
make 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-grained
server where it offers one service only. The coarse-grained server is deployed, scheduled by CPU
and can be cached when deployed; thus improving the scalability.

Apart from performance benefits, coarse-grained server also helps in de-coupling of clients and
server. As the fine-grained interfaces (services) are exposed through the server to the client, a
change 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, business
object, database calls etc. Each component itself should similarly follow modular design. Each
module should have a clearly defined purpose, provide abstract interfaces (hide implementation
details) and promote reusability.

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

 Controller
 Protocol Handler
 Message formatter
 Security Manager
 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) version
and the product version. Both versions will have the same interface, but the actual implementation will
vary. 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 is
via 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 independent
and should be in XML/IIOP objects.

 Application server/protocol specific code should be encapsulated in its own classes. These
classes should be concrete implementation of abstractions. Caller should use the interfaces
provided 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 in Figure 1.

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 business
delegate 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
r
Request
Implementer
Controlle
r
Business
Objects
Business
Delegate

Data Layer








Business Logic Layer
Presentation layer Client Browser
View
Command
Object
Command
Object
forward
s
execute
s
forward
s
uses
execute
s
forward
s
Business delegate calls the server at business layer. The server implements façade 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 in Figure 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.


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 first
invokes 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
Deformatter
Security
Manager
Command
Object Locator
View Object
Locator
Controller
associates
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 façade pattern and has two major components: controller & business
objects.

Message
(De)Formatter
Service
Locator
Application Server
Adaptor/Protocol Handler
Business
Delegate
associates
Controller at business logic layer associates with other objects to provide common functionality.
These associations are depicted in the Figure 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
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 response
to 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.


Response
Create
Instance
Build View
Formatted Msg

Client
Application
Server
Specific
calls
Model
Execute
Call
Service
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

Controller

Business
Delegate

Service
Locator
Applicatio
n Server
Adapter

Command
Object
Request
Command
Object
Locator

View
A
Figure 5: Sequence Diagram - Presentation Layer

Format Message
Authenticate
the request
Deformat
Request

Request
Authenticated Request

Controller
Msg as
vector of
Objects

Security
Manager

Message
Deformatter
Command
Object
Locator
Locate Command object
Business
Object

Message
Formatter
Create
Instance
Return Command Object
Response
Command
Object
Execute Create
Instance
Call
Method
Business
Object
Response Objects

Formatted Message
A
A
Figure 6: Sequence Diagram - Business Layer
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 façade, 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 the
places. This layer will read the message from a channel, convert the message into standard native
format (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.

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 format
and second one from standard native format to actual objects implementing the request.