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
MORE BUSINESS, LESS INFRASTRUCTURE
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.
Rev 122 1/6
 peer-to-peer design, allowing TAG to the enterprise in a T24 XML dialect
provide an embedded master-slave employing a SOAP-like message
administration capability. This includes structure. The SOAP-like structure
configuration and administration follows the same principles as laid down
services for distributed runtime control. in the Web Services standards; single
TAG ships in both native .net 2.0 and envelope, mandatory body, optional
native Java 5, to enable T24 users to headers and fault-based error handling.
leverage their technology of choice.
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 Web Service. Deployment can be 1. The user defines a namespace for
performed directly from the T24 SOA the T24 SOA Web Service. This
tooling, but may also be deferred to the namespace should be consistent
preferred tool of an organisation. This with the organisations naming
permits the T24 SOA tooling to link to conventions.
any configuration management system,
2. The User selects the target pre-
for provision of release controls.
configured T24 installation and
This three step process simplifies the queries for available business
deployment of T24 SOA Web Services, services or for specific business
removing the need for specific and deep services. The selected T24 business
technical knowledge of the many Web services may then be added to the
Services technologies. user-defined Web Service.



!
!

$
$

'

'

$




!
!

$
$

'

'

$


"

"

%
%

&

&

#
#

#*

#*


"

"

%
%

&

&

#
#

#*

#*

T24 business services directly from the

standard Web Services technologies. Web Service Calls
(SOAP/XML)

gx
qd

d
a
Three Step SOA Deployments

u
v

wd

h
gx

k
d

d
s
Creation and deployment of T24 SOA

gx

no

k
r

ry
z


{|}

Web Services (TWS) is completely










































driven by the T24 SOA deployment WSDL

MNOP

W
! "

QRS

RTU



\
YZ

U
[

RT
tooling, and hence is a user-driven


T24 Code-Behind Wrappers



NAMESPACE










(Business Service Proxies)






activity. Which T24 business services

=>?

BC

I
F

F
b

DE

GH

E
K

L
are deployed on each Web Service is

{|}

gx
d

d
Significant amongst these capabilities is

completely user defined.

no

k
d

d
s
the XML API, the base message format

gx

g
v

hy

k
d

qh

wd
s

j
provided with T24. Introduced in 2001 The T24 SOA deployment tooling offers


{|}

|}
and known as OFSML, It is defined by a a GUI-based environment for defining

=>?

BC

I
F

F
A

DE

GH

E
K

L
fully W3C compliant XML Schema and the Web Service namespace, querying
documented by use cases. the available T24 transaction and

lm

no
enquiry business services on the target

df

di

d
j
`

k
OFSML, supported exclusively by the

qd

q
j

s
T24 installation, inspecting and
l

gx

no
h

df

hv

d
t

+,-

+,-

1
+,-

+,-

+,-

1
+,-

+,-

1
/

/2

/2

3
/

/2

/2/2

/2

3
/

/2

/2

3
T24 Application Gateway and pre-dating
k

g
qd

dy

q
h
s

t
finalising the Service Interfaces to be z

{|}

|}

05

7
^2

3
the Web Services era, offers generic

05
:

;2

<

;
deployed for each business service, and

9
3:_

3:

3;

0
/

/
.

95

05

0
3

<

;2

/
access to both core and customised
finally to optionally deploy the specified
T24 business services to be exposed to

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 2/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.
MORE BUSINESS, LESS INFRASTRUCTURE
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.
Container
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; All T24 Web Services are aggregated at
deployment time using a strictly
Service Interfaces the actual
enforced interpretation of the SOA
business service end-points of T24,
aggregation principle. The T24 SOA
aggregated to a Service Definition by
tooling requires that any T24 business
users via the T24 SOA deployment
service which is to be deployed as a
tool bound to a logical Service
Web Service, be placed in a user-
Definition;
defined Service Definition. A Service
Business Services the single- Definition represents a logical channel
source reusable T24 business via which one or more T24 business
service, implementing the associated services will be made accessible. It is
Service Interface on one or more established simply by defining a unique
Service Definitions (business name for the Service Definition, which
services may be reused across becomes the T24 logical channel name
Service Definitions). and hence the name of the Web
Service.
1 N Service N N Service 1 1..N Service N 1 Business
Container Definition Interface Service As Service Definition, or logical channel,
is used as a collection container in
which to place the reusable T24
business services, individual T24
T24 Service Definitions & Interfaces
business services thus become
The capability to create and deploy a exposed as one or more individual
Web Services rendering of T24 Service Interfaces within the Service
business services is one key aspect of Definition. Note, each reusable T24
the T24 SOA deployment tooling. business service retains its atomic unit
However, a second key aspect is the of work characteristic.
exact nature and quality of the business
Following the SOA aggregation model
service end-points offered by the Web
provides for a safe approach to
Services. It is the quality, and critically
the overall consistency in style, of the business service reuse. A business
deployable Web Services definitions service that is reused on two different
that determines a critical aspect of the Service Definitions is scoped by
final usability of the T24 Web Services. different logical channel names. Hence,
Rev 122 3/6
 where the same T24 business service is criteria. Hence, as only a single due to validation failures. definition, including mandatory fields.
deployed on different logical channels, mapping rule exists, masking of enquiry
Reverse unwind an existing WSDL & WS-I
each instance of the deployed business service mappings is not permitted: if an
transaction in T24. Based on the SOA aggregation and
service is easily and uniquely identified enquiry is added to a Service Definition,
by its associated Service Definition. it must exist on the Web Service. Delete delete the record of an deployment models, the deployment
existing transaction in T24. generation of T24 business services
http://my-ws-host/my-ws-container/my-webservice-name creates a Web Services Definition

See retrieve (show) the record of Language (WSDL) in a consistent style

an existing transaction in T24.

regardless of the T24 business services

fundsTransfer_Internal_Input
fundsTransfer_Internal_Authorise As each of these functions infers a selected.
fundsTransfer_Domestic_Input different processing aspect of a T24
#

The T24 deployment tooling permits a

fundsTransfer_Domestic_Authorise

business service, it is necessary to
! #

fundsTransfer_International_Input number of control options on the

$

fundsTransfer_International_Authorise define T24 business service end-points generation of the WSDL. The
fundsTransfer_International_Reverse
as: deployment tool does not generate
accountBalanceEnquiry WSDL itself directly it actually
Service Interface ::=

accountStatusEnquiry

accountTypeEnquiry T24 business service + function. generates a code-behind package
describing the Web Service.
Once a T24 transaction is added to a
Service Definition using the SOA Although the WSDL is, in reality, always
Service Interface Mappings T24 transaction business services are deployment tooling, it is possible to generated by the target Web Services
slightly more complex, due to the select exactly which of the five container, the deployment tooling
The mapping of T24 business services
multiple functions offered by T24. associated Service Interfaces are to be presents options to influence the WSDL
to individual Service Interfaces is very
deployed. generation. This includes options
well defined. This mapping is managed For each transaction definition in T24,
around the use of the WS-I (WS-
by the deployment tooling, which up to five functions or aspects may This facility enables masking of the Interoperability) profile, for the full
additionally supports the possibility to be applied to the business service. This unwanted Service Interfaces associated document style WSDL with both bare
mask particular mappings if required. is applicable uniformly to all transaction with a T24 transaction definition, which and wrapped parameter renderings.
T24 enquiry business services are business services offered by T24. in turn helps to restrict the deployed
Web Service to exactly those features Enabling native support for the WS-I
relatively straight forward, mapping one- Input input a new or amend an
required by the user. profile ensures a high-level of
to-one with a single Service Interface on existing transaction in T24. compatibility of the T24 Web Services
any given Service Definition. This is
Authorise authorise an existing Finally, Service Interfaces for T24 solution with the many Web Services
possible as the only parameters that
transaction that has blocked in T24 transactions offer request and response platforms in the market, including both
need to be passed are for selection
parameters aligned to the transaction open source and commercial products.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 4/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
propagated to the TWS by the Web Services effectively run headless: the Multi-tier Deployment
Services container itself. TWS then deployment tooling is not required at T24 SOA Web Services (TWS) are built
uses that context to recover the runtime. on top of the T24 Application Gateway
associated T24 user from a T24 identity (TAG). As TAG is based on a peer-to-
Service inspection is possible via a
mapping branch stored in LDAP or peer deployment design, TWS benefits
direct query by an external tool on the
Active Directory. from a multi-tier deployment capability
WSDL. However, the Web Service
The TWS implementation uses the cannot be altered directly once too.
standards associated with the selected deployed. The only method available Web Service Calls
(SOAP/XML)
technology platform (.net or Java) and for altering the service specification is to
the underlying secure store for the T24 re-deploy it. Hence, the containers
identity mapping branch (LDAP or platform services help to secure and WSDL
Active Directory). Hence, it is possible control T24 SOA Web Services (TWS).
to extend the T24 Impersonate facility to
Service discovery is possible as the
include any external authentication
WSDL is standard. TWS itself does not
"#
(
$%&'
manager that offers direct support for
perform automatic registration of
WS-Security (as implemented by the
available services to repositories like WSDL
target Web Services container).
UDDI. However, if the container
SOAP T24 Services Invocations platform supports automated






!
Once deployed, the T24 SOA Web registration, it is possible to have TWS
services recorded in UDDI or any other
Web Service Calls
(SOAP/XML) repository supported by the containers

















 






runtime, when a Web Service invocation platform services.
is received by TWS, the alternative Execution interaction with the Web


















TWS may be deployed on the same

identity is mapped to a pre-associated Services is via standard SOAP/XML

T24 user. The associated T24 user is physical server as the T24 applications,

messaging. TWS itself does not have

then submitted to the requested T24 its own SOAP listener; it relies or on a middle-tier server or servers.
business service and is used as normal completely on the SOAP listener TWS is compliant with the overall T24
in the authorisation profile of the T24 provided by the Web Services container architecture, and hence supports a
Security Management System. runtime. Hence, SOAP processing, distributed deployment pattern that

This security mechanism is based on including basic validation, is performed scales vertically up to adjacent tiers and

by the containers platform services.

horizontally on the same tier.

standards. The WS-Security context is

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 5/6
 Service Management secure communications via WS- Calls to other Systems About TEMENOS
Post deployment, TWS is managed via Security (X509 certificate based). Founded in 1993, TEMENOS Group AG is a
the TAG distributed administration
Activity 1 Activity 2 Activity 3 Activity 4
provider of integrated modular core banking

!
These features are accessible from any
facilities. systems to over 500 financial institutions in

,
system that can consume and invoke Activity 5
110 countries worldwide. TEMENOS
TAG administration general features: Web Services. A configuration and software provides banks with a single, real-
Web Service Calls
administration GUI is provided also. time view of the client across the enterprise,
master/slave configuration service, WSDL/SOAP
enabling banks to maximize returns while
for the setting of all technical BPEL Interaction
streamlining costs. Whether providing 24/7
parameters for gateway instances & The support offered by T24 SOA Web functionality to the wholesale, retail and

IJKR

TU

Y
N

N
S

WX

Q
Z

[
supported Web Service containers; Services for a number of the key WS private or universal banking sectors,
standards, namely WSDL, SOAP and partnering with central banks on core
master/slave administration service, system replacement, or working with the
WS-I, provides for interoperability with

IJKL

IJKL

O
IJKL

IJKL

O
IJKL

IJKL

O
IJKL

IJKL

O
N

N
M

M
M

PQ
PQ
M

M
M

PQ
PQ
M

M
M

PQ
PQ
M

M
M

PQ
PQ
for control of local and remote World Bank on solutions for the emerging
an Enterprise Service Bus (ESB) and
gateway instances; markets, TEMENOS knows banking. The
any associated Business Process The deployed WSDL associated with
company has a transparent approach to its
master/slave message monitoring Execution Language (BPEL) engine. the channel may then be imported by operations and brings to bear its experience,
and reporting services: a third party BPEL tool. Orchestration expertise, commitment and professionalism
T24 SOA Web Services are deployed in
of T24 business services is at the on every project.
all master/slave services are the standard manner, as a set of related
Service Interface level, with individual
technical Web Services; channel business services. Headquartered in Geneva, Switzerland, the
Service Interfaces becoming atomic
company has 39 offices in 31 countries and
activities in the BPEL workflow. This is listed on the main segment of the SWX
Web Services for Web Services for
assures the transactional behaviour of Swiss Exchange (TEMN).
234

BC

5D

Gateway Management Application Management

?

?F

?H

T24 within the long-lived process. www.temenos.com

TAG Configuration T24 User Management
Service Service
Instrumentation of a BPEL flow, to feed Any statements in this press release about future expectations,
TAG Administration T24 Agent Control (COB) plans and prospects for the company and statements containing
Service Service a Business Activity Monitor (BAM), is the words believes, anticipates, plans, expects, will and
234

78

;8

>

similar expressions, constitute forward-looking statements. Actual

6

<

:A

TAG Instrumentation
Service
T24 TEC Instrumentation
Service
also possible. This is outside the scope results may differ materially from those indicated by these forward-

TAG Reporting T24 WS Deployment

of the TWS, but many of the ESB looking statements as a result of various factors. In particular, the
forward looking financial information provided by the company in
Service Service
vendors in the market offer a BAM this press release represents the companys estimates as todays
date. We anticipate that subsequent events and developments will
facility which is dependent only on the cause the companys estimates to change. However, while the
BPEL flow definition itself. 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
Hence, any T24 SOA Web Service may
)*
+
)*
+

/
)*
+
)*+
+
)*+

,
,
,
,

/
)*+

)*+

/
-

1
-0
1
-0
-
-
-
-

1
-0
1-0
-0
-01
-

-01

-01

statements should not be relied upon as representing the

companys estimates of its future financial performance as of any
% & % & be employed in a BPEL orchestration, date subsequent to todays date.
# #
' () * "( " ( " and may be linked to BAM via BPEL.

MORE BUSINESS, LESS INFRASTRUCTURE

Rev 122 6/6