t24 soa webservices

Rev 122 1/6

MORE BUSINESS, LESS INFRASTRUCTURE

R07+ Highlights Support for W3C/OASIS

compliant Web Services Multi-Platform capable

native Web Services support in both Java 5 & .net 2.0

Full access to T24 transaction and enquiry business services

GUI-based deployment tooling for defining which T24 business services are made available as Web Services

Web Service deployment follows the Service Oriented Architecture aggregation principle user defined at deployment time

Host T24 Web Services on the application server tier, middle tier and/or both

Supports resilience & fail-over deployment options

WS-Security support via the T24 Impersonate Service

Embedded instrumentation and configuration control

Introduction T24 Business Services The T24 Banking Platform has offered a business service oriented architecture to its users since 1996; with the creation of the Open Financial Services (OFS) module, the T24 user population gained a generic and open access to the entire set of core banking transaction and information services offered by the business applications of T24. This feature of T24 has been a corner-stone in the technical evolution of the platform, underpinning the multi-channel capabilities of T24.

T24 business services fall into 6 major categories: transactions, to perform discrete controlled business functions such as funds transfers; enquires, to access data from the T24 database in a secure and controlled manner; business messaging, for services such as SWIFT; report services, for client and management information presentation; events, providing notifications of user defined significant activities inside T24; and technical management services,

providing services for the technical control, instrumentation, monitoring and configuration administration facilities.

All of these services offered by T24, be they core services shipped with the product or customised services tailored to a particular client site, are registered in the T24 database as T24 services definitions. These definitions allow the services to be self-describing, defining the service type (a unique name or identity for the service), required business data (inputs and outputs) and any constraints (validations). They provide a comprehensive description of the business services contracts, a fundamental building block of any service-based application.

Open Access, Open Technology The introduction of the OFS module permitted the exposure of the business services of T24 via many technology environments, all based on the generic service access offered by OFS. This includes application programming interfaces (APIs) in technologies such as Java and .net, and support for enterprise middleware message bus environments such as the de facto standard IBM WebSphere MQ, generic Java-based JMS and the Microsoft MSMQ. Support for these newer technologies has been provisioned by an extended module, extending the reach of the OFS modules capabilities. This extended module is based on a de facto standard design pattern known as an application gateway, hence the module is known as the T24 Application Gateway1.

The T24 Application Gateway (TAG) is a pure technology component. It uses a

1 Commonly termed the connector.

Release R07 of the TEMENOS T24TM Banking Platform provides an integrated Web Services deployment tooling capability, providing T24 users with SOA-compliant core banking business services interfaces for their enterprise.

Rev 122 2/6


peer-to-peer design, allowing TAG to provide an embedded master-slave administration capability. This includes configuration and administration services for distributed runtime control. TAG ships in both native .net 2.0 and native Java 5, to enable T24 users to leverage their technology of choice.

Significant amongst these capabilities is the XML API, the base message format provided with T24. Introduced in 2001 and known as OFSML, It is defined by a fully W3C compliant XML Schema and documented by use cases.

OFSML, supported exclusively by the T24 Application Gateway and pre-dating the Web Services era, offers generic access to both core and customised T24 business services to be exposed to

the enterprise in a T24 XML dialect employing a SOAP-like message structure. The SOAP-like structure follows the same principles as laid down in the Web Services standards; single envelope, mandatory body, optional headers and fault-based error handling.

This capability, coupled with the distributed administration of TAG and strong self-describing nature of the T24 business services, provides the staging post for the creation of full access to the T24 business services directly from the standard Web Services technologies.

Three Step SOA Deployments Creation and deployment of T24 SOA Web Services (TWS) is completely driven by the T24 SOA deployment tooling, and hence is a user-driven activity. Which T24 business services are deployed on each Web Service is completely user defined.

The T24 SOA deployment tooling offers a GUI-based environment for defining the Web Service namespace, querying the available T24 transaction and enquiry business services on the target T24 installation, inspecting and finalising the Service Interfaces to be deployed for each business service, and finally to optionally deploy the specified

T24 Web Service. Deployment can be performed directly from the T24 SOA tooling, but may also be deferred to the preferred tool of an organisation. This permits the T24 SOA tooling to link to any configuration management system, for provision of release controls.

This three step process simplifies the deployment of T24 SOA Web Services, removing the need for specific and deep technical knowledge of the many Web Services technologies.

1. The user defines a namespace for the T24 SOA Web Service. This namespace should be consistent with the organisations naming conventions.

2. The User selects the target pre-configured T24 installation and queries for available business services or for specific business services. The selected T24 business services may then be added to the user-defined Web Service.

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

!" #

$!% &

'

#

$( ) #*

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

4 0

/

056

7

8

3

9

3: 3; 6 3

./

0

/

+

: / ;2 / 6

05< ;

.

/

0

/

=>? @A A

BCDE

F

CGH

I

E

FJK

E

L

WSDL ! " ! "

NAMESPACE

MNOP

QRS RTU

V

R

W

XYZ [S

V

U

\

S RT

Web Service Calls(SOAP/XML)

]^2

5

; 32 2

4

3:_

56 32

.

3

95

;

5 05

< ;2

`

a

b

cd

e

df

gh di

j

k

h d

lm no

p

j

q

kr d q q qd h

s

k

f d q

l k

h df

g et

u

hv w

gx

d

m no

qd hs

k

f d h dy

k

q

g

h

t

z{|} ~

|

| }

| {

qd h

l

d

u kr d q

gx

d

e

v y

k

f

e

r wd

u

v h

gx

d

k

h

d

p c

d hs

k

f d

kr

gx

d

m no c g

v v

e kr y

z{|} ~

|

|

d

e

v

t

gx

d r d

m no

d

p cd h

s

k

f d

v r

gx

d

g

h y d

g

d

p cd h

s

k

f d qh

jr

g k

w d

z{|} ~

|

|}

=>? @A A

BC

DE

F

CGH

I

E

FJK

E

L

T24 Code-Behind Wrappers(Business Service Proxies)

z{|} ~

|

{

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

+,- ./

0

/

1/ 2 3

4 0

/

056

7

8

3

9

3: 3; 6 3

./

0

/

+

: / ;2 / 6

05< ;

.

/

0

/

=>? @A A

BCDE

F

CGH

I

E

FJK

E

L

WSDL ! " ! "

NAMESPACE

MNOP

QRS RTU

V

R

W

XYZ [S

V

U

\

S RT


]^2

5

; 32 2

4

3:_

56 32

.

3

95

;

5 05

< ;2

`

a

b

cd

e

df

gh di

j

k

h d

lm no

p

j

q

kr d q q qd h

s

k

f d q

l k

h df

g et

u

hv w

gx

d

m no

qd hs

k

f d h dy

k

q

g

h

t

z{|} ~

|

| }

| {

qd h

l

d

u kr d q

gx

d

e

v y

k

f

e

r wd

u

v h

gx

d

k

h

d

p c

d hs

k

f d

kr

gx

d

m no c g

v v

e kr y

z{|} ~

|

|

d

e

v

t

gx

d r d

m no

d

p cd h

s

k

f d

v r

gx

d

g

h y d

g

d

p cd h

s

k

f d qh

jr

g k

w d

z{|} ~

|

|}

=>? @A A

BC

DE

F

CGH

I

E

FJK

E

L

T24 Code-Behind Wrappers(Business Service Proxies)

z{|} ~

|

{

Rev 122 3/6


3. The Web Service is then finalised by defining global settings such as WS-Security policies. Additionally, if required, each Service Interface may be finalised too, to remove (mask) any unrequired functions provided by the T24 business service (see T24 Service Definitions & Interfaces for more information). Finally, the new Web Service is saved as a T24 Service Definition. Optionally, the user may target a pre-configured Web Services runtime container and interactively deploy the Web Service, a feature that is intended to service the needs of an active T24 implementation environment.

The three step deployment process, embodied in the associated tooling, significantly simplifies and streamlines the mechanisms for deploying well defined T24 business services as Web Services. Note, each Web Service is treated as a Service Definition and hence may be viewed as a channel.

When coupled with good analysis of an organisations multi-channel model and channel services needs, the T24 SOA Web Services deployment tooling can rapidly bridge the gap from analysis to a very tangible multi-channel Web Services deployment.

Deployment Model The overall deployment model employed by the T24 SOA Web Services is intended to provide a consistent and repeatable manner in which to create and deploy Web Services for any T24 installation.

The deployment model encompasses both the interface definition model and the runtime model. This promotes transparency and traceability in the deployment model, from the T24 business service to the physical runtime Web Services host.

The deployment model is comprised of:

Web Service container hosts the physical servers where T24 Web Services will reside bound to a physical server;

Web Service containers the logical end-point location for a Web Service bound to N container hosts;

Service Definitions the user defined T24 SOA Web Service (channel services), defined by users via the T24 SOA deployment tool bound to

one or more containers;

Service Interfaces the actual business service end-points of T24, aggregated to a Service Definition by users via the T24 SOA deployment tool bound to a logical Service Definition;

Business Services the single-source reusable T24 business service, implementing the associated Service Interface on one or more Service Definitions (business services may be reused across Service Definitions).

T24 Service Definitions & Interfaces The capability to create and deploy a Web Services rendering of T24 business services is one key aspect of the T24 SOA deployment tooling. However, a second key aspect is the exact nature and quality of the business service end-points offered by the Web Services. It is the quality, and critically the overall consistency in style, of the deployable Web Services definitions that determines a critical aspect of the final usability of the T24 Web Services.

All T24 Web Services are aggregated at deployment time using a strictly enforced interpretation of the SOA aggregation principle. The T24 SOA tooling requires that any T24 business service which is to be deployed as a Web Service, be placed in a user-defined Service Definition. A Service Definition represents a logical channel via which one or more T24 business services will be made accessible. It is established simply by defining a unique name for the Service Definition, which becomes the T24 logical channel name and hence the name of the Web Service.

As Service Definition, or logical channel, is used as a collection container in which to place the reusable T24 business services, individual T24 business services thus become exposed as one or more individual Service Interfaces within the Service Definition. Note, each reusable T24 business service retains its atomic unit of work characteristic.

Following the SOA aggregation model provides for a safe approach to business service reuse. A business service that is reused on two different Service Definitions is scoped by different logical channel names. Hence,

ServiceDefinition

ServiceInterface

1..N1

ServiceContainer

NN

ContainerHost

N1

BusinessService

1

NServiceDefinition

ServiceInterface

1..N1

ServiceContainer

NN

ContainerHost

N1

BusinessService

1

N

Rev 122 4/6


where the same T24 business service is deployed on different logical channels, each instance of the deployed business service is easily and uniquely identified by its associated Service Definition.

Service Interface Mappings The mapping of T24 business services to individual Service Interfaces is very well defined. This mapping is managed by the deployment tooling, which additionally supports the possibility to mask particular mappings if required.

T24 enquiry business services are relatively straight forward, mapping one-to-one with a single Service Interface on any given Service Definition. This is possible as the only parameters that need to be passed are for selection

criteria. Hence, as only a single mapping rule exists, masking of enquiry service mappings is not permitted: if an enquiry is added to a Service Definition, it must exist on the Web Service.

T24 transaction business services are slightly more complex, due to the multiple functions offered by T24.

For each transaction definition in T24, up to five functions or aspects may be applied to the business service. This is applicable uniformly to all transaction business services offered by T24.

Input input a new or amend an existing transaction in T24.

Authorise authorise an existing transaction that has blocked in T24

due to validation failures.

Reverse unwind an existing transaction in T24.

Delete delete the record of an existing transaction in T24.

See retrieve (show) the record of an existing transaction in T24.

As each of these functions infers a different processing aspect of a T24 business service, it is necessary to define T24 business service end-points as:

Service Interface ::= T24 business service + function.

Once a T24 transaction is added to a Service Definition using the SOA deployment tooling, it is possible to select exactly which of the five associated Service Interfaces are to be deployed.

This facility enables masking of the unwanted Service Interfaces associated with a T24 transaction definition, which in turn helps to restrict the deployed Web Service to exactly those features required by the user.

Finally, Service Interfaces for T24 transactions offer request and response parameters aligned to the transaction

definition, including mandatory fields.

WSDL & WS-I Based on the SOA aggregation and deployment models, the deployment generation of T24 business services creates a Web Services Definition Language (WSDL) in a consistent style regardless of the T24 business services selected.

The T24 deployment tooling permits a number of control options on the generation of the WSDL. The deployment tool does not generate WSDL itself directly it actually generates a code-behind package describing the Web Service.

Although the WSDL is, in reality, always generated by the target Web Services container, the deployment tooling presents options to influence the WSDL generation. This includes options around the use of the WS-I (WS-Interoperability) profile, for the full document style WSDL with both bare and wrapped parameter renderings.

Enabling native support for the WS-I profile ensures a high-level of compatibility of the T24 Web Services solution with the many Web Services platforms in the market, including both open source and commercial products.

http://my-ws-host/my-ws-container/my-webservice-name

fundsTransfer_Internal_InputfundsTransfer_Internal_AuthorisefundsTransfer_Domestic_InputfundsTransfer_Domestic_AuthorisefundsTransfer_International_InputfundsTransfer_International_AuthorisefundsTransfer_International_Reverse

accountBalanceEnquiryaccountStatusEnquiryaccountTypeEnquiry

!

#

$

#

http://my-ws-host/my-ws-container/my-webservice-name





!

#

$

#

$

#

Rev 122 5/6


WS-Security T24 Impersonate Leveraging the facilities offered by the Web Services runtime containers provides easier access to a number of the emerging WS-STAR standards such as WS-Addessing and WS-Security.

WS-Security support is available with the T24 SOA Web Services (TWS). This permits alternative, non-T24, identities to be used in conjunction with calls to the T24 SOA Web Services, to execute any request on any business service end-point. Where alternative (external) identities are used, TWS does not directly authenticate the request itself; all authentication is deferred to the associated external authentication manager.

Alternative identities support that ships with TWS includes X509 digital certificates and NT domain users. At runtime, when a Web Service invocation is received by TWS, the alternative identity is mapped to a pre-associated T24 user. The associated T24 user is then submitted to the requested T24 business service and is used as normal in the authorisation profile of the T24 Security Management System.

This security mechanism is based on standards. The WS-Security context is

propagated to the TWS by the Web Services container itself. TWS then uses that context to recover the associated T24 user from a T24 identity mapping branch stored in LDAP or Active Directory.

The TWS implementation uses the standards associated with the selected technology platform (.net or Java) and the underlying secure store for the T24 identity mapping branch (LDAP or Active Directory). Hence, it is possible to extend the T24 Impersonate facility to include any external authentication manager that offers direct support for WS-Security (as implemented by the target Web Services container). SOAP T24 Services Invocations Once deployed, the T24 SOA Web

Services effectively run headless: the deployment tooling is not required at runtime.

Service inspection is possible via a direct query by an external tool on the WSDL. However, the Web Service cannot be altered directly once deployed. The only method available for altering the service specification is to re-deploy it. Hence, the containers platform services help to secure and control T24 SOA Web Services (TWS). Service discovery is possible as the WSDL is standard. TWS itself does not perform automatic registration of available services to repositories like UDDI. However, if the container platform supports automated registration, it is possible to have TWS services recorded in UDDI or any other repository supported by the containers platform services.

Execution interaction with the Web Services is via standard SOAP/XML messaging. TWS itself does not have its own SOAP listener; it relies completely on the SOAP listener provided by the Web Services container runtime. Hence, SOAP processing, including basic validation, is performed by the containers platform services.

Multi-tier Deployment T24 SOA Web Services (TWS) are built on top of the T24 Application Gateway (TAG). As TAG is based on a peer-to-peer deployment design, TWS benefits from a multi-tier deployment capability too.

TWS may be deployed on the same physical server as the T24 applications, or on a middle-tier server or servers.

TWS is compliant with the overall T24 architecture, and hence supports a distributed deployment pattern that scales vertically up to adjacent tiers and horizontally on the same tier.



!

WSDL

WSDL


"#$%&'

( (

!

WSDL

WSDL


"#$%&'

( (

Rev 122 6/6


Service Management Post deployment, TWS is managed via the TAG distributed administration facilities.

TAG administration general features:

master/slave configuration service, for the setting of all technical parameters for gateway instances & supported Web Service containers;

master/slave administration service, for control of local and remote gateway instances;

master/slave message monitoring and reporting services:

all master/slave services are technical Web Services;

secure communications via WS-Security (X509 certificate based).

These features are accessible from any system that can consume and invoke Web Services. A configuration and administration GUI is provided also.

BPEL Interaction The support offered by T24 SOA Web Services for a number of the key WS standards, namely WSDL, SOAP and WS-I, provides for interoperability with an Enterprise Service Bus (ESB) and any associated Business Process Execution Language (BPEL) engine. T24 SOA Web Services are deployed in the standard manner, as a set of related channel business services.

The deployed WSDL associated with the channel may then be imported by a third party BPEL tool. Orchestration of T24 business services is at the Service Interface level, with individual Service Interfaces becoming atomic activities in the BPEL workflow. This assures the transactional behaviour of T24 within the long-lived process.

Instrumentation of a BPEL flow, to feed a Business Activity Monitor (BAM), is also possible. This is outside the scope of the TWS, but many of the ESB vendors in the market offer a BAM facility which is dependent only on the BPEL flow definition itself.

Hence, any T24 SOA Web Service may be employed in a BPEL orchestration, and may be linked to BAM via BPEL.

About TEMENOS Founded in 1993, TEMENOS Group AG is a provider of integrated modular core banking systems to over 500 financial institutions in 110 countries worldwide. TEMENOS software provides banks with a single, real-time view of the client across the enterprise, enabling banks to maximize returns while streamlining costs. Whether providing 24/7 functionality to the wholesale, retail and private or universal banking sectors, partnering with central banks on core system replacement, or working with the World Bank on solutions for the emerging markets, TEMENOS knows banking. The company has a transparent approach to its operations and brings to bear its experience, expertise, commitment and professionalism on every project. Headquartered in Geneva, Switzerland, the company has 39 offices in 31 countries and is listed on the main segment of the SWX Swiss Exchange (TEMN). www.temenos.com

Any statements in this press release about future expectations, plans and prospects for the company and statements containing the words believes, anticipates, plans, expects, will and similar expressions, constitute forward-looking statements. Actual results may differ materially from those indicated by these forward-looking statements as a result of various factors. In particular, the forward looking financial information provided by the company in this press release represents the companys estimates as todays date. We anticipate that subsequent events and developments will cause the companys estimates to change. However, while the company may elect to update this forward-looking financial information at some point in the future, the company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the companys estimates of its future financial performance as of any date subsequent to todays date.

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

234 56 6

789 :

;8< =

>

:

;? @ :A

Web Services forWeb Services forGateway ManagementGateway Management

TAG ConfigurationTAG ConfigurationServiceService

TAG AdministrationTAG AdministrationServiceService

TAG InstrumentationTAG InstrumentationServiceService

TAG ReportingTAG ReportingServiceService

Web Services forWeb Services forApplication ManagementApplication Management

T24 User ManagementT24 User ManagementServiceService

T24 Agent Control (COB)T24 Agent Control (COB)ServiceService

T24 TEC InstrumentationT24 TEC InstrumentationServiceService

T24 WS DeploymentT24 WS DeploymentServiceService

% &

#' () * "("

% &

# ("

234 BC 5D

?

E B

?F G

89 ?H

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)*+ ,-

.

-

/

-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

)* + ,-

.

-

/-01

234 56 6

789 :

;8< =

>

:

;? @ :A

Web Services forWeb Services forGateway ManagementGateway Management

TAG ConfigurationTAG ConfigurationServiceService

TAG AdministrationTAG AdministrationServiceService

TAG InstrumentationTAG InstrumentationServiceService

TAG ReportingTAG ReportingServiceService

Web Services forWeb Services forApplication ManagementApplication Management

T24 User ManagementT24 User ManagementServiceService

T24 Agent Control (COB)T24 Agent Control (COB)ServiceService

T24 TEC InstrumentationT24 TEC InstrumentationServiceService

T24 WS DeploymentT24 WS DeploymentServiceService

% &

#' () * "("

% &

# ("

234 BC 5D

?

E B

?F G

89 ?H

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

I JKRS S

TUVM

N

UWX

Y

M

N

QZ

M

[

WSDL/SOAP

Web Service Calls

Activity 1 Activity 3 Activity 4

Activity 5

Activity 2

Calls to other Systems

!

+

+

+

+

,

,

,

,

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKLM

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

IJKL

M

N

M

O

M PQ

I JKRS S

TUVM

N

UWX

Y

M

N

QZ

M

[

WSDL/SOAP

Web Service Calls

Activity 1 Activity 3 Activity 4

Activity 5

Activity 2

Calls to other Systems

!

+

+

+

+

,

,

,

,

t24 soa webservices

Documents

business services of

t24 services definitions

information services

business services contracts

customised services

business applications

t24 transaction

t24 database