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 module’s 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 organisation’s 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
d
u
k
q
d
r
d
h
u
h
v
d
f
k
wd c
h
e
”
k
e
ry
g
v
W R
RTU
MNOP
RT
V
\ S
[
S
U
YZ
X
QRS
V
I
C
F
BC
F
=>?
@
L
E
J
E
{
~
| gx
d
f
k
d
r c
h
g
k
wd
r
I
L
E
J
E no
lm d j
h
k
K
GH
A
F
C
BC DE
F
@ A
=>?
|}
|
~
j
qh
g
d
d
k
hy
c
f
h s
d
p
d
g
s
d
p d
t
d
e
{|}
z
K
GH
DE
A
A
b
v
d
no
m
gx r
v
d z {|} g
di
h
e
c
df
d
q
k
d
f
h
qd
no
m
gx
d
w
u
e
1 1
1 1
1 1
1
3
3
/2
/2
3
/2
3
3
/2
/2/2
3
3
/2
/2
0
.
.
0 0
.
0
0
.
.
0
0
.
.
/
/
/
/
/
/
/
/
/
/
/
/
/
/
+,-
+,-
+,+,-
+,+,-
+,g q
h
7
05
0
05
;
<
6
/
;2
/ 9
0 / 0 /
/
;2
;
3
.
05
5
95
.
/
.
3
6
3;
3:
3
2
3
6
3:_
8
5
4
:
+
6
/
3
2
2
;
^2
4
5
]
{
|
|}
t
dy
h
d
k
t
hv
g
s
q
q
d
p
k r
q j l
k
df
h
k f
h s
~
<
|
~
|
{|}
v
c
no
m
gx
k r
z
d
(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
"
z
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.
`
s
d
p d
h
k
f
y
v
gx
d
“ r
e
Three Step SOA Deployments
k
a
qd
l
(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 organisation’s 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
1
Service N Interface
1..N
1
Business Service
¡¢
¦
¡¢
¦
¢
£
§
¨©
£
§
¨©
£
¬
¦
¢¥
¦
¢¥
§
¤
§
¤
«
ª
N
N
Service Container
N
1
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 container’s 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 container’s 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 container’s 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.
8
B
Web Services for Application Management
?H
G
9
E
?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
1
1
-0 -01 -0
1
-0
1-0 -01
-01
.
,
,
. .
,
,
.
. ,
,
.
.
,
,
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
)*
+
)*
)*+ +
)*
+
)*+ )*+
)*+
T24 WS Deployment Service
%
&
&
# * "( "
Activity 5
WSDL/SOAP
U
Y
[
Q O O
N
PQ
PQ PQ
PQ PQ
PQ PQ
PQ
N
O O
N
N
O O
N
N N
N M
M M
M M
M M
M
O
O
Z
M
N
TU
WX
M
N
IJKR
V
M
S
S
IJKL
IJKL IJKL
IJKL IJKL
IJKL IJKL
IJKL
M
M
M
M M
M
M
M M
M
M
M
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 :
<
5
78 9
6
6
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 company’s estimates as today’s date. We anticipate that subsequent events and developments will cause the company’s 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 company’s estimates of its future financial performance as of any date subsequent to today’s date.
MORE BUSINESS, LESS INFRASTRUCTURE Rev 122 6/6
