TM

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

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 1/6

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.

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 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.

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 preconfigured 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.
Web Service Calls

gx

wd
c

ry

W
R

RTU

MNOP

RT

\
S

YZ

QRS

BC

=>?

|
gx

r
c

wd

r


E
no

lm
d
j

GH

BC
DE

@
A

=>?

|}

qh

hy

h
s

p
d

{|}

GH

DE

no

gx
r

d
z
{|}
g

di

df

qd

no

gx

1
1

1
1

1
1

/2

/2

/2

/2

/2/2

/2

/2

0
0

+,-

+,-

+,+,-

+,+,-

+,g
q

05

05

<

;2

/
9

0
/
0
/

;2

05

95

3;

3:

3:_

^2

|}

dy

hv

k
r

q
j
l

df

k
f

h
s


~

<

{|}

no

gx

k
r

(Business Service Proxies)

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 Code-Behind Wrappers

NAMESPACE

qd

WSDL

"







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

{|}








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.

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.



































p
d

gx

Three Step SOA Deployments

qd

(SOAP/XML)

#*

#*
#*

#*

)
)

'

'

'

'

$
(

&

&
&

&

!
#

%
#

%
%

!
"

"

"

"















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.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 2/6

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.

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.

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;

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.

Business Services the singlesource reusable T24 business

service, implementing the associated
Service Interface on one or more
Service Definitions (business
services may be reused across
Service Definitions).

Service
Definition

Service N
Interface

1..N

Business
Service

Service
Container

Container
Host

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.

one or more containers;

Deployment Model

3. The Web Service is then finalised by

defining global settings such as WSSecurity 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 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

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 userdefined 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,

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 3/6

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

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 oneto-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

Reverse unwind an existing

transaction in T24.
Delete delete 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:

accountBalanceEnquiry
accountStatusEnquiry
accountTypeEnquiry

fundsTransfer_Internal_Input
fundsTransfer_Internal_Authorise
fundsTransfer_Domestic_Input
fundsTransfer_Domestic_Authorise
fundsTransfer_International_Input
fundsTransfer_International_Authorise
fundsTransfer_International_Reverse

due to validation failures.

See retrieve (show) the record of

an existing transaction in T24.

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.

! #

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.

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

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 (WSInteroperability) 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.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 4/6










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.

(
$%&'

"#

WSDL



!









 












WSDL

(SOAP/XML)

This security mechanism is based on

standards. The WS-Security context is

Web Service Calls

(SOAP/XML)

Once deployed, the T24 SOA Web

Web Service Calls

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.

SOAP T24 Services Invocations

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.

T24 SOA Web Services (TWS) are built

on top of the T24 Application Gateway
(TAG). As TAG is based on a peer-topeer deployment design, TWS benefits
from a multi-tier deployment capability
too.

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).

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).

Multi-tier Deployment

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.

Services effectively run headless: the

deployment tooling is not required at
runtime.

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.

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.

WS-Security T24 Impersonate

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.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 5/6

 secure communications via WSSecurity (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.

TAG administration general features:

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

T24 SOA Web Services are deployed in

the standard manner, as a set of related
channel business services.

Web Services for

Application Management

?H

?F

5D

234

BC

all master/slave services are

technical Web Services;

TAG Configuration
Service

T24 User Management

Service

TAG Instrumentation
Service

:A

T24 TEC Instrumentation

Service

TAG Reporting
Service

/
/

/
/
/

/
-0

-0
-01
-0

-0

1-0
-01

-01

.
.

.
,

)*

)*

)*+
+

)*

)*+
)*+

)*+

T24 WS Deployment
Service

&

&

#
* "( "

Activity 5

WSDL/SOAP

Q
O
O

PQ

PQ
PQ

PQ
PQ

PQ
PQ

PQ

O
O

O
O

N
N

N
M

M
M

M
M

M
M

TU

WX

IJKR

IJKL

IJKL
IJKL

IJKL
IJKL

IJKL
IJKL

IJKL

M
M

M
M

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.

T24 Agent Control (COB)

Service

;
:

>
=

;8
:

<

78
9

234

TAG Administration
Service

#
' ()

Activity 4

Web Service Calls

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.

master/slave message monitoring

and reporting services:

Activity 3

Activity 2

BPEL Interaction

master/slave administration service,

for control of local and remote
gateway instances;

Web Services for

Gateway Management

Activity 1

Post deployment, TWS is managed via

the TAG distributed administration
facilities.

About TEMENOS

Calls to other Systems

Service Management

( "

Hence, any T24 SOA Web Service may

be employed in a BPEL orchestration,
and may be linked to BAM via BPEL.

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, realtime 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 forwardlooking 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.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 6/6