architecture design document v0[1].2

8/11/2019 Architecture Design Document v0[1].2

1/62

TCS PRODUCTS

TCS PRODUCTS

Version 0.2

Aug 2006

Copyright TCS

Copyright TCS

This is a controlled document. Unauthorised access, copying or replication are prohibited. This documentmust not be copied in whole or in parts by any means, without the written permission from TCS.

Beware - This document and its contents are intended exclusively for the information of the addressees and

do not wholly or in part constitute or contain a legally binding statement or commitment.


2/62

!"###$%&.doc TCS 'roducts

TABLE O CO!TE!TS

". #!TRODUCT#O!.....................................................................................................................................4

2. CO$$O! DE#!#T#O!S.......................................................................................................................5

%. ARCTECTURE V#E' PO#!TS..........................................................................................................6

(.$ BUS)*+SSC)T+CTU+..................................................................................................................6(. /*0)*+C)T+CTU+.....................................................................................................................6(.( C**+0C)T+CTU+................................................................................................................14(.! 1+'0/23+*TC)T+CTU+......................................................................................................... 16(." )*T+4C+C)T+CTU+.............................................................................................................. 20(.5 BTCC)T+CTU+..................................................................................................................... 20(.% +'/TC)T+CTU+...................................................................................................................21

(. DEVELOP$E!T PROCESS...............................................................................................................22

!.$ 1+6+0/'3+*T3+T/1/0/72....................................................................................................... 22!. 1+6+0/'3+*TT//0-S+T................................................................................................................22!.( 1+6+0/'3+*T+*6)/*3+*T.........................................................................................................23

). ARCTECTURE OB*ECT#VES.........................................................................................................24

".$ +8T+*S)B)0)T29 C/*4)7UB)0)T2....................................................................................................24". USB)0)T2.........................................................................................................................................25".( SC0B)0)T2.....................................................................................................................................25".! 3/1U0)T2.................................................................................................................................... 25

6. SPEC##C CO!CEPTS........................................................................................................................ 26

5.$ 3U0T)+*T)T2....................................................................................................................................265. 3U0T)-0*7U7+............................................................................................................................. 305.( '3+T+):T)/*..........................................................................................................................315.! U0+3*7+.............................................................................................................................. 325." /1SSU''/T..................................................................................................................................33

5.5 U1)T)*7..........................................................................................................................................355.% +8C+'T)/**10)*7......................................................................................................................365.; 0+T*1*/T)4)CT)/*.................................................................................................................375.& S+CU)T23*7+3+*T..................................................................................................................395.$# CC+3*7+.........................................................................................................................415.$$ '+4/3*C+/)+*T+1'TT+*S...........................................................................................425.$


3/62


TABLE O #,URES

4)7U+$@ C/3'/*+*TST6)/US02+S........................................................................................;4)7U+@ C/*T/00+*1)TSSS/C)T+1C0SS+ST'+S+*TT)/*02+......................................&4)7U+(@ BUS)*+SS1+0+7T+*1)TSSS/C)T+ST'+S+*TT)/*02+.......................................$#

4)7U+!@ C/*T/00+*1)TSSS/C)T+STBUS)*+SS0/7)C02+...............................................$$4)7U+"@ S+>U+*C+1)73- '+S+*TT)/*02+......................................................................$4)7U+%@ /*0)*+C**+0C)T+CTU+.......................................................................................$"4)7U+;@ S)*70+39C1+'0/23+*T3/1+0.......................................................................................$%4)7U+&@ S+'T+


4/62


". #!TRODUCT#O!

This document describes the

pplication architecture, technical architecture

1evelopment tool-set, deployment A execution architecture

)nteroperability architecture

Common design approaches A strategies

6ision for S/

The document lays down the technical A design approaches finalied for the 'roductsD. 3any of theseaspects shall be further crystallied EseparatelyF as design-reGuirements.

The intended audience of this document is the 'roduct teams.

The document is organied as follows@-

Chapter $- " 1escribes the scope of this document, overview of architecture,design obHectives and considerations.

Chapter 5 ? & 1escribes the individual components

Chapter $# 0ays the vision for S/

Copyright TCS Confidential Page 4 of 62


5/62


2. CO$$O! DE#!#T#O!S



6/62


%. ARCTECTURE V#E' PO#!TS

%." BUS#!ESS ARCTECTURE

%.2 O!L#!E ARCTECTURE

%.2." CO!S#DERAT#O!S

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

aF Service /riented vs. monolithic@

The architecture will be n-tier where i-th tier provides services to iI$-th tier. +ach tier can access theunderlying tier via well-defined interfaces9service points.

bF Conversational vs. *on Conversational Services@

The services offered will be non-conversational. )t will be based on reGuest-response model. /ncereGuest is serviced, there is no foot print of reGuest on the server. *on-conversational services will maJethe architecture scalable.

cF Coarse 7rained vs. 4ine 7rained Server@

+ach server will offer a set of services. )t should be coarse-grained server and not a fine-grained serverwhere it offers one service only. The coarse-grained server is deployed, scheduled by C'U and can be

cached when deployedK thus improving the scalability.

part from performance benefits, coarse-grained server also helps in de-coupling of clients and server.s the fine-grained interfaces EservicesF are exposed through the server to the client, a change to theformer will have minimal impact on the client.

dF 3odular 1esign

The product architecture should follow a modular design e.g. rchitecture component, business obHect,database calls etc. +ach component itself should similarly follow modular design. +ach module shouldhave a clearly defined purpose, provide abstract interfaces Ehide implementation detailsF and promotereusability.

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

Controller

'rotocol andler

3essage formatter

Security 3anager

Business /bHect 0ocator

+xception handling

eF Separation of interface and implementers of services.



7/62



8/62


igure "1 Coponents 3t 43rious 53yers

Command implementer may need to call business layer to get the data. )t uses business delegate for thesame. To decouple command implementers from nitty-gritty of service calls and different types of servers,business delegate pattern is used. fter getting the data from business layer, command implementer returnscontrol bacJ to controller. Controller then forwards the reGuest to view which will generate the page using 7U)technologies liJe LS'9LS4 etc.

Business delegate calls the server at business layer. The server implements faMade pattern and has two maHorcomponents@ controller A business obHects. Controller acts as a central point and receives all service reGuests.)t reads the message, de-formats the message, looJs up for command obHects. Service reGuests areimplemented by business obHect. To decouple controller and business obHects, command pattern is used.Business obHects access 1B via native 1B calls.

'resentation 0ayer

s mentioned above, presentation layer implements 36C pattern. The function of various components atpresentation layer is described below.Controller, at presentation layer, associates with various other obHects to provide common functionalities. Theassociations between controller and other obHects are depicted in 4igure . )t receives all the reGuests frombrowser layer, calls message de-formatter to convert the message from protocol specific format to languageobHects. Then it calls security manager to validate the session. /nce reGuest is validated, it calls commandobHect locator. Command obHect locator reads the configuration file, instantiates the command obHects andreturns it to controller. Controller executes the command.


Controller

e!"e#t

$%ple%enter

Controller

&"#ine##

'()e*t#&"#ine##

+elegate

+ata ,ayer&"#ine## ,ogi* ,ayerPre#entation layerClient &ro-#er

ie- Co%%and'()e*t

Co%%and

'()e*t

for-ard# e/e*"te#

for-ard#

"#e#

e/e*"te#

for-ard#


9/62


igure 21 Contro55er 3n its 3sso7i3te 753sses 3t Present3tion L3yer

eGuest implementer class can service various reGuests. These are implemented as fine grained methods onreGuest implementer class. There will be one command obHect corresponding to one reGuest implementerclass. Command /bHect implements an execute interface that forwards the reGuest to fine grained reGuestimplementers.

eGuest implementer does the actual worJ for a reGuest. )t accesses the application server layer and gets thedata, 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 obHects to locate the service provider,format the message and reGuest the service provider for the service. The associations between businessdelegate and other obHects are depicted in 4igure (. )t first invoJes service locator. Service locator will returnapplication server adaptor obHect corresponding to application server that is providing the service. daptorencapsulates the application server specific ') for communication and provides a generic interface thatbusiness delegate can call. s described in channel architecture, application server will accepts message in))/'9830 format. )f application server is accepting messages in 830, adaptor associates with messageformatter to construct a 830 for the obHects. )f application server is accepting messages in ))/', messageformatter will not be used. pplication server adaptor then communicates with application server in its protocolspecific language.


e##age

+efor%atter

Se*"rity

anager

Co%%and

'()e*t ,o*ator

ie- '()e*t

,o*ator

Controller a##o*iate#


10/62


igure %1 Business e5eg3te 3n its 3sso7i3tes 3t Present3tion L3yer

/nce command obHect returns control bacJ to controller, it calls view obHect locator to find the next view. 6iewobHect locator Hust reads configuration file to find out the class implementing the view.

6iew component can be implemented in various technologies. )t can be LS4, LS'... Underlying principle isthat there will be various control classes for 7U) controls liJe S0+, combo etc. These controls willencapsulate the logic for rendering in browser specific language e.g. for T30 browser, control will outputT30 and for hand-held devices it will output


11/62


igure (1 Contro55er 3n its 3sso7i3tes 3t Business Logi7 L3yer

Controller receives all the reGuests from presentation layer9protocol handler, calls message de-formatter toconvert the message from 830 format to language obHects. Then it calls security manager to validate thesession and authorie the reGuest. /nce reGuest is validated and authoried, it calls command obHect locator.Command obHect locator reads the configuration file, instantiates the command obHects and returns it tocontroller. Controller executes the command.

Business obHects publish various methods. These methods implement business logic. Corresponding to eachbusiness obHect, there is one command obHect. Command obHect implements the execute interface. This is acoarse grained interface. )t instantiates business obHect and invoJes the fine grained methods. Businessmethod performs the business logic and returns the result to command obHect that in turn returns to controller.)f needed, controller will then call message formatter to convert result into 830. Controller will, then, return theresponse to presentation layer.

%.2.% SE8UE!CE D#A,RA$

The 4igure "and 4igure 5portray as to how a typical reGuest for a page from browser is serviced.


ppli*ation Serer

Proto*ol andler

e##age

+efor%atter

Se*"rityanager

Controller

Co%%and

'()e*t

,o*ator

for-ard#

a##o*iate#


12/62


igure )1 Se9uen7e Di3gr3 : Present3tion L3yer


e#pon#e

Create

$n#tan*e

&"ild ie-

or%atted #g

Client

ppli*atio

n Serer

Spe*ifi*

*all#

odel

/e*"te

Call

Seri*e

+efor%atted

#g

et"rn

e#pon#e

et"rn Co%%and '()e*t

Create

$n#tan*e

or%at #g

Sererdaptor '()e*t

,o*ate *o%%and

'()e*t

"thenti*ate

the re!"e#t

Call

Seri*e

-ith

o()e*t# in

atie

or%at

,o*ate

Seri*e

"thenti*ated

e!"e#t

e##age a#

'()e*t#

+efor%at#g

Message

(De)Forma

tter

Security

Manager

Message

Deformatter

Controller Business

Delegate

Serice

!ocator

"##licatio

n Serer

"$a#ter

Comman$

%&'ect

e!"e#t

Comman$

%&'ect!ocator

ie


13/62


6* Se+uence Diagram , Business !ayer


"thenti*ate

the re!"e#t

+efor%at

e!"e#te!"e#t

"thenti*ated e!"e#t

Controller

#g a#

e*tor of

'()e*t#

Security

Manager

Message

Deformatter

Comman$%&'ect

!ocator

,o*ate Co%%and o()e*t

Business

%&'ect Message

Formatter

Create

$n#tan*eet"rn Co%%and '()e*t

Comman$

%&'ect

/e*"te Create

$n#tan*e

&"#ine##


14/62


%.% C&A!!EL ARCTECTURE

%.%." CO!S#DERAT#O!S

The following are some of the considerations for the Channel rchitecture@

aF *ative 3essage format@ /bHects vs 830

*ative message format defines the format in which the online application server accepts service reGuestsfrom 7U) clients. Since online server implements a session faMade, its interface will be generic for clients./ptions for generic interface are

6ector of ))/' /bHects for input and output.

830 for input and output.

)f application server supports ))/', then to increase the performance for ))/' clients sitting in the same

application server process space, it is recommended to go by option one. 4or other clients, there will be astd. 830 in S/ format only. Channel handlers will convert the message into ))/' format.

)f application server does not support ))/', then go by option two. )t can have native 830 for internalclients and standard 830 in S/ format for external clients.

bF bstraction of protocol specific code

'rotocol specific code should be abstracted out in a layer. )t should not have footprint all over the places.This layer will read the message from a channel, convert the message into standard native format EifneededF and call the lower layers.

cF bstraction of message EdeFformatter code

Conversion of message from 830 to obHects Eor from extraction of obHects from vectorF should beabstracted in a layer.

dF *umber of transformations

=eep the number of transformations, which a message has to undergo before the service is invoJed, to amaximum of two. The first one being client format Epreferably S/F to standard native format and secondone from standard native format to actual obHects implementing the reGuest.

%.%.2 T&E ARCTECTURE

The 4igure % depicts the channel architecture. pplication server can be capable of listening to more than oneprotocol. The protocol, which presentation layer uses to talJ to application server, will be referred to as nativeprotocol.

*ative message format defines the format in which the online application server accepts service reGuests frompresentation layer. Two message formats will be supported@ native message format Ee.g. vector of ))/'obHectsF and 830 conforming to S/ standard.

)n summary, 7U) clients will talJ to server in native format and in native protocol. Clients wanting to use non-native protocol will always use S/ 830.

There will be a channel handler for each type of non native protocol. )t associates with the protocol handler forthe reGuired protocol. 'rotocol handler reads the message using protocol specific ') and sends the messagebacJ to channel handler. Channel handler then associates with message converter to convert message to


or%at e##agee#pon#e

Call

ethod

e#pon#e '()e*t#

or%atted e##age


15/62


native format. Channel handler sends the message to controller at application server layer directly or vianative protocol handler. Controller publishes two interfaces@ one for native message format and one for 830.

)n the 4igure %, client $ and client are sending message over non-native protocol while client ( and client !are sending messages in native protocol. )f a client Ee.g. Client F needs to use a non-native protocol andapplication server supports this non-native protocol, channel handler will reside inside the application server.)n this case channel handler sends message to controller directly.

/n the other hand, if application server does not support the protocol that client wish to talJ over, either wedeploy channel handler over another application server that supports the reGuired protocol or we need to builda channel listener and a scalability mechanism for channel handler. )n this case channel handler sends thismessage to application server via native protocol. Client $ depicts this situation.

Client ( and client ! talJ to application server over native protocol. Client ( is sending messages in nativeformat and client ! is sending messages in ST1 830 format. Controller may associate with appropriatemessage de-formatter to convert message into application obHects.

igure +1 On5ine Ch3nne5 Ar7hite7ture


e##age in ST+

:, for%at oer

natie proto*ol

Controller

e##age oer $$'Pproto*ol

e##age in ST+:, oer nonnatie proto*ol

e##age oeratie proto*ol in

natie for%at

e##age in natie

for%at oer natie

proto*ole##age in ST+:, oer nonnatie proto*ol

atie Proto*ol andler

for on $$'P %#g# only

ST+ :, $nterfa*e

natie for%at*onerter

atie for%at $nterfa*e

natie for%at *onerter

e##age oer $$'Pproto*ol

"##lication Serer

Channelandler

C-annel an$ler "## Serer

Client / Client 4 Client 2 Client

Channel andler

on;atie Proto*ol andler

:, to natie for%at *onerter

e##age +e or%atter


16/62


%.( DEPLO;$E!T ARCTECTURE

%.(." CO!S#DERAT#O!S

The following are some of the considerations for the 1eployment rchitecture@

aF Scalability


17/62


18/62


Serer Serer &

igure 1 Sep3r3te 'e= ser4er ep5oyent oe5

cF


19/62


igure "01 Verti735 S735ing Dep5oyent $oe5

)f application server and web container are in different address spaces, application servers also forma different cluster. Some application server liJe web sphere taJe the responsibility of synchroniationbetween various instances, while others liJe pache do not. )n these cases, application needs tosynchronie the session state. TCS 'roducts will go for shared cache or 1B based synchroniation.s the session is synchronied, any application server can service the reGuest from web container.

dF


20/62


igure ""1 &ori>ont35 ? Verti735 S735ing Dep5oyent $oe5

$.


21/62


%. ow does the architecture provide for the capability to run different batch schedules for instances indifferent time onesN

;. ow is the productPs availability assured as !x% N

%.+ REPORT ARCTECTURE

$.


22/62


(. DEVELOP$E!T PROCESS

(." DEVELOP$E!T $ET&ODOLO,;

The methodology shall follow the following phases broadly@

S. !o. Ph3se De5i4er3=5e

$F Scope 1efinition eGuirements 1atabase

F Business 'rocess 1esign 'rocess 3odel

'rocess 1escription

nalysis Class 3odel

(F Component 1esign Class 3odel

SeGuence 1iagram

Class specifications

U) specifications

eport specifications

rchitecture changes

'rototype

!F Component +ngineering >'', U), eport

Test 'lan, Test Cases, Test 1ata, egressionscripts

Test esults

)nstallation scripts

Service repository

'' 3asterCraft



23/62


S. !o. De5i4er3=5e Too5

%F U) L7

;F eport

&F Test 'lan, Test Cases,Test 1ata, egressionScripts

$#F Test esults

$$F )nstallation Scripts

$F Service epository

4./ DEVELOP$E!T E!V#RO!$E!T


24/62


). ARCTECTURE OB*ECT#VES

)." E@TE!S#B#L#T; < CO!#,URAB#L#T;

)t is the ability of the product to allow for extending and configuring while preserving the core of the product.

The architecture of the product needs to support such extensions Eor reductionsF on user interface, servicesand9or database.

The various scenarios and the options available are discussed below. This section provides guidance andinputs to the design of the architecture itself.

aF e-arranging fields on a U)

The user-interface provides the visual representation of the product and also embodies the brand of thecustomer. )t is expected that the style-sheet, layout, etc. shall undergo customiation for eachimplementation. Such changes that are localied to style-sheet and9or re-arrangement of the fields wouldbe supported by the U) tool ? by providing a simple interface EliJe +xcelF.

bF e-organiing multiple U)Ps, the U) flow

re-organiation of U)Ps and the associated flow brings in a need for a 'rocess 4low 3anager E'43F thatde-couples the U) from the underlying business services. Such a '43 Ein this contextF would need to@

3anage the flow from U) to the business service

3anage the context of the business process

This, combined with the U)-tool would provide the support for the changes in U) within the followingconstraints@

The business services are not changed, including its signature

The U) adheres to the interfacing needs of the process flow manager

cF Changing a business service

The options for enabling such a need include obHect inheritance and provision of user-exits. )n the initialphase, the service design shall provide for user-exits.

dF Changing the process flow, replacing a service

Such a need shall be catered through a process flow manager. 4or more discussion on this topic, pleaserefer to the S/ 6isionD chapter.

eF ltering the data model

This would include the need for@

dding 9 emoving one or more attributes

dding 9 emoving one or more tables

Such a need has to be addressed within the following constraints@

The codeD is not a deliverable and hence not available with the System )ntegrator 9 Customer

The changes to the business service, U) and the flow needs to be isolated and Jept as

extension-JitsD ? i.e. separate from the core product

The analysis and design for this reGuirement is still pending.

)t is expected that the application development tool-Jit provides for the above extensibility needs, whileassuring consistency in the business process A data.



25/62


).2 USAB#L#T;

Usability is a Guality measure of the efficiency with which a user can perform reGuired tasJs with the product.Usability can be measured obHectively via performance errors and productivity, and subHectively via userpreferences and interface characteristics.


26/62


6. SPEC##C CO!CEPTS

This section explores some of the Jey concepts used for defining the architecture of our next generationproducts 9 solutions.

6." $ULT# E!T#T;

The architecture needs to support an autonomous, yet combined view of business entities to enable businessto maJe decisions that impact the entire enterprise. 3ulti-entity banJing enables centralied integration andconsolidation resulting in increased productivity and reduced operational costs ? at the same time allowing forthe identity of an individual entity.

ey e3tures

The specific features to be supported include the following@

4lexible entity definitions that match the business organiation

Shared data across all entities ? ability to distinguish between centralied vs. localied data

3anaged data on a centralied or decentralied basis

+ntity specific system tailoring capabilities

4ull security within and across entities

+ntity specific reporting

utomatic inter-entity eliminations for consolidated accounting 9 reporting

Centralied or decentralied deployment

Time-one management

s value added services, the product must transparently handle inter-entity transactions and generate

booJings for each entity involved in the transaction

Appro37h

To support multi entity, the organiations operations profile will need to be captured into the system. 4or thispurpose, the concept of /perational Unit and /rganiation 7roup will be used.



27/62


igure "21 $u5ti Entity $oe5 : A 7on7ept

Operational Unit (OU)@ n /rganiation group can encompass one or more entity. The criteria for setting upan /perational Unit will be extensible and will include parameters liJe, entity, depot, event type, security typeetc. 3ultiple values will be supported for these parameters e.g., one or more than one entity, depot can becombined to setup an /U.

These units will provide visibility restrictions EimplicitF in the system. These visibility restrictions will be definedbased on a set of parameters and will be configurable at the time of the implementation of the system.

Organization Group (OG):ny number of operational groups can be setup within an operation unit. n /7will have users associated with the group. n /7 can have a manager.


28/62


igure "%1 User 5e4e5s in 3 $u5ti Entity $oe5

Consier3tions or A77ess Pri4i5eges

4ollowing considerations will define the access privileges for the users of the system@

+very data is owned by an entity. This implies that each table in the system stores the entity id of the

entity to which the data belongs.

ules will be built based on the type of the data, userPs access privilege and the organiation structure

to define the access privileges for the users.

The users have defined functional access within the system. The functional access is defined by theroles setup in the system. Users are linJed to roles to define their functional profile.

ll data access through the system is restricted as per the data access profiles defined in the system.

Users are linJed to the data access profile to define their access privileges.

Users can be linJed at any level in the hierarchy e.g., the operational group 9 operational unit.

O/perational UnitP defines the data access scope of the user setup at the /perational Unit level in the

system. These are EimplicitF data access ruled built into the system at the implementation time basedon configurable parameters.

Users defined at the /peration Unit level, can have data update access to the data which is common

to the entire operational unit. Users defined at the global 9 system level can have data update access

to the data that is common to the entire system. The access privilege of an individual user is as perthe userPs role profile 9 data access profile setup in the system.

User creation and role assignment rules are flexible. Users can belong to multiple /perational groups

and have different role profiles in associated /Us.

/nce logged-in the users can switch between the associated operations units.

eports can be generated at all levels e.g., /perational Unit, /perational 7roup, System 9 7lobal

level etc.

App5i73tion P3rtitioning or Oper3tions ? Peror3n7e

4or day-to-day operations liJe batch processing etc., a number of operational units can be linJed to form an

pplication 'artition. +ach pplication 'artition can have its own batch cycle and business date. Theimplementation of the pplication 'artition in effect is the same as different banJs defined within the system 9banJ where the system is implemented.


$ULT# E!T#T; $ODEL

Syste

/perationalUnit (

/perationalUnit $

/perationalUnit

/7 $ /7 /7 ( /7 !

System9 7lobal 0evelUsers

'rocesses9 1ata applicableat System 0evel

/perational Unit 0evelUsers

'rocess91ata applicable at

/U 0evel

/perational 7roup0evel Users

'rocess91ata applicable at

/7 0evel


29/62


igure "(1 App5i73tion P3rtitioning

4or performance reasons, database will be partitioned. +ach pplication 'artition will have multiple tablespaces partitions for the important tables. 4or example, if the processing of the application is based on +vent)1 then, all critical tables will be table space partitioned on pplication 'artition id and the range of +vent )de.g., pplication 'artition )d R EUS )ncome and US *on-)ncomeF and +vent )d ange E ########$ ?

+&&&&&&&&&F. The leading character of the event id E, B, CF will provide flexibility in terms of the number oftable space partitions.

batch program running in an application partition will thus be multithreaded and each sub process will beworJing on a range of event ids which corresponds to table space partitions. This will avoid contention acrosspages and true benefits of partitioning will be realied with flexibility.

igure ")1 $u5ti Thre3ing ? P3rtitioning


19.

'perational =nit

'perational >ro"p

'perational =nit'perational =nit

'perational >ro"p 'perational >ro"p 'perational >ro"p 'perational >ro"p 'perational >ro"p

ppli*ation

Partitionppli*ation

Partition

ppli*ation

Partitionppli*ation

Partition

"ltithreaded

Pro*e##

"ltithreaded

Pro*e##

Ta(le #pa*e

Partition#

Ta(le #pa*e

Partition#

'perational >ro"p * Base$ %n* Functional "rea3 Brea ueue For 1orflo

'perational =nit * Base$ %n* ntity3 De#ot3 ent ty#e etcppli*ation

Partitionppli*ation

Partition* Base$ %n* %#erational 7nits -aing common Business $ate an$ B%D%D

+&

&at*hController

&at*hntitle%entThread;1

&at*hntitle%entThread;2

&at*hntitle%entThread;n

Ta(le Spa*e 1 Partition 1






Ta(le Spa*e nPartition 1

Ta(le Spa*e n Partition 2

Ta(le Spa*e n Partition 3


30/62


6.2 $ULT#:LA!,UA,E

The rchitecture needs to support multi-lingual capability for the end user profile. )t should be Unicodecompliant and support multiple languages for the user-interface based on the locale and user-preferences.

)nternationaliation support of user interface and messages will be provided whereby static information isserved to the user on the screens using various 7U) elements such as 4ield 0abels, Table column headers,button names, tool tips, inbuilt application messages liJe errors, warnings in the language of choice for theuser.

)nternationaliation will also be supported for text entry in certain blocJs of the screen. These texts will bedisplayed in the language in which they have been entered.

User Interface

The implementation will be Unicode compliant and support multiple languages for the user-interface based onthe locale and user-preferences. 4ollowing are the three Jey considerations for presenting the text in non-+nglish languages@

$. The document is delivered in the desired natural language Esuch as +nglish, 4rench, etc.F and dialectEUS, British, etc.F. The document is presented in the correct character set. This is a reGuirement for most +astern

languages Eussian, Lapanese, etc.F.

(. The document is presented in the correct directionality. This is a consideration for languages such asebrew, rabic, Lapanese that are customarily written right-to-left or top-to-bottom.

3essages and other textual information can be localied by using the standard Hava i$;n techniGue ofexternaliing it to .propertiesD files wherein the information is associated to Jeys and the application uses onlythese Jeys to refer to it. lternatively, multiple web-sites will be created from the single code-base to supportthe various languages reGuired.

4or representing the text flow correctly, one needs to Jnow three things@

igure "61 Tet 5o Represent3tion

which way the text flows within a line Einline progressionF which way the lines stacJ EblocJ progressionF

which way the glyphs are facing Eglyph orientationF

owever, not all combinations of text direction and glyph orientation are valid. Therefore if certain charactersinherent characteristics are Jnown, it is often possible to derive one from the other. Unicode systems taJeadvantage of this model in horiontal text.

The Unicode specification assigns directionality to characters and defines a EcomplexF algorithm fordetermining the proper directionality of text. Unicode supports assigning an inherent directionality, whetherleft-to-right EltrF or right-to-left ErtlF, to characters which are evidently a part of a directional script. /ther

characters however have neutral directionality, and their behavior is meant to be dependent on their context inrelation to other characters.



31/62


T30 offers higher-level marJup constructs that do the same thing Ethe dirattributeF. This can be used todisplay the text in the correct directionality.

Data & Reports

ll databases provide support for )nternationaliation 9 Unicode. This will be exploited to support data entry inthe language of the userPs choice. 4or this purpose, the system will maintain the language code along withthe data in the database. This field will be used to render the data correctly on the browser at the time of

access.

This will also provide the reGuired support for reports to be generated from the system with the appropriatelanguage specific texts. The static text of the report will be internationalied using the concept of propertyfiles 9 resource bundles as explained above.

6.% PARA$ETER#FAT#O!

/ptimal parameteriation to enable the solution deployment by independent teams, meeting the customerobHectives needs to be provided. This feature will enable single source code maintenance across multiple

implementations and increase the profitability of the solution.Solution customiation, where needed, will be done as per the pre-defined norms, Jnown as extension Jits.

Appro37h

To build-in adaptability 9 specialiation in a component, following process will be followed@

Study the domain and identify commonalities

nticipate typical variations

Build variability points to include the variations

6ariability points should be configurable

Built for typical non-functional scenarios

The parameters will be defined at various levels@

System level

4unctionality-specific

4unction 9 3ethod specific

Syste Le4e5 P3r3eters

System level parameters may be used for application setup 9 configuration. The parameters will be stored inthe database 9 files. These parameters may be cached for performance.

Certain business parameters which affect the overall behavior of the system will also be defined through thesystem level parameters. These parameters will definitely be cached at the appropriate level for optimumperformance. Business components will be designed to worJ in accordance to these parameters.

)mplementation teams can be trained to worJ with these parameters to install 9 tune 9 upgrade the system asmay be reGuired.

un7tion35ity:spe7ii7

These parameters will typically define the business flows 9 process of the system as may be reGuired for aclient 9 implementation. These parameters may be static 9 dynamic in nature.



32/62


The static parameters may be configured in property 9 830 files 9 1B. The dynamic parameters will be definedand managed through the ules 3anager. The ules 3anager will be integrated with the Business 'rocess3anager 9 ueries on ule instances

Caching of ules in conHunction with the Cache 3anager

http://www.w3.org/TR/html401/struct/dirlang.html#adef-dirhttp://www.w3.org/TR/html401/struct/dirlang.html#adef-dir


33/62


ule 3anager should define its own repository for storage of rules. generic table can define and storedifferent rules and their corresponding instances. The individual rules should be maintained using these setsof generic tables and 7U) screens. This maJes the storage and maintenance more generic with easyincorporation of new rules reGuiring no need for new tables and 7U) screens.

Rule Evaluation

The evaluation model should use row-by-row processing against in-memory rule data instead of complex and

costly S>0 Hoins. 0.

Packaging

The ule 3anager frameworJ should be pacJaged as a separate component. )t can also be clubbed with theeference 1ata component.


34/62


Figure 9* %DS Sc-ematic

Pri3ry 3n Se7on3ry D3t3=3se

The transactions from any source Eonline or batchF will worJ on the 'rimary database EtransactionaldatabaseF. This database will be optimied for transactional performance with the database schema orientedas per the system transactions and the data will be Jept to the minimum reGuired for processing thetransactions.

ll data that is not reGuired for the transactions will be moved to secondary database as per the definedfreGuency. This database will be optimied for Gueries and the data schema for this database may be

somewhat different from the primary database to optimie the cost of Gueries. 6iews will be created on thesecondary database to provide support for the typical Gueries.

ueries


35/62


/0 1ow do we make the business ser%i(e layer transparent to the knowledge of where data is) The datamanagement layer needs to en(apsulate this knowledge. ata (an be in primary se(ondary master orar(hi%e.

20 3et us segregate the primary&se(ondary&ar(hi%e and 4S&data warehouse.

!0 The 4S itself will be(ome too broad a topi( for us to support. 'e should support a %iew into the primary ,se(ondary data 5 that (an be utili-ed to populate the 4S. This %iew (an be in terms of a standard (anoni(alform.

#0 The se(ondary database will ha%e the e*a(t same data model as primary but will be tuned for queryperforman(e.

60 There will be a set of data that will relate to master information that will not follow the abo%e s(heme. Su(hdata will only be sent to ar(hi%e based upon rules.

70 The mo%ement from primary to se(ondary needs to follow a set of (onfigurable business rules. This wouldrequire a set of 89 " asso(iated ser%i(es to manage the (onfigurable rules. This would also require a set ofser%i(es to e*e(ute the mo%ement from primary to se(ondary.

0 $%ery produ(t upgrade would need a migration of data for primary se(ondary and master&data.>

Batch programs will be run on the primary 9 secondary database as may be reGuired. 1ata from the secondarydatabase will be fed into the /1S.

)n the schematic above, the /1S is seen to be an architectural structure that is fed by integration andtransformation Ei9tF programs. These i9t programs can be the same programs as the ones that feed the datawarehouse or they can be separate programs. The /1S, in turn, feeds data to the data warehouse.

This approach will allow for easy integration with other applications. The specific features that will besupported by this approach are as follows@

)ntegrate data from multiple sources to facilitate operations, analysis and reporting

Cleaning, redundancy resolution and business rule enforcement of the data from various sources

Support the dual role played by the /1S@ /perational with high response time and high availabilityKintegrated, subHect oriented, supporting decision support processing.

*ew releases of the system impacting the primary database will potentially have an impact on the secondarydatabase as well. This means that the secondary database may need to be upgraded each time there is achange in the primary database. The /1S will be a de-normalied complex structure that will be evolved fromthe rich and varied experiences of our product implementations. This database structure will not be directlyimpacted by the schema changes in the primary database.

eports may be generated from the Secondary 1atabase or the /1S as may be reGuired.

Ar7hi435 < D3t3 '3rehouse

1ata from the /1S will be fed into the rchival 9 1ata warehouse. The archival approach of the banJ at whichthe system is being implemented will define the archival policies 9 processes.



36/62


)n general, rchival rules 9 policies will be defined for each business component of the system. These ruleswill be configurable as they will be based on parameters liJe, creation date, status etc. The relevant data willbe archived as per these rules from the /1S using the banJPs archival frameworJ. The frameworJ will supportfor the archived data to be retrieved for Gueries Eonline viewingF 9 reporting purposes. The /1S structure andassociated processes will provide the relevant information for the same. The access to the archived databasewill be governed by the organiations data access restrictions for archived data.

/ne approach for rchival 9 etrieval is as given in the figure below.

igure "-1 Ar7hi435 < Retrie435 option

The approach for /1S given above allows for seamless integration with the organiationPs data archival 9 dataware-housing policies. ny third-party tool may be utilied for the same.

6.6 AUD#T#!,

6arada@$. uditing is at two levels@ class and transaction. Table is a physical realiation of the class. /ne class,theoretically can be implemented as one or more tables.. U) needs to be presented to allow for configuration of the auditing. This should present all the transactionsand all the classes that are auditable. The configuration would include@ choice of class9transaction, choice offull image or selective information. ccordingly, rules 9 configuration file needs to be created that are utilied atrun-time for auditing.(. ) need a seGuence diagram9flow diagram showing the execution of a transaction, and the point at which thisdecision on auditing is done.!. +very transaction shall be assigned a uniGue number ? irrespective of whether an audit is reGuired or not.". )f a class is chosen for audit, the associated transaction number shall also be logged.5. The audit table will be constructed as a name-value pair for each field. Thus, a generic view into the audit

table can be provided that can show all the fields in a pre-structured fashion.uditing is done to store the details of operation on a table, as well as the impacted data into the audit trailtable. udit trail is a process, which is specific to each component.

e3tures1

The following details should be captured in the audit trial table

Time of creation of audit information or record

=ey 4ield value of the data row changed

*ame of the Table on which change has taJen place

User who changed the data Efrom online screenF or program id Ein case of batch programF Type of Change Edd, 3odify or 1eleteF

're )mage EThis is the image of the row before the changeF



37/62


'ost )mage EThis is the image of the row after the changeF

bility to generate reports

udit Trail eports should give the facilities for online as well as batch reports

uditing should be done in a manner that will tie the changes to table rows with the business transactions thathave resulted in such changes.


38/62


39/62


3ails

S3S

'agers

1ashboards

TicJers

Third-party monitoring tools

Appro37h

The lerts and *otifications can be setup to individual users 9 groups can be setup based on the businessevent defined in the system. The approach for the same is as defined below.

E4ent DeinitionH su=s7ription 3n es7353tion

Business events in a system will be captured in the lerts and *otification component. 1eal Creation, 1eal+xecution, ccount Credit and 1eal 'ending for authoriation are some examples of business event. Thefacility will be configurable to send messages to individual user, group of users or to all the users of thesystem Ebroadcast messages for system availability notifications, new product releasesF based on the event.

4or this purpose, each event is classified into three types@

3andatory

)ntended subscriber

ll Subscribers

)n mandatory events, alert 9 notification is always generated for the intended user. )n intended subscriber, analert or a notification is generated for the intended users who have subscribed for the event. )n order toreceive alerts 9 notifications for such events, subscription is mandatory. )n all subscribers, all the subscribers ofthat event will receive alerts 9 notifications.

+very business event has a rule associated with it and a rule base to dynamically evaluate the rule./ccurrence of a business event can be checJed by evaluating the rule. 3essage template Ewith place holders

for relevant business informationF is defined for every business event for each dispatch mechanism ES3S, +-mail, 48, and )nternal *otificationF.

+scalation related information will also be defined for an event. )f some alert 9 notification is not responded oracted upon within a predefined 9 configured time, then an alert 9 notification can be sent again to same user 9next level of users. 3any such escalation levels can be defined for an event.

!otii73tion $e7h3nis

lert and *otification engine allows an individual user or a user group to subscribe to a particular set of event.)t also allows the user 9 user group to choose a preferred notification mechanism such as sending an email orS3S for a particular event. The user 9 user group can also define some rules at the time of subscription to theevent. These rules will be evaluated to checJ the occurrence or happening of an event before sending thealert 9 notification to particular user 9 user group.

Triggering o A5erts 3n !otii73tions

This facility will provide for delivery of system Esystem exceptions, technical failures etc.F as well as businessmessages Ee.g., credit to the userPs accountF.

lerts and *otifications can be triggered by various architectural components as part of the process flow.Typical examples are@


40/62


41/62


!. uthoriations will be based upon servicesD Ebusiness transactions I enGuiry transactionsF and itsassociated data-attributes.". +very invocation of service needs to verify that such an invocation is authenticated and is authoried basedupon 4' 9 1'. This verification will again be based upon servicesD and associated data attributes.5. The verification should be the first step in the service, even before any validations.%. 4ailure in the verification should be passed onto the exception handling frameworJ.;. uditing module shall taJe care of determination whether such violations need to be audited.

pplication Security 4rameworJ caters to all security aspects within the application including uthentication,uthoriation, uditing and 0ogging.

e3tures1

The frameworJ should provide 4orm based uthentication. )t should involve the verification of User )1 andpassword during login. Client-certificate based authentication is a more secure method of authentication andshould be supported by the frameworJ.

4or uthoriation purposes the frameworJ should use 4unction ccess 'rofile E4'F and 1ata ccess 'rofileE1'F to provide value based security.

The sections below present the various security features that should be provided by the pplication Security4rameworJ@

AUT&E!T#CAT#O!

ll users are authenticated at the 0ogin screen using the user id and password. ll communication ofpassword details from the browser is passed over $;-bit SS0. ll servlets and LS's checJ for a valid sessionto prevent direct access of the application servlets and LS's. Client-certificate authentication uses TT' overSS0 ETT'SF, in which the server and the client authenticate each other with 'ublic =ey Certificates.

AUT&OR#FAT#O! A!D ACCESS CO!TROL

The frameworJ should use a fine-grained role based model for providing uthoriation and ccess Control. tfunction level every action that a user can perform on any of the components should be captured whilecreating the userPs functional access profile and is verified whenever a user performs an action. 4' refersto one or more roles a user is assigned. 3ultiple oles can be assigned to multiple users. +ach role furthercan have functions 9 entitlements such as 11, 3/1)42, 1+0+T+ etc., defined on a particular component 9screen.

VALUE BASED SECUR#T;

ccess control at data level for value based security can be provided using 1'. 1' would determine thefields on which partitioning of data can be applied. 4or example an +vents Service 0ocation can be a 1'field which would be used to partition data on the basis of +vent Service 0ocations the user has entitlementsfor. This is achieved by 1ata partitioning based on organiational model. This will enable data to be viewedand manipulated by users belonging to a particular organiational unit. 4ollowing diagram shows theentitlement model

User1

User 2

User 3

OU 1

OU 2

OU 3

OU 4

Add

View

Edit

Authorize

Function AccessData Access

User1

User 2

User 3

OU 1

OU 2

OU 3

OU 4

Add

View

Edit

Authorize

Function AccessData Access



42/62


igure 20 Se7urity Set:up =3se on AP


43/62


C5ientC37he

% r P3rty

C37hingr3eorG

D3t3DAO

C37he

1ata ccess

0ogic7et

eGuested

/bHect using

1/

eGuest

Cache /bHect

eturn Cache

/bHect

Create or

retrieve

Cache /bHect

Uses

C5ient C37he$3n3ger

%r

P3rtyC37hing

r3eorG

D3t3Sour7eDAO

C37heO=Ie7tO=Ie7t

C5ientC37he

% r P3rty

C37hingr3eorG

D3t3DAO

C37he

1ata ccess

0ogic7et

eGuested

/bHect using

1/

eGuest

Cache /bHect

eturn Cache

/bHect

Create or

retrieve

Cache /bHect

Uses

C5ient C37he$3n3ger

%r

P3rtyC37hing

r3eorG

D3t3Sour7eDAO

C37heO=Ie7tO=Ie7t

Figure 2* Cac-e Manager

APPROAC&

The Caching frameworJ should be designed in such a manner that a single Cache 3anager classencapsulates all the implementation details of caching, such as the access, creation and destruction ofobHects in the cache from the client components. 3oreover the caching manager should also hide thedetails of (rd party caching ') to be used.

Several obHect-caching frameworJs Eboth open source and commercial implementationsF providedistributed caching in servlet containers and application servers. /SCache from /pen Symphony is a

third party ') that can be used considering the following@

Supported 4eatures EClustering support only available on /SCacheF

'erformance esults ESome published results@ /SCache was twice as fast as LCS and " to $#

percent faster than L/Cache. L/Cache came in second in terms of caching performance.F

/SCache .# supports for clustering of caches. /SCache currently ships with implementations that allowsyou to use either Lava7roups or L3S as the underlying broadcast protocol for clustered cacheimplementation.

6."" PEROR$A!CE OR#E!TED PATTER!S

'erformance needs to be considered and factored into user interfaces, designs, and development processesup front. The success would lie in understanding the usage profile in terms of the number of concurrent users,target response times, usage patterns, and data growth in an obHective and measurable manner.

ere are some L++ specific tips and techniGues for the product design@

Use Stateless Session Beans as far as possible.

The following L++ design patterns can improve performance@

D3t3 Tr3nser O=Ie7tto encapsulate and pass a business obHectPs data attributes to the

presentation tier. educes remote networJ traffic and helps to Jeep a clean separation between LS'sand +LBs.

Ser4i7e Lo73torto cache results of L*1) looJups

V35ue List &3n5erfor Guerying, filtering, large amounts of data

D3t3 A77ess O=Ie7tto provide a simplified interface for performing complex L1BC

operations and to encapsulate data-access logic. llows decoupling of data-access optimiations



44/62


Session 373e1

To group calls to +LBs in a Coarse 7rained )nterface@ to execute complex use cases

in a single networJ call. Use local interfaces for entity beans and any session +LBs that will be collocated

within the same 63. )f +LBs need to be called remotely wrap them with the session facade designpattern to combine methods in order to reduce remote invocations.

To group related entity or 1B updates into single container managed transaction

void usage of +ntity beans

Use S>0L for batch programs as against the use of direct L1BC calls. 0L and L1BC.

un Batch processes in their own L63 as compared to running them in the application server. This

saves the overheads associates with the +LB components.


45/62


+. O!L#!E PRO,RA$ ARCTECTURE

+." DE#!#T#O! A!D RE8U#RE$E!T

/nline program architecture E/0'F defines the seGuence of interactions that taJe place between the

architecture components during an on-line reGuests@ be it through native application user interface or externaluser interface or real-time application-to-application calls. /0' also defines the interface between thesearchitecture components.

/0' supports the following types of user interactions @

Single row inGuiry, in which contents of the response message are normally filled into one screen. Theresponse may be received either from the TCS 'roduct pplication Server,


46/62


@Tum@ This attribute contains the uniGue number assigned to each service reGuest. This

number is generated in the Business Transaction EBTF logic.

Se(urity+lag@ This attribute identifies whether the service reGuest reGuires service authentication

or not. This is used by the BT logic to identify whether to log the service reGuest in 4unctionccess 0og or not when the transaction is committed to the database.

8ser9d

'orkstation9d

Ser%i(e9d =esour(e9d

This obHect need not participate in communication from user front end. This should definitely be part ofcommunication between


47/62


+.%.2 CO$PO!E!T $ESSA,E #!TERACT#O!

This section briefly describes the messages being passed between the various architecture components @

ro C5ient App5i73tion to 'e= Ser4er

Client pplication is responsible for sending the following message obHects. /bHect are .

$. UT)*4/

. pplication 1ata @ ll input obHects reGuired by the


48/62


49/62


'e= Ser4er to User #nter37e

9L3S.

3essage 4ormats@ )t should support proprietary 830 and S/' formats.



50/62


3essage Binding @ )t should support 1ocument based as well as 'C based bindings.

3essage Transformation and mapping.

0imited orchestration capability

+.%.- APPL#CAT#O! SERV#CE

)t refers to all the application Servers which service the business transactions and enGuiry transactions.

+.%. D$ LA;ER

13 0ayer refers to library of database functions. 1atabase functions are defined as class methods. Thesemethods are invoJed by pplication Services.



51/62


-. EA# $A!A,ER

#ntrou7tion1The purpose of the Lava9830 based +nterprise pplication )ntegration E+)FframeworJ is to provide a platform to build flexible adaptors with limited programming effort so thatany B4S) product can interface with the other applications in the enterprise eco-system with which it

needs to exchange data.

Re9uireents1The frameworJ needs to provide the following@

3edia independence via configuration so that different media on which the message comes

can be connected to for reading 9 writing the message. The media could be 3>, 4lat file,T)BC/, L3S, 1B3S etc.

4ormat )ndependence via configuration so that message buffer can be interpreted as per

different formats liJe CS6, fixed width, 830 etc. S


52/62


The frameworJ classes promote Oprogramming to interfacesP concept and can be easily configuredto assemble Lava based adaptors doing necessary transformations at B4S) 'roduct touch pointsThe following are important components of the solution@

daptor@ n adaptor is a set of one or more 'ipelines, although most common adaptors areexpected to consist of a single 'ipeline

'ipeline@ pipeline is a networJ of *odes interconnected to one and another. )t is important to notethat these components are primarily Lavabeans and they can be combined and assembled as perthe Spring frameworJ based on an 830 configuration. The Spring frameworJ uses the principles of

1ependency )nHection and )nversion of Control. Spring frameworJ provides a light weight containerin which these components get OwiredP to each other for running.

*odes@ These are components through which messages pass in a 'ipeline. They receive messagesfrom the Transport, and ultimately pass messages bacJ to the transport for further propagationthrough the 'ipeline. ll *odes may have an embedded 'rocessor whose function is to manipulatedata Eas ecordsF as it passes through the nodes. special boundary *odes Ei.e. )npoints and/utpointsF will also have a configured Connector. The Connectors connect to external sources ofdata for the 'ipeline. 1ata is read by the Connectors Eas an array of ecordsF, and is pacJaged intoa 3essageContext. 4inally, the 3essageContext is passed to the Transport for delivery to other*odes within the daptor. daptor /utpoints are *odes where messages terminate


53/62


54/62


55/62


56/62


57/62


.2 SOA / A! ECO:S;STE$ OR TCS PRODUCTS

TCS B4S) products needs to be analyed and architect on the service based design. Some of the productsliJe >uart do have the basic elements of service based design, which is the most important aspect for S/enabling. )t should be possible to see each product as a set of services available over the networJ, which canbe integrated as-it-is with the other TCS products using point-to-point service integration or +SB basedintegration.

=ey obHective for interoperability of the products using S/ is to define and design the


58/62


1escription of the Jey components are provided below @

'e=Ser4i7e #nter37e 1ealiation of


59/62




60/62


"0. SOA / STEPS TO BE TAE!

This section provides the details related to phased implementation of S/ across all products and thepreparation reGuired for the same.

"0." OR$AT#O! O ,OVER!A!CE BOD;

Before we embarJ on the planning, design and implementation phases for S/, we need to form a7overnance Body comprising Jey technical architects and business architectswho wll be responsible for thereview and assessment of the phased implementation and provide technology guidance to the implementationteam.

"0.2 U!CT#O!AL A!AL;S#S O PRODUCTS OR SERV#CE OR#E!TAT#O!

This is the most important aspect for S/ enabling

nalye each product and prepare the list of functionalities to be exposed as


61/62


+) frameworJ should have the capability to control the granularity of services and should be possible

to present the coarse grained services by composing the services within the product +) frameworJ.

)dentify and plan the possibility for asynchronous communication using


62/62

architecture design document v0[1].2

Documents