1

White Paper (Technical Appendix)

A real technology for a new collaborative philosophy between applications and business processes

SOA: Service Oriented Architecture

2

1 SOA in J2EE 4

Introduction to Java 4J2EE Components 5Construction of the SOA Service Layer in J2EE 6Security in Web Services 7Interoperability in Relation to Security and possible Problems 9Transactionality in SOA and J2EE 10BTP 11WS-Transaction/WS-Coordination 11JAXTX 11Monitoring in SOA and J2EE 11

2 SOA in EAi 13

MOM Characteristics 13EAI Architecture 15The Adaptor 17Web Services 17Security in EAI 18Message Broker-based Security 20Connector-based Security 20Security based on the Proxy between Connectors and the ESB 21The ACL Management Service 21Transactionality in EAI 21

3 SOA in .nET 23

Working with Services 23Web Services 23Security 25Monitoring 25Transactionality 26SOA Realities with .NET 27What does the Future hold for us? 27Indigo: Windows Communication Foundation 27Avalon: Windows Presentation Foundation 28Windows WorkFlow Foundation 28

4 SOA in lEgAcy TEchnOlOgy EnvirOnmEnTS 29

CICS Environments 29Environments involving Procedures stored on Databases 31Environments with ANSI C or VISUAL C++/Visual Basic Applications 32Alternative environments 33

5 cOnclUSiOnS 34

6 linE Of BUSinESS in ATOS ApplicATiOn ArchiTEcTUrE 35

CONTENTS (TECHNICAL APPENDIX)

3

SErvicE OriEnTEd ArchiTEcTUrE (SOA) iS in ThE prOcESS Of implEmEnTATiOn in ThE lEAding mArkET cOmpAniES. These forms of architecture are characterized by the fact that they are composed of functional units – services – rendered by service businesses.

Although initially, the definition of SOA only covered web services, corporate reality often implies extending this definition to cover other services that include ad-hoc development (Cobol/CICS, Visual Basic, Fortran, and C... transactions) and software packages (SAP, Documentum, Staffware...).

The present document represents the Technical Appendix to the White Paper entitled SOA: Service Oriented Architecture, supplementing it with a technical review of these forms of architecture in the different environments existing in companies nowadays.

ABSTRACTCONTENTS (TECHNICAL APPENDIX)

4

Initation

inTrOdUcTiOn TO JAvA

Currently, Java is one of the leading platforms for the creation of corporate software. The evolution of the Java programming language has been extraordinary (see the figure below). It has progressed from its role as a tool for developing small applets for execution on browsers to become a standard multi-platform programming model, now capable of implementing the critical applications of large companies.

The Java platform is not a specific software, but rather, a set of specifications defining each and every one of the technologies comprising the platform.

It is necessary at this point to underscore that Java, and specifically J2EE, are neither commercial products nor a sole manufacturer’s alternative for business software development, but rather a set of specifications in which the main software manufacturers of the world participate, nowadays referred to as the JCP (Java Community Process). The figure below summarises the process of evolution that Java has undergone since it appeared, (when Sun Microsystems held all the rights to the platform), until it became the current free standard.

The Java Community Process is the organism that governs the evolution of the Java platform through the creation of new specifications and the maintenance of those already existing. The JCP defines its own operation and the standards by which it is regulated, standards that have been evolving since its creation in December 1998. The current JCP version is version 2.6.

New technologies are incorporated into the Java platform through the JCP, by means of a "Java Specification Request" (JSR). In order to create a JSR, the need for the new technology or for the modification of an existing technology must be explained in a document, along with how this change will affect the rest of the platform. Although it is not necessary, it is also recommendable to propose a group of experts who will take charge of developing the JSR, if this is accepted. Anybody, whether or not is a member of the JCP, may propose new JSRs.

In this manner, the open and coordinated evolution of the standard is guaranteed, without the impositions of a single manufacturer. This constitutes a guarantee of stability over the medium and long term when it comes to selecting this platform as against other possibilities.

Below is a more detailed description of the J2EE platform reflecting its capacity to accommodate SOA services.

SOA CONCEPTS

“SErvicE OriEnTEd ArchiTEcTUrE (SOA) iS in ThE prOcESS Of implEmEnTATiOn

in ThE lEAding cOmpAniES On ThE mArkET.”

JSP Review &EC Vote

Early Draft

Expert Group Formed

Early DraftComplete the Specification

Public Draft Final Release

Public Review

EC VoteProposed Final Draft

Final approval Ballot

Final Releae

Maintenance

Maintenance Review

EC Item Exception

14 days

30-90 days

30-90 days

last 7 days

14 days30 days

last 7 days

1 2 3 4

Vote

divErSE STAgES ThrOUgh which A JAvA SpEcificATiOn rEqUEST pASSES

5

J2EE cOmpOnEnTS

Distributed applications require access to a serie of company-hosted services. Typical services include transaction processing, high availability and load balancing, access to databases, messaging, multi-tasking and multi-threading, etc. J2EE architecture unifies access to these services in a service API. Nonetheless, instead of having to access these services over a customised or non-standard interface, application programs based on J2EE are able to access these APIs through the J2EE container.

A typical J2EE platform (or J2EE applications server), whether commercial or free of charge, includes one or more containers, and access to company APIs is determined by J2EE specifications. These define the multi-layer execution environment and provide the specifications that facilitate the developers’ work for each layer. Within the presentation layer we find specifications such as servlets, JSP (Java Server Pages), JSF (Java Server Faces), whereas in the business layer, the main specifications are those defining the structure and behaviour of reusable objects (components) called Enterprise Java Beans (EJB). In addition, there are specifications regarding, among other things, database access (JDBC), directory service access (JNDI), SMTP messaging service (JavaMail), access to a Message Oriented Middleware or MOM (JMS), access connectors to legacy environments (JCA), connectivity between objects lodged in the same machine or in others (RMI and RMI-IIOP, which maintain compatibility with CORBA), and a long line of others.

The objective of the J2EE platform is to permit programmers to concentrate as far as possible on the specific details of business and to delegate low-level services (transactionality, concurrence, security, persistence, high availability, monitoring, integration, transparency with regard to location, etc.) to the container. J2EE architecture, and more specifically EJB, aspires to solve this type of problems by substituting the programming of this type of low-level service with their declarative syntax. Their encapsulation as components favours their reuse or substitution with a lower level of impact. The container takes charge of maintaining the life cycle of the objects created.

Basically, J2EE may be understood as a set of standardized APIs for working with technologies that have been around for a long time as distributed

transaction coordinators (DTCs), messaging systems (message queues), models of objects distributed (ranging from RPC, through DCOM or CORBA up to Java’s own RMI), transaction monitors (like CICS or TUXEDO), etc. J2EE has not invented anything new in this sense, but simply defines a standard way of accessing previously dispersed functions that obliged developers to depend on specific suppliers. J2EE changed this restriction, permitting competence between companies and giving rise to new business models, such as those based on the offer of free, open-code J2EE platforms, where benefits are not obtained from the sale of user licenses but from consulting or support services.

“ThE OBJEcTivE Of ThE J2EE plATfOrm iS TO pErmiT

prOgrAmmErS TO cOncEnTrATE AS fAr AS pOSSiBlE On ThE

SpEcific dETAilS Of BUSinESS And TO dElEgATE lOw-lEvEl

SErvicES TO ThE cOnTAinEr.”

6

cOnSTrUcTiOn Of ThE SOA SErvicE lAyEr in J2EE

The advent of SOA brought the world of IT a conceptual evolution in the manner of tackling interconnectivity between applications and components, rapidly giving rise to new services of a higher level. J2EE did not ignore this movement and included several aspects regarding web services in its J2EE 1.4 specifications. Web services are the elements that make up SO architecture.

One characteristic that differentiates web services from other J2EE specifications is that these are designed to present interfaces based on independent open multi-platform protocols belonging to the manufacturer, while at the same time providing a vehicle for building interconnected services, with the added advantage that these were loosely coupled.

Thus, an SO architecture may be divided into four layers, as against the traditional three layer arrangement:

> Presentation> Service> Business> Persistence The service layer is marked by the characteristics of loose coupling and completeness. J2EE provides a complete platform on which to build the service layer in an SO architecture through web service APIs, among which JAX-RPC and JAXP stand out.

JAX-RPC provides a simple, stable platform for building and deploying applications that use web services, concealing the complexity of mapping the correspondence between XML and Java data types from the J2EE developer. In addition to the details of low level management of SOAP and JAX-RPC messages, it introduces a new paradigm that offers two programming models: one server-side model for developing supplier web services using Java classes or stateless EJB session components, and one client-side model for creating consumers who may access the web services as local objects.

JAX-RPC 1.1 establishes the use of the standard SOAP 1.1 protocol, permitting interoperability with web services done in other technologies such as Microsoft .NET.

Support for JAX-RPC is included among the principal application servers compatible with J2EE 1.4, such as (in alphabetical order) Apache Geronimo 1.0, BEA Weblogic Server 9.0, IBM WebSphere Application Server v6, Jboss Application Server 4.0, Jonas ObjectWeb 4.4, Oracle Application Server Containers for J2EE 10g (OC4J) 10.1.3 and Sun One Application Server 8.

Interoperability is one of the key aspects of service oriented applications. In order for services to be interoperable, they must be able to communicate not only with other J2EE platforms, but also with implementations based on other technologies such as .NET. Once a web service has been deployed and its existence published, registered for instance in a directory service (such as UDDI), any client may find it and invoke it. Hence, it is impossible to anticipate the type of client that will act as service consumer.

In consequence, it must be ensured that the web services created comply with the standard WS-I Basic Profile (Web Services Interoperability Basic Profile). WS-I is an open consortium of suppliers such as Oracle, IBM, Microsoft and Sun who emphasize interoperability between the web services of different platforms, operating systems and languages. J2EE 1.4 establishes compatibility with the WS-I Basic Profile as a requirement for the certification of an applications server, which means that the applications server must generate interoperable web services.

“SOmE Of ThE mEmBErS Of OASiS fOrm pArT Of ThE Jcp

(Java Community ProCess). ”

7

SEcUriTy in wEB SErvicES

Due to the dissemination of web services and their rapid adoption in the framework of e-business, information technology companies have found themselves confronted by the need to introduce aspects relating to security in web services that go beyond what is set forth in the WS-I Basic Profile. This has affected all service providers, not only those centred on J2EE. During an initial phase, every software manufacturer (Microsoft, Sun Microsystems, IBM, etc.) had its own security implementation, creating a climate of confusion in this regard while awaiting the deployment of a de facto standard.

Regardless of the business problem to be resolved by the web service, it is necessary to tackle the same problems of security that exist in the technologies of distributed integration or computing. Problems relating to security are fundamentally as follows:

> The client must be authenticated with respect to the server.

> The server needs to be authenticated with respect to the client.

> It is necessary to guarantee the integrity and confidentiality of the messages exchanged.

> It is necessary to guarantee non-repudiation of the transaction.

> It is necessary to determine a client's rights of access, verifying not only his identity, but also his level of authorization against internal access control policies.

Security mechanisms based on HTTP are insufficient, since there are scenarios involving the dispatch of messages in dialogues more complex than that of the simple petition/response pattern; for example, over intermediary routes. Transmissions without the intervention of HTTP also exist (such as web services over SMTP or message queues). HTTP and its security mechanisms (SSL and HTTPS) solely respond for point-to-point security. It is necessary for more complete solutions to incorporate an end-to-end security concept. The identity, integrity and security of a message and its sender must be protected in the different kinds of transactions, including those scenarios. Throughout the route, it is possible to use various encoding keys. Domains of confidence may intersect with each other. These needs are enumerated below, and an analysis is made of up to where these may be resolved with SSL:

Authentication: Implementing digital certificates on the server resolves the problem of its authentication. By configuring this server, it is possible to require the client to present his own certificate, thus performing mutual authentication.

Encryption: The information transferred is encrypted by means of a key (generated during the SSL negotiation) using a symmetrical key algorithm capable of encrypting large volumes of information in very little time.

Integrity: The unnoticed passage of intentional or accidental modifications in the information as it travels through internet is impeded. This is achieved by using an asymmetric encryption key employing a MAC (Message Authentication Code). This MAC would be the hash summary of the message concatenated by a secret SSL session number shared between the client and the server.

Non-repudiation: In order to solve non-repudiation, it is necessary to resort to the electronic signature of transactions. This is achieved thanks to the WS-Security specification that describes a standard way of signing SOAP messages, since SSL does not resolve this security problem.

WS-Security deals with a way of ensuring a secure context by means of a multi-point message route.

The WS-Security specification includes a standard set of SOAP extensions that make it possible to secure a web

“ThE wEB SErvicES crEATEd mUST cOmply wiTh ThE

Ws-i BasiC Profile STAndArd, which rEvOlvES ArOUnd ThE

inTErOpErABiliTy Of wEB SErvicES.”

8

service in order to guarantee integrity and confidentiality. This in turn is open to other security models including PKI (Public Key Infrastructure), Kerberos and SSL. WS-Security provides support for multiple security tokens, multiple formats of electronic signature, multiple secure domains and multiple encryption technologies.

The specification includes the propagation of security tokens, message integrity and confidentiality. Nonetheless, these mechanisms by themselves alone do not cover all the aspects of a complete secure solution. Thus, WS-Security represents only one of the design layers of a sophisticated security solution for web services.

The WS-Security specification is one of the first standards among web services to support, integrate and unify multiple security models, mechanisms and technologies, permitting a great variety of systems to interoperate neutrally in what refers to language and platform. Organisms such as OASIS and different companies have participated in its definition. In April 2002, Microsoft and IBM created a roadmap for WS-Security called “Security in a Web Services World: a Proposed Architecture and Roadmap”. In September 2002 WS-Security v1.0 was published and it was approved in April 2004.

WS-Security tackles the theme of security making use of existing specifications and standards. This circumvents

the need for defining a complete security solution in WS-Security, as it takes advantage of the fact that the industry has already resolved many of these problems.

> Kerberos and X.509 take charge of the subject of authentication. Likewise, X.509 uses the existing public key infrastructure (PKI) in administering keys.

> XML Encryption and XML Signature describe different forms of encrypting and signing the content of XML messages.

> XML Canonicalization analyses ways of preparing XML for the process of signing and encryption, such that the introduction of changes in format (carriage returns, blank spaces, tabulators) does not pose any problems.

What WS-Security contributes to existing specifications is a framework in which to incorporate these mechanisms to a SOAP message. This task is carried out neutrally with respect to the transport protocol.

WS-Security defines a SOAP heading element for the transport of data related to security. If XML Signature is used, this heading may contain the information defined by XML Signature that transmits the signature algorithm of the message, the key used, and the resulting value of the signature. Likewise, if an element of the message is encrypted, the information regarding this encryption, such as, for example, that transmitted by XML Encryption, may be included in the WS-Security heading. This does not specify either the format or the encryption of the signature, but rather determines the mode in which the security information contributed by other specifications may be incorporated into a SOAP message.

Fundamentally, WS-Security is a specification for a security metadata container based on XML.

Apart from making use of other existing authentication, integrity and message privacy protocols, WS-Security specifies a mechanism for transferring simple user credentials through the UsernameToken element. In order to send binary symbols used for encryption or message signatures, the BinarySecurityToken element is also defined. Messages can store information regarding the caller and the mode in which the message was signed and encrypted in this heading. WS-Security presents an end-to-end solution for web service security that preserves all security information in the SOAP part of the message.

Applying security to web services

SOAP message security level(WS Security)

Transport channel security (SSL)

Example:Encryption of entire message (for HTTP this means encrypting the entire HTTP message)

AuthorizationExample:

Username Password

ConfidentialityExample:

Message encrypting

IntegrityExample:

Security token

9

inTErOpErABiliTy in rElATiOn TO SEcUriTy And pOSSiBlE prOBlEmS

There are instances of existing WS-Security implementations in commercial products such as IBM WebSphere, Bea Weblogic Server, SUN JWDP (Java Web Services Development Platform), among others, or in open-code products such as the Apache WSS4J extension in the case of Java, and in the WSE extension in the case of Microsoft, distributed separately on Microsoft .NET Framework 1.1, but already fully incorporated into its version 2.0.

In theory, the purpose of all these implementations is to adhere to the specification standard and ensure interoperability, fundamental when dealing with SO Architecture, in which heterogeneity is usual. Unfortunately, at present, maturity is still insufficient in this regard, and it may happen in a real scenario that a product implements a concrete version of the specification, while the other end follows a different version or an errata of the specification, continuing to raise questions about interoperability in this field. Nonetheless, rapid advances are being made in this connection.

This problem is illustrated by a specific example below:

Given a scenario with the products IBM WebSphere 6.0 and Microsoft WSE 2.0 SP3 (the principal founding members of OASIS), it is verified that, in principle, both support the same version of WS-*, SOAP, and WSDL specifications. Three basic scenarios of WS-Security supported by these products are presented below.

1. Use of UsernameToken for client authentication. Here it is seen that both products are interoperable.

2. Signature with X509 certificates: The client signs a request using the private key associated with its x509v3 certificate. The receiver verifies the message signature using the client’s public key associated to its certificate. It is detected that interoperability in this scenario is not 100%, since by default WebSphere 6.0 literally follows an errata in the specification on indicating the value of the BinarySecurityToken element.

3. Mutual authentication with X509 certificates, signature and encryption. Both the client and the server have a certificate representing their identities.Authentication is carried out with each presenting its certificate. The request is signed using the private client key. This in turn encrypts the request with the public key of the server certificate. The response is signed using the private key of the server certificate, and encrypted with the public key of the client certificate which is encapsulated in the response. In sum, typical scenario in B2B communication.

It is observed that in this scenario, it is not possible for the specific products mentioned to interoperate correctly. This is due to the differences between the OASIS WSS X509 Token Profile 1.0 standard implemented by Microsoft WSE2.0 SP3 and the OASIS WSS X509 Token Profile 1.0 non-normative errata followed by IBM WebSphere 6.0. OASIS and IBM also know the problem, and this latter entity plans to publish a fix in the next service pack of its product to enable OASIS WSS 1.0 support.

These types of incompatibilities are being resolved as such new specifications mature and grow in acceptance and dissemination.

The conclusion is that the scenarios in which SO architecture and its applications are implemented should be carefully verified. It is convenient to formulate pilot

April 2002WS-Security

August 2002 WS-Security Addendum

September 2002 WS-Core Draft 1

February 2003 WSS: Usename Toke

Profile Draft 2

May 2003 WSS: SOAP Message

Security Draft 3

OASIS ACTIVITIES

EvOlUTiOn SEcUriTy TO wEB SErvicES

10

projects to verify that problems of interoperability will not arise and, if applicable, to seek assessment from a technological partner experienced in the market situation.

TrAnSAcTiOnAliTy in SOA And J2EE

One of the desirable characteristics of SOA lies in the fact that its components present loose coupling, so that they are able to form part of diverse business processes on the basis of reutilisation without the need for change, preventing too much impact on the process into which they are integrated in case they are substituted by another equivalent component. This requirement has facilitated an evolution in the concept of transactions.

In traditional models, the transaction is carried out within the scope of a specific business, taking different sources of data and the need to maintain the coherence between them into account. In the world of J2EE, this model of transaction is implemented through the JTA and JTS specifications, which define the contract between the transaction managers, the applications and the J2EE containers. These specifications provide interfaces for managing data sources by means of X/Open standards.

In the world of SOA, the definition of a transaction is complicated, due to the fact that, conceptually, the way applications operate in this architecture differs from the way they operate in the traditional model. These differences lie in aspects such as:

> Loose coupling. The loose coupling of its components implies little involvement with the environment. It may happen that an SOA component invokes other SOA components executed in outside companies and that the business process obliges the consolidation of each and every party involved. The case is complicated when the components are lodged in heterogeneous systems and are developed in different technologies.

> Very extensive transactions in terms of time. The concept of transaction isolation applied to transactions that are extensive in terms of time brings several problems with it, such as the possible blocking of resources.

> Optional transactions. Some business processes may require that the failure of one operation will not imply the failure of the entire transaction.

> Propagation of the context of the transaction. If the transaction extends to several organisations, a mechanism for the propagation of the transaction context should be provided.

The previous points underscore that the typical characteristics to a traditional transaction (ACID) are complicated in the case of an SO architecture. Thus, efforts have been made to standardize a scenario that permits the use of transactions within SO architecture.

HOTEL(participant)

AIRLINE A(participant)

CAR RENTAL (participant)

COORDINATOR / COMPOSER

EXPENSIVEAIRLINE B(participant)

OVERBOOKINGAIRLINE C (participant)

Reservation madeReserves

ReservesReservation made

Reserves

Reservation made

Reserves

Reservation

made

Prepares

Unavailable

Atomic set

11

BTp

OASIS defined BTP (Business Transaction Protocol) to coordinate transactions between independent services. The basis of BTP is the fact that none of the parties controls the transaction, but rather, that this is propagated between them and each party decides whether or not to participate in the transaction. If a party opts to join the transaction, it should provide a mechanism for cancelling or confirming this. Each party is responsible for its internal blockages.

BTP uses XML messages sent between the coordinators of each party involved in the transaction in order to function. Two different types of transactions are defined:

> atomic transactions (all the parties are obliged to finish the transaction successfully)

> cohesion transactions (not all the parties are obliged to finish the transaction successfully).

Although BTP is not only thought out for operation with web services and leaves the messaging protocol open, the use of SOAP makes it possible to use BTP in practice in web services. The first industrial implementation of BTP is ascribed to HP, with HP Web Services Transactions (HP WST)

wS-TrAnSAcTiOn/wS-cOOrdinATiOn

Microsoft, IBM and Oracle-BEA on their side defined the WS-Transaction and WS-Coordination specifications to cope with the problems arising from changes of scenario. WS-Coordination takes charge of defining general mechanisms to create, coordinate and record the activities carried out by several web services. Each service creates and records its activity and its coordination protocol.

WS-Transaction/WS-Coordination are oriented towards web services since it is built on the basis of SOAP and WSDL.

Both BTP and this model respond to the same needs, the most important difference between them is that WS-Transaction/WS-Coordination are linked to web services, while BTP has no limitations as to underlying architecture.

WS-Transaction/WS-Coordination define two types of elementary transactions – “atomic” and “business” – the characteristics of which are similar to those of BTP.

JAXTX

J2EE responds to the new needs of transactionality by launching its reference specification, JAXTX. This seeks to isolate the programmer and the J2EE containers from the complications of complex transactions, although this aim cannot be covered in the same way as in the case of JTA/JTS, since this new scenario contemplates that it may be necessary to add application logic in order to deal with these complex transactions.

mOniTOring in SOA And J2EE

One of the most important aspects of an SO architecture is the information monitoring and auditing process. This process may be carried out efficiently in J2EE by means of the JMX (Java Management eXtensions) specification.

JMX is the technology defining management architecture - the API, the design patterns and the services for monitoring and administering Java-based applications.

The application processes, configuration parameters and trace levels may be remotely monitored.

This makes it possible, for example to make the traditionally used focus more sophisticated in order to administer services and applications, making it possible, for example, to make changes to the status/information of a clustered application in the framework of a high availability environment with several servers in cluster. Indeed, the most significant applications servers on the market use JMX technology to manage their own internal processes. IBM, Oracle-BEA, and Jboss, among others, have followed this scheme for their administration architecture.

JMX facilitates the management of applications and services. This technology permits Java developers to integrate their applications with existing management and operation solutions, making it possible to administer (by changing application configuration parameters) as well as monitor these (by obtaining statistics and error notifications from them).

12

JMX architecture defines three levels:

> Instrumentation Level (Application Layer): The application layer (called instrumentation level) is where the components that facilitate the information necessary to administer an application reside. These components are developed in accordance with the management needs of each application. For example, a component may have a method to stop a service within an application.

> Agent Level: The agent level is that which facilitates an interface for the administration of the components of the instrumentation level.

> Adaptor Level: The adaptor level consists of one or more connectors (or protocol adaptors) that provide access from remote monitoring systems.

Managed Beans or MBeans are the JMX objects that present the manageable information in the form of properties and operations. As a previous requirement to the implantation of JMX, the components that perform services that may be subject to instrumentation are codified as MBeans or at least have their interface published in the form of an MBean, such that the invocation of an MBean method updates component status.

There are several types of MBeans (Standard MBean, Dynamic MBean and Model MBean). The selection of one or another must be done according to our needs of instrumentation.

REMOTE MANAGER

CONNECTOR LEVEL

AGENT LEVEL

INSTRUMENTATION LEVEL

JMXManager

WEBBrowser

SNMPManager

Application

SERVER

JmX ArchiTEcTUrE

MBeans MBeans

RMIAdaptor

HTTPAdaptor

SNMPAdaptor

MBean Server

13

EAI (Enterprise Application Integration) is understood as the use of methods, principles and technology to make applications, generally from the Business Support Systems (BSS) environment of a specific company, work together jointly or in an integrated manner. The term EAI, coined during the 90s, has undergone considerable evolution with the passing years, from the original concept of point-to-point connection between the applications and systems in a company to the most recent approaches using web services and the internet to present fully distributed services to companies and clients. Its final objective has always been that of attaining the most flexible, efficient and competitive way of integrating processes between applications in order to provide services to clients.

During the years prior to the start of this technology, connection was resolved by means of point-to-point connections between applications. This highly simple scheme lost its feasibility as the number of applications and services increased.

mOm chArAcTEriSTicS

Of the three principal types of existing middleware – that is to say, Remote Procedure Call (RPC), Object Request Broker (ORB) and Message Oriented Middleware (MOM), we shall focus on this latter as the technology that has undergone a greater expansion over the last few years.

EAI emerged in the knowledge of the problems inherent in the focus on point-to-point connections, whereby it rapidly allied with the concept of messaging – and hence the term Message Oriented Middleware (MOM) – which describes the paradigm by which the applications interchange information through the dispatch of data packets (messages) over a homogenous medium (middleware).

Message Oriented Middleware introduces a fundamental concept when it comes to focussing on and resolving application integration. This concept is Asynchronous Communication.

Asynchronous Communication provides a certain degree of freedom to the applications participating in the integration, since they do not oblige any application

to wait for certain information if this is not available at the moment of consultation. In this way, the applications can continue to resolve other tasks and even attend to other clients while the consultation being made is resolved.

The manner in which asynchronous communication is resolved within a MOM accounts for the difference between the two fundamental philosophies of presentation middleware at present. These two tendencies are message queuing and message passing.

Message queuing is defined as a model of indirect communication in which the communication takes place over a queue. Messages coming from a specific application are sent to a specific queue, which is identified by its name. Once the message has been stored in the queue, the queue manager takes charge of conveying it up to the application of destination. The message passing paradigm is associated to a mechanism of direct communication, since the information is sent to the applications that require it without the participation of any intermediary element.

SOA IN EAI

“middleWare introduCes A fUndAmEnTAl

cOncEpT, ASynchrOnOUS cOmmUnicATiOn.”

14

One characteristic proper to systems based on message passing is the capacity to implement publication/subscription mechanisms. This publication/subscription based paradigm makes it possible for a group of applications interested in specific information to subscribe to the said information. The application that issues the information publishes it under a specific “topic” or “subject” agreed upon with subscribers, such that the message reaches the appropriate addressees.

The publication/subscription paradigm introduces another fundamental concept when it comes to working with the integration of applications in real time. This concept is that of event, and refers to that occurrence that accompanies the reception of a message to which a certain action has been associated.

The messaging-based model gives EAI with the capacity to connect to the services provided by the

applications in an organised manner, thus building a Service Bus. The most puristic definitions of EAI contemplate the interconnection of applications with the medium and the management of message exchanges as its sole responsibility. Nonetheless, this perception has been expanding and currently also includes the feature of orchestration.

“EvEnT OriEnTATiOn And rEAl TimE ArE fEATUrES

prOvidEd By ThE pUBlicATiOn/ SUBScripTiOn pArAdigm.”

AGENT CALL CENTER CRM BPA

ADDRESSED SySTEM 1

ADDRESSED SySTEM 2

Search for client Search for client

Gather client data

Create Client

Send confirmation

to client

Send confirmation

to client

Create Client

Create Client

Send confirmation

to client

Create Client in System 2

Does it exist?

DEFINITIONS

Business Process (User)

Business Activity

Integration Business Process

YESNO

Error?

User interaction

Business service application

Business service integration

Error?

Create Client in System 1

BUSinESS prOcESS

15

ADAPTOR

EAi ArchiqUEcTUrE

Typically, the basic architecture deployed to integrate EAI based applications consists of positioning a series of connectors or adaptors that connect the applications to be integrated into the integration bus with an orchestrator or BPA (Business Process Automation) mechanism, the component charged with performing the transformations and message passing paradigm in accordance with the rules established for the execution of the Business Process.

BPA has been fundamental in advancing EAI, more specifically, its implementation in company integration suites. The capacity that these tools provide to design business processes such as the orderly and conditioned execution of the services provided by the different applications has revolutionised the development of application integration projects, enabling them to achieve very high performance levels.

BPA permits the reception of a high-level definition of a business process and its rapid implementation on the basis of UML-based schemes.

The figure of the page before, 'Business Process', presents an example of a Business Process and shows how this would be schematically represented within a BPM tool.

As may be observed in the figure at the foot of the page, EAI is currently built around diverse components and tools that transcend the simple concept of application integration and provide facilities for the management, deployment and maintenance of integration and development. These elements are what comprise the current Integration Suites.

“BpA hAS BEEn fUndAmEnTAl in AdvAncing EAi.”

APPLICATION 1

ADAPTOR

APPLICATION 2

ADAPTOR

APPLICATION 3

ADAPTOR

APPLICATION 4

SERVICE BUS

Monitoring and Control

Business Activity Monitoring /

Complex Event Correlation

Business Process Management

Business Process Automation

Deployment and management

Configuration and Status

Repositories

cOmpOnEnTS Of An inTEgrATiOn SUiTE

16

The role played by the business process manager in resolving automated processes has already been set forth. A further step in the search for the total integration of company procedures incorporates elements that are capable of administering long-term processes where human intervention generally occurs. The workflow facilitates the elements necessary to manage these processes and, furthermore, introduces the pertinent layer of information persistence required to recover the status of the process the moment it is reactivated.

The current tendency in the evolution of integration suites is the incorporation of BAM (Business Activity Monitoring) and CEP (Complex Event Processing) tools. BAM permits business analysts to collect and present information about the execution of the business processes integrated by the company in real time. Statistics are measured by means of the identification of the Key Performance Indicators (KPI). The KPIs are distributed along the strategic points of the business process and provide the information that the BAM needs to prepare the pertinent reports.

Lastly, CEP makes it possible to capture events in real time and correlate them to determine events on the Bus. One of the main applications of CEP is to detect regular deficiencies in the service and determine the adoption of immediate compensatory measures to maintain degree of client satisfaction.

Modern tools provide the management capacity for complex application integration projects through the use of the proper version of the elements developed, facilitating the deployment of development. The start-up and configuration of the different elements making up integration development is performed from a centralised console with access to all the network servers belonging to the Service Bus.

The observation of the physical parameters of each server as well as of each process or application executed to support to the business processes making up each and every one of the applications is supported by the monitoring consoles, which present differing solutions. Currently, moreover, monitoring of the business process in course is supported, such that if there were a failure in the execution of a specific petition in a business

process, the execution status of the said process would be stored for its subsequent recovery. From this point onward, the supervisor can be informed of the reasons why the exception occurred and can take the appropriate measures to draw up an incident report for the interested parties capable of resolving it. These tools in turn provide facilities for obtaining the message data and manipulating these in order to recover the process and continue its execution from the point at which the incident occurred.

“ThE cUrrEnT TEndEncy in ThE EvOlUTiOn Of inTEgrATiOn

SUiTES iS ThE incOrpOrATiOn Of BAm And cEp.”

17

ThE AdApTOr

The connection with the services provided by the applications takes place over the connectors or adaptors of each application. The adaptor is a part that may be supplied by the manufacturer, developed by a third company or custom-built on the basis of the development kit supplied by the manufacturer.

The preceding figure shows the main components of an adaptor, which are as follows:

> Modules for adaptor start-up and stoppage.> Module for loading configuration from the record or

repository.> Module for managing event loops.> Container module for services or call-backs that

provide the functionality necessary to resolve a bus Business Service.

> Trace management module.> Monitoring module.> Error management module.

The adaptor specifically adapts to each application as it incorporates the mechanism through which it establishes contact and accesses the services that the application wants to present. It likewise provides the communication mode between the service bus and the application, such that those services that are defined in the adaptor container become public and thus may be invoked from any other application connected to the service bus, as is shown in the following figure.

The adaptor, on another hand, is the tool that establishes the relationship between channels, subjects or topics, and the application services, as the mechanism by which the services become public. The adaptor acts as a bridge between the independent worlds of the application and the Service Bus, translating between protocols in order to establish communication.

wEB SErvicES

The recent rise of web services has brought about a clear convergence of integration suites towards the principles on which this technology is based. In consequence, all the principal manufacturers of integration suites within the scope of EAI have incorporated SOAP (Simple Object Access Protocol) and its interfaces for permitting WSDL (Web Services Description Language) service definition and coupling between them from other applications.

Nevertheless, web services go much further beyond the mere definition of new service access protocols and their service definition language. As is set forth in the next figure, Web Services define a series of standards to implement the operability necessary to provide access to the services.

“ThE rEcEnT riSE Of wEB SErvicES hAS BrOUghT ABOUT

A clEAr cOnvErgEncE Of inTEgrATiOn SUiTES TO ThiS

TEchnOlOgy.”

Trace Management

Monitoring

ADAPTOR

Start-up Manager

Event Loop

Stop Manager

Configuration Manager

Service Container

CONFIGURATION

18

The standards of communication (SOAP) and interface definition (WSDL) have been rapidly assumed and incorporated into integration suites, due in part to the maturity of their specifications. This notwithstanding, the register of services continues to be a pending task in which, at present, the Universal Description, Discovery, and Integration (UDDI) standard has not enjoyed the same degree of acceptance as its other two companions.

As a result, integration suites have resisted the incorporation of implementation elements that would provide the cataloguing and registration capability of services such as are specified in UDDI, and it is only very recently that they have begun to opt for largely individual solutions, partly due not only to the incorporation of web services as an alternative for application integration, but also to the fact that SOA implantation based on EAI has reached considerable volumes and that the service suites implemented in companies are requiring a significant management effort since they are not completely automated.

SEcUriTy in EAi In the SOA model, applications are integrated to the business service producer applications and the responses that these provide by means of message dispatches. Normally, applications are distributed on different machines, possibly belonging to several network segments, which fact facilitates possible attacks against authenticity, confidentiality and the integrity of the information exchanged.

For this reason, it is necessary to protect both the message dispatch to producers and the responses that these producers provide the consumer, in such as way as to guarantee the identity of whoever is sending a message to the information bus (authenticity), to ensure that no unauthorised party may have access to message contents (confidentiality) and to assure that no one can modify a message in transit without this being detected (integrity).

Regardless of the security measures adopted to protect the machines on which the applications and the measures designed to protect communications between them reside, applications must adopt their own mechanisms to protect information. These mechanisms will include the encryption of the information, digital signatures, or the codes guaranteeing message integrity.

It must be pointed out that these protective mechanisms imply a slowdown in message processing that can become considerable, such that they should be applied only when necessary.

Following is a description of these mechanisms and how to apply them in the development of SOA.

“ThE EncrypTiOn mOdUlE

inTErcEpTS ThE mESSAgES EXchAngEd BETwEEn ThE

ApplicATiOn And ThE ESB And dETErminES whEThEr Or nOT

ThESE ShOUld BE EncrypTEd.”

REGISTER OF SERvICES

SERvICEPRODUCER

SERvICE CONSUMER

Find Publish

Link

UDDI

WSDL

SOAP

19

With a view to securing integration through SOA services, EAI requires the following components that, on occasion, may be included in the existing middleware:

> A module providing an API for access to security functions such as encryption/deciphering of messages or of the digital signature in messages.

> A module charged with message encryption through the security API. This module shall have facilities for the selection of the encryption policy to apply to each message type. Depending on the characteristics of the platform employed, the module may form part of the ESB itself, may be located in the connectors, or, if neither of the previous options is possible or a modification in its functional characteristics is desired, it may be developed on a specific proxy.

> A module providing access control list (ACL) mechanisms, both with regard to list administration (list creation, modification, deletion) and list access on the part of the applications (consult user permits).The following figure shows the security scheme to employ in integrating applications to SOA, along with the three possibilities for invoking the Security API.

The need for an existing connectivity between the applications and the ACL management module in order to execute access control tasks should be taken into consideration in this scheme.

“SEcUring ThE SErvicES rEqUirES SpEcific SEcUriTy Apis,

mOdUlES fOr EncrypTiOn And Acl AccESS And mAnAgEmEnT

mEchAniSmS.”

APPLICATION 1 APPLICATION 1 APPLICATION 1

CONNECTOR CONNECTOR CONNECTOR

SecurityAPI PROXy

HOST A HOST B HOST C HOST D

ACL

CONNECTOR

ACLDB

ESB

SecurityAPI

SecurityAPI

cOmpOnEnTS Of An inTEgrATiOn SUiTE

20

Api for Security functionsThis API provides the services of message confidentiality, authentication and integrity and makes it possible for these services to be included in the applications, more specifically in the connectors linking the applications to the ESB.

The API conceals the implementation details of the security services from the application developers, such that application programmers centre on the implementation of their functions, leaving the security personnel to configure security requirements (encryption algorithms to use, length of keys, etc.) and user access privileges.

Normally, APIs may be used in two different ways:The programmer may explicitly invoke the security services provided by the security API, such as for example, the encryption and deciphering of every message sent or received.

It is possible to opt to perform these security operations implicitly, such that programmers limit themselves to sending and receiving messages over a secure medium of transport.

module for message EncryptionThis module intercepts the messages exchanged between the application and the ESB and determines whether or not these should be encrypted. Where the module is integrated into the ESB itself – specifically in the message broker – the messages are encrypted or not depending on the type of message

mESSAgE BrOkEr-BASEd SEcUriTy

The message broker is the element that sends or receives information between the connector and the ESB.

This component can be capable of establishing secure channels between systems and thus depositing duly encrypted information in the ESB. One example of this would be the use of SSL in TCP/IP to perform the information exchanges.

The direct use of this mechanism implies the encryption of all the data contained in all messages. Consequently,

to be able to consume the information supplied through this mechanism, all the systems must be mounted on the same security paradigm.

A refinement to this mechanism would be to deploy a tool kit permitting the configuration or programming of this message broker, such that only certain messages are encrypted, on the basis, for instance, of channel or topic used for publication.

Encryption would thus be more selective and it would not be necessary for all the systems to be included among the secure channels, thus reducing the load that the encryption of all information may imply.

In the preceding figure, the message broker is represented by the segment of ESB belonging to each host.

cOnnEcTOr-BASEd SEcUriTy

Normally, this case arises in the developed connectors in which it is easy to include a security management module. Its advantage in comparison to message broker-based security is that it is easier to control which parts of messages should be encrypted and which parts should not.

“AdminiSTrATiOn ThrOUgh Acls mAkES iT pOSSiBlE

TO AUThEnTicATE SErvicE BUS AccESS, ApArT frOm AUThOriSing ThE USE Of

SErvicES On ThE BASiS Of cliEnT idEnTiTy.”

21

SEcUriTy BASEd On ThE prOXy BETwEEn cOn-nEcTOrS And ThE ESB

The use of security proxies is a specific case of connector-based security that will be indispensable where connectors that do not support security services are employed, as well as connectors in which no development is to be done that will permit the incorporation of such services.

The proxies will have the following characteristics:

> Security proxies will be installed in all those machines housing applications that need to secure message transmission.

> Each application needing authentication shall have its own security proxy for exclusive use. This is due to the fact that the proxy may use digital certificates that authenticate the proxy with respect to the ESB.

> Each security proxy shall have a different identifier that is unique in the network.

> The communication channel established between applications and their security proxy must be protected.

> The proxy will make use of the security API to protect messages before sending them and to remove the protection from messages received.

> The proxy must be able to record the information about messages sent and/or received.

ThE Acl mAnAgEmEnT SErvicE

This service is a server process that distributes security information to the applications connected to the ESB. This information is managed by the security administrator and is based on the establishment of relationships with users (roles) and user groups with access permits.

The security information will refer solely to user authorisation for access to certain resources. TrAnSAcTiOnAliTy in EAi

CAs has been previously remarked, the clear event orientation of EAI leads it to dispense with storing status reports, or at least to do so only to a very restricted

extent, so as not to affect its response time and comply with the “real time” maxim.

This characteristic accounts for transactionality not being one of the mandatory points to comply with in suites that implement EAI, but rather, being an optional feature which, at times, may even have to be resolved by bringing in solutions belonging to third-party manufacturers.

It may certainly be said that there are EAI solutions on the market that provide transactionality as a serial feature, but in fact, these solutions are not EAI solutions properly said, but rather, transaction monitors, used for their capacity to connect to databases in order to perform application integration through data exchange.

These solutions do not present the characteristics proper to EAI as we have described it in previous chapters, but even then, they may be used to implement service oriented architecture, albeit in a very basic way.

Currently, integration suites admit the creation of transaction islands within their business processes. A transaction island is a container that holds all the transactions or operations with other systems that require compliance with ACID paradigms (Atomicity, Consistency, Isolation, and Durability). This means that the process imbedded into the transaction container will be carried out only if it is possible to successfully perform each and every one of the actions inside the container. Otherwise, the container itself is charged to perform the roll-back actions necessary to undo the operation and restore the entire system to its status prior to the beginning of the transaction block.

“inTEgrATiOn SUiTES USE TrAnSAcTiOn mOniTOrS ThAT

implEmEnT ThE XA STAndArd TO prOvidE TrAnSAcTiOnAliTy TO

BUSinESS prOcESSES.”

22

Integration Suites use transaction monitors that implement the XA Standard to provide transactionality to those business processes that require it, such that when the BPA reaches a transaction block in the course of executing a business process, it cedes execution to the transaction monitor, which is the element that resolves that specific part of the process.

XA is the protocol proposed by X/Open for the management of transactions in distributed environments (Distributed Transaction Process, DTP), as it is reflected in next figure, and proposes the interface to follow in order to effect the connection between the transaction manager (TM) and the resource managers.

Noteworthy instances of the implementation of this protocol may be found in CICS, Tuxedo and JTA. Lastly, solutions have appeared on the market that implement object oriented transaction processing monitors, as may be exemplified by OrbixOTM based on CORBA, MTS based on DCOM and Encina based on DEC.

It is nonetheless necessary to indicate that the transactionality is only valid for those applications and systems compliant with the XA Standard. Typically, these applications are the database managers, and at present, many applications forming part of company infrastructure are based on client/server models, making it rather difficult to maintain these principles.

When the applications, or resource managers according to the scheme set forth by XA, do not observe these principles, it is impossible to comply with the guidelines established by DTP, and consequently, it is necessary to attempt to execute a transaction roll-back through the adequate organisation of the business process, by implementing the pertinent rules that undo that part of the procedure that has been executed.

“if ThE ApplicATiOnS inTEgrATEd dO nOT cOmply wiTh ThE XA

STAndArd, iT iS nEcESSAry TO rESOrT TO prOcESS EnginEEring

in OrdEr TO mAnAgE ThE cOnSiSTEncy Of OpErATiOnS.”

APPLICATION 1

TRANSACTIONMONITOR

RESOURCE MANAGER

The application uses the resources of a set of managers

1 The application defines the requirements of the transaction with the Transaction Monitor Interface (TX)

2

The Transaction Monitor and the Resource Managers exchange information over the XA interface

3

cOncEpTUAl viEw frOm X/OpEn’S dTp mOdEl

23

The leading software manufacturers are directly involved in the processes of defining the new standards that guide the development of IT.

Each of them implements the standards defined in its own way, enriching their functions with respect to the functions of other manufacturers, competing so that their products may be the winners… and Microsoft is no exception. Its involvement in the adoption of XML as a support for communication between systems is shaping up as a winning option.

Along with the principal software manufacturers, Microsoft belongs to the consortium called OASIS, an organisation set up for the purpose of developing and orienting the adoption of new IT standards.

XML support may be found in all Microsoft products. Due to broad acceptance on the part of other manufacturers, every day there are increasingly more language specifications for the exchange of information based on XML. Many sectors have their own specific languages: the health sector has the new version of HL7, the chemical sector has CML, the graphic design sector has SVG or SMIL, and XBRL exists for the financial sector. Every field has an XML base, whether in an original version or a new version.

Microsoft maintains its other tactic, namely, simplicity in the handling of its tools. For this purpose, it continues to facilitate the administration and configuration of all its products from user-friendly interfaces, contributing SSO mechanisms throughout its technological platform and making other software manufacturers seek compatibility in their products, not only with the J2EE platform, but also giving support to the .NET platform.

wOrking wiTh SErvicES

In order to consume a service, it is necessary to have a client that acts as a service requester. The client generates a message containing the request and waits for another message containing the response.

Depending on the service interface, the request and response messages will be encapsulated according to the channels or protocols used for communication, all

the while that their content will always remain the same, regardless of the transport. And… how do we publish our services?

When it comes to publishing a service, it is possible to opt for different alternatives depending on how the service is going to be used. Depending on the platform on which the clients or consumers of the service are executed, it may turn out to be of more or less interest to think about publishing the services in the server GAC or in SOAP. If all my applications that consume the service are developed on .NET, the easiest workaround would appear to be to register the assembly containing the function in the GAC so that other applications may use it automatically. But what happens when the consumer is not executed on the .NET Framework? There may be applications developed in other technologies that cannot use this Framework resource. The new standards indicate that web services have an advantage over other forms of publication, and their adoption on the market is, without a doubt, the best support that they can rely on.

wEB SErvicES

Microsoft clearly backs a web service oriented platform based on XML. This medium for publishing services makes it possible for any platform capable of generating a SOAP request to consume web services developed on a different platform.

“micrOSOfT, AS A fOUnding mEmBEr Of OASiS, pArTicipATES

in dEfining All TypES Of STAndArdS lArgEly rElATEd TO

SErvicE OriEnTATiOn.”

SOA IN .NET

24

Using two of the most widespread technologies currently in circulation – communication by hypertext transfer protocol (http) and message structuring by means of XML – web services are similar in certain aspects to .NET Remoting, over which they have a crucial difference: the potential for interoperability with other platforms. While the implementation of a service through .NET Remoting implies that the consumer process must be executed on the .NET platform, the use of web services enables any execution platform other than .NET that manages SOAP/HTTP to invoke the services. Doing so requires the adoption of three standards already mentioned: SOAP as communication protocol, WSDL for the description of the functions offered by the web service and, optionally, UDDI for the business catalogue based on XML lists.

In addition, there are a large number of specifications regulating the evolution of web services. These specifications affect transactions, security, messaging, etc.

As a complement to the discovery of web services in the absence of a UDDI catalogue, Microsoft offers the function of dynamic discovery through the Discovery protocol. The definition of the web service container in a WSDL file is only useful when we know how to locate and use it. Where there is no service catalogue such as UDDI, the files of the Discovery protocol may be

published in the web server with the .DISCO extension. These can contain both the URL to locate the WSDL file representing the operations of the web service to be invoked and references to other .DISCO files that reroute the request.

In the design phase, if access is had to the implementation of the web service, various Microsoft IDE tools make it possible to generate a web service proxy, in such a manner as to compile the service call. On other occasions, it becomes necessary to invoke the service in a dynamic way, by creating the proxy for invoking the service operations dynamically.

There are other manners of requesting the execution of a service without using SOAP for communication. Microsoft has its own implementation of a messaging system based on message queues, Microsoft MQ. The possibility of using message queues as a communications mechanism adds persistence, a factor that can be crucial on a service platform. When a service is not available, the use of communication mechanisms that provide persistence makes it possible to maintain the information about the request so as to process it when the service becomes accessible once more.

However, when it is necessary to execute more than one service to resolve a business process, how do we

TRANSACTIONS> WS-Coordination> WS-AtomicTransaction> WS-BusinessActivity

SECURITy> WS-Security> WS-SecureConversation> WS-SecurityPolicy> WS-Trust> WS-Federation> WS-Single Sign-On

TRANSACTIONS SECURITy MESSAGING> WS-ReliableMessaging

METADATA> WSDL> WS-Policy> WS-PolicyAssection> WS-PolicyAttachment> WS-Discovery> WS-MetadataExchange

MESSAGING> SOAP > MTOM (Attachments) > WS-Eventing > SOAP-over-UDP> WS-Addressing > WS-Enumeration > WS-Transfer

XML > XML > Namespaces in XML > XML Information Set

SOA prOTOcOlS

25

ensure coordination during execution? By means of transactionality? And what happens to security?Service orchestration may be designed by programming, whereby the developer coordinates the calls to the operations offered by different services. This requires an environment that facilitates the coordinated execution of the services required by the process, that simplifies the management of security on all levels, that brings about the monitoring of the resources employed throughout the execution process and, above all, that is supported by a transaction manager capable of processing several operations as a single transaction unit.

SEcUriTy

Microsoft participates together with Sun in the process of defining the basic specifications for the implementation of Single Sign–On. This type of authentication enables a user to obtain access privilege to several systems through a single petition for authentication.

When several services offered by multiple platforms are executed in a coordinated manner, this way of functioning simplifies security management. Microsoft integrates SSO into its server products (IIS, SQL Server, BizTalk Server etc.), such that once a user is validated against an Active Directory in the domain, he does not have to log in as a user and give his password again when he wants to access a protected resource.

Using the Windows integrated security function, the authentication ticket obtained during initial validation is transmitted to other servers in subsequent requests without the need for the user to log in once more.

mOniTOring

In service oriented architecture, it is indispensable to be aware at all times of the availability of resources and their employment status.

Visual Studio, with its types of System.Diagnostics namespace, facilitates the design and development of parts of the architecture for tracing and auditing, making it possible to configure levels of detail for the information, apply criteria for the consumption of the events generated, or assign different repositories for the logs as MSM Queues, DBs, or text files.

And how are services executed? Visual Studio also offers an extensive set of performance metres that make it possible to obtain service status “shots” indicating memory, consumption, number of execution threads and requests processed… providing a complete perspective that makes it possible to measure service implementation quality on the basis of the resources consumed.

In order to have a thorough knowledge of the status of service provider resources, it is possible to use the advantages of Windows Management Instrumentation. This monitoring infrastructure makes it possible to measure the transaction load that a process requires, the memory consumption involved in the execution of an operation, or its response time.

“ThE pOSSiBiliTy Of USing mESSAgE qUEUES AS A

mEchAniSm Of cOmmUnicATiOnS AddS pErSiSTEncE, A crUciAl

fAcTOr On A SErvicE plATfOrm.”

26

TrAnSAcTiOnAliTy

The execution of a business process that involves the invocation of several services is usually linked to the concept of distributed transactions, the management system whereby all the operations executed in one and the same transactional context may act as a single atomic transaction in which confirmation is performed for all the transactions or for none of them.

Microsoft facilitates coordination of distributed transactions through the COM+ model. Using MSDTC (Microsoft Distributed Transaction Coordinator), it is possible to administer several distributed transaction operations provided that the transaction resource that each operation represents is compatible with the standard specification on distributed transaction management (X/Open XA). This compatibility is enriched by the protocol known as Two-Phase Commit or 2Pc: confirmation is produced simultaneously on all the transaction managers only if all the elements involved are available for the purpose. Once operations have been executed, during the preparation phase, the MSDTC, transaction coordinator asks about the availability of the managers integrated into the transaction context so as to confirm the execution of

the operations. When the response indicating that all the managers are available is received, the confirmation phase is initiated, in which the transaction coordinator sends another message to the managers to perform the confirmation. Should any manager not send a satisfactory response to this second request, all the transactions initiated in the context will be cancelled. The manner of working with the objects that manage transactions was upgraded starting from version 2.0 of .NET Framework. By using the classes of the System.Transactions package, developers will not have to distinguish between objects that will give support to a simple transaction (operations over one and the same connection to a repository) and objects employed to manage distributed transactions in programming.

Developers will not need to know the type of transaction they wish to manage during the design phase. When the first transaction is created, the framework will petition a lightweight transaction designed for simple transactions. When a new transaction is added to the context, the framework will automatically promote the object to a TxTransaction type of request capable of coordinating transactions on more than one transaction manager… all this without obliging the developer to take it into consideration.

“ThE mAnnEr Of wOrking wiTh ThE OBJEcTS ThAT mAnAgE

TrAnSAcTiOnS wAS UpgrAdEd STArTing frOm vErSiOn 2.0 Of

.nET frAmEwOrk.”

ServerSystem 1

ServerSystem 2

ApplicationServer

cliEnT SySTEm

DTC DTC

Resource Manager

Proxy

Resource Manager

ProxyDTC

27

SOA rEAliTiES wiTh .nET

Microsoft has deployed a series of products around the .NET platform using Framework as a context of execution that facilitate the task of implementing SO architecture in companies.

The Microsoft IDE, Visual Studio, has undergone substantial modification throughout its existence. Microsoft offers a set of tools for Visual Studio called Web Service Enhancements as a development component specialised in the design of web services.

Outstanding among its principal features is security management and the adoption of the latest standards related to web services. The new specifications come integrated into the new versions of the package.

Another feature to underscore is the possibility of developing web services without the need to publish them on an IIS. The web services may be deployed on console applications or on Windows services and may be invoked using TCP/IP.

The Yukon project known as SQL Server 2005 demonstrates the influence of service orientation based on the integration of several channel adaptors on SQL servers. By using a new service as a broker, it will permit the queuing of requests for the execution of sentences in asynchronous mode. It also integrates other SMTP messaging services, .NET alerts or http requests – everything necessary to connect database servers to the service bus.

When it comes to linking systems, BizTalk Server is the EAI tool on which the integration platform rests. Thanks to its ease of process configuration, its multiple adaptors – supplemented by routing – and the design of integrated solutions with a visual client, the functionality of BizTalk Server helps when it comes to publishing and consuming services as well as integrating systems or distributing information.

whAT dOES ThE fUTUrE hOld fOr US?

The short-term future shapes the guidelines for service orientation. As it has been said in the preceding section, the new Microsoft product versions share this philosophy, including components specifically designed for adaptation to the new architecture.

Microsoft applications architecture rests on three new pillars: the Windows Communication Foundation, the Windows Presentation Foundation and the Windows WorkFlow Foundation.

indigO: windOwS cOmmUnicATiOn fOUndATiOn

Indigo offers a framework oriented toward service development and integration, clearly defining the manner of consuming the service. The development of a service is much simpler. The interaction between a consumer and the service takes place exclusively over XML. The only restriction in this communication is the service interface itself.

A WCF service will be composed of the class that groups together the functions of the service offered through methods, an application and a process that shape the service execution context, and some points

PROCESS

APPLICATION DOMAIN

METhODS

INDIGO

host

Sevice Class

Endpoints

SErviciO wcf

28

of access to the functions in order to interact with consumers. Communication between the consumer and each function of the service at these points is regulated by a service contract. So as to facilitate the consumption of the service, a series of contracts defining its features is established. There must be at least one service contract through which the consumer may obtain the information necessary in order to construct the call to a service method. On another hand, another type of contract will indicate the data structures that the service manages. Communication with the service will be regulated by a message contract specifying the composition of the message elements. In principle, the elements of a message are the heading and the body, although it is possible to create other elements by means of a contract customising the definition of the message structure. This would give rise to a “typed” message. Indigo services principally employ resources for security, serialization and transaction management… Indigo will functionally replace the development done with web services and .NET Remoting, and will become a fundamental component in the development of services.

AvAlOn: windOwS prESEnTATiOn fOUndATiOn

This is the new programming interface for heavy client applications. Equipped with a package of new controls to increase user-machine interaction, it integrates the new XAML (eXtended Application Markup Language) specification, the programming language for graphic interfaces in both 2D and 3D.

In combination with the usual .NET programming languages, the developer will be able to control programmatically the look and feel of the client application with XAML as though he were working with the styles of a web application, except that the results will be much more attractive.

But this is not the sole advantage of WPF… All applications have to process the information that they handle in one way or another. When the application design separates the data presentation into different layers, it is necessary to manage a link between both sections. WPF has several data management services to facilitate the link and the information management.

Data suppliers will obtain the information from relational or other repository types of XML sources that may be used by developers. This makes possible a client architecture in which the server transmits screens represented in XAML in order to generate controls.

windOwS wOrkflOw fOUndATiOn

Microsoft is planning to incorporate this into its products such as its new operating system, Windows Vista, the Microsoft Office Suite or BizTalk Server, in order to increase its functionality. Its name reflects its function: the management of workflows, understanding workflows to refer to the orderly execution of activities on the basis of business rules.

It provides a set of resources for programmatically controlling the flow of information that the execution of a process involves. It is equipped with a visual designer of workflow processes that will facilitate the task of coordinating the execution of activities using the advantages of the new framework, above all those utilities related to transaction management and service consumption.

Microsoft presents a whole new range of integrated products for developing, implanting and maintaining a highly solvent service oriented architecture, with tools based on common components.

“indigO OffErS A frAmEwOrk OriEnTEd TOwArd SErvicE

dEvElOpmEnT And inTEgrATiOn.”

29

Although J2EE and .NET technologies are the principal options when it comes to implementing an SO architecture, it is normal for companies to have software assets developed in other technologies that it would also be of interest to take advantage of as SOA services.

The said technologies may normally fall into two categories. On one hand, we have the category of legacy technologies (classic or inherited systems), which may be exemplified by CICS/Cobol transaction systems, procedures stored in Oracle databases or applications developed in C or Visual Basic. On another hand, we have the category of relatively minority technologies that represent alternatives to J2EE and .NET, such as PHP or, recently, Ruby, among others.

One of the principal promises of SOA is to permit the use of web services encapsulating the underlying technology in a non-relevant form. Some strategies when it comes to tackling implantations of this type are set forth below.

In the first place, it must not be forgotten that SOA deals with the interconnection of business services. The first step is to correctly identify and select them. These should be services with a relevant business function to the company, an appropriate granularity (a high granularity is not convenient, since each web service invocation implies a certain penalisation due to the transformation and transport of the information), and a self-contained and adaptable character (it must be possible for them to evolve or be substituted by other equivalent services without any impact outside the service; i.e., without affecting the rest of the processes of which they form part).

cicS EnvirOnmEnTS

CICS environments currently enjoy a widespread presence in sectors such as Public Administration, Banking or Insurance, where a significant part of the business services is based on this technology. Two large categories of CICS applications are taken into consideration:

> COMMAREA-based programs. These are programs that receive requests and send responses over an

area of the memory known as the “COMMunications AREA”. The programs may be written in COBOL, PL/I, C, C++, Java, etc. Usually they do not store any status information between invocations (they are stateless) and they delegate transactionality or the security context over a CICS runtime.

> Programs oriented toward invocation from a 3270 terminal. These are programs that receive a data stream along with the user request (which may include characteristics of the input device) and generate a data stream with the response (which may also include characteristics of the output terminal). Every request- response usually corresponds to an interaction between the user and his terminal. The set of programs invoked make up the “conversation” of the user with the application.

Although each transaction or program may be monolithic, it is recommended that these be internally structured with a distinction between these levels:

> Message Adaptor Level (encapsulating the specific communication with a specific client), if one exists

> Integration Level> Business Logic> Data Access Logic

Thus, the adaptation of the program to different clients is facilitated and its capacity for reutilisation improves.

SOA IN LEgACy TECHNOLOgy AND OTHER ALTERNATIvE ENvIRONmENTS

“iT iS nOrmAl fOr cOmpAniES TO hAvE SOfTwArE ASSETS

dEvElOpEd in OThEr TEchnOlOgiES ApArT frOm

JAvA And .nET, And ThAT iT mAy AlSO BE Of inTErEST TO TAkE

AdvAnTAgE Of AS SOA SErvicES.”

30

The need to contemplate certain aspects of the input/output terminal, which is present in the second type of CICS program, is an inconvenience with respect to its utility in services (in which the dependencies of a terminal make no sense). The ideal scenario is for programs only to concern themselves with aspects of context and session.

For this reason, IBM provides characteristics such as Link3270 and BMS (Basic Mapping Support) in CICS Transaction Servers that make it easy to prepare even those programs that have to dialogue with terminals in such a way that they are internally based on COMMAREA, facilitating their use as services.

On another hand, the normal practice is for CICS programs to be the ones setting themselves up as services to be invoked from external clients. They do not, for their part, usually behave as direct web service clients.

Typically, a service residing on a CICS Transaction Server may be accessible over external connectors (for example, CICS Transaction Gateway and the JCA connector), internal adaptors (such as web adaptors or WebSphereMQ, a socket listener, or Java ORB).

To use CICS programs in an SOA environment – i.e., to invoke it from SOAP clients (i.e., web service clients), the normal practice is for the SOAP request to be received by the web adaptor (HTTP listener) or the WebSphere MQ adaptor for CICS Transaction Servers, which pass the request over to the “SOAP for CICS” engine, which in turn processes the headings and establishes context, finally passing the XML message on to a message adaptor, which converts it into a COMMAREA structure. Once the business logic is executed, the response is left in COMMAREA; the message adaptor converts it into XML, and “SOAP for CICS” adds the necessary headings, dispatching the response over the pertinent listener (web or MQ).

IBM provides tools to facilitate the conversion of XML messages into COMMAREA structures and vice-versa in its development suite.

“SOAP for CICS” also makes it possible for CICS programs to act as web service clients, although this is not such a frequent scenario, as has already been indicated.

If the applications server is intended to execute within the mainframe, this must be an IBM WebSphere Application Server. If the applications server is located on another platform outside the mainframe, this may be any J2EE applications server with JCA support (J2EE Connector Architecture), in order to be able to use the CICS Transaction Gateway.

This server would take charge of the tasks of incoming message validation, conversion into the appropriate format for CICS, invocation of the program through the CICS Transaction Gateway, recovery of the response message, and conversion into the output format. The said tasks would be implemented by means of Java servlets.

In the event that our applications server is in the .NET technology, there are similar products on the market such as Microsoft Host Integrator, which make the server environment par excellence accessible to the distribution environments, making it possible to request for the execution of a transaction, pick up the result, and return the response to the consumer.

In this manner, CICS programs take charge solely of the business process, and the rest is delegated to the front-end, allowing for greater flexibility when it comes to incorporating new standards. This also prevents burdening the performance of the CICS environment with additional validation and formatting tasks.

“AnOThEr STrATEgy Of rApid AdApTATiOn TO wEB SErvicES fOr A cicS EnvirOnmEnT mAy

BE TO SiTUATE An ApplicATiOnS SErvEr AcTing AS A frOnT-End BETwEEn ThE SOAp cliEnT And

ThE cicS prOgrAmS.”

31

The following figure summarises the different possibilities formulated:

Given that in companies using a CICS environment, this usually takes charge of the critical transactions of the business, it is important to evaluate carefully whether there will be an impact in performance, in the light of the foreseeable increases in requests and the added overload that enabling access through web services presupposes.

EnvirOnmEnTS invOlving prOcEdUrES STOrEd On dATABASES

In many companies, another large group of software assets are implemented in the form of procedures stored in the database, such as, for example, PL/SQL procedures in the case of Oracle databases.

These stored procedures often reflect business logic that may be offered in the form of services. On another hand, it may also be necessary for the said business logic to invoke other web services external to the database as part of their processes.

Thus, the principal database administration manufacturers (Oracle, IBM, Microsoft, etc.) are incorporating web service runtimes and environments into their products in such a way that codes may be placed in the current databases to act as web service consumers or providers.

The choice of the optimum technological solution for building and starting up these services usually depends on each case, making it convenient to do a prior analysis of a functional as well as technical type that can identify the aspects to be evaluated (granularity, quality of service, security, performance, scalability, etc.). It is highly recommendable to select and prepare a pilot solution.

In the case of Oracle, there are several alternatives to enable the database to operate with web services, either acting as client or as server. Recourse may be taken to low-level libraries such as the UTL_HTTP and UTL_DBWS packages, which make it possible to course HTTP and SOAP invocations. Nonetheless, it is recommendable to resort to the higher level tools made available in the new versions (Oracle 9i and 10g).

To enable an Oracle database to consume web services, it is possible to install the “Database Web Service Callout Utilities” that the manufacturer offers free of charge. These Java-based utilities install the necessary classes to avail of the SOA stack in the database and (using the JPublisher utility) make it possible to generate a Java proxy or a PL/SQL wrapper, on the basis of a description of the service in WSDL format, which facilitates the process of invoking the said service from procedures stored in one or another language.

“in ThE cUrrEnT vErSiOnS Of dATABASE SErvErS SUppliEd By ThE principAl mAnUfAcTUrErS

(OrAclE, iBm, micrOSOfT), iT iS pOSSiBlE TO plAcE cOdES

ThAT cAn AcT AS wEB SErvicE cOnSUmErS Or SUppliErS.”

XML XML XML

Internet, Intranet

CICS/390 APPLICATIONS

WebsphereOS/390

+JCA, CTG

CICSTRANSACTION

SERvER

win, unix

J2EE App Srv+

JCA. CTG

OS/390

cicS/390 ApplicATiOnS

32

If what is necessary is to convert the database into a web service provider, the usual practice is to seek support from an applications server that will act as intermediary. The JPublisher utility also serves to encapsulate database operations, generating a Java proxy class which in turn may be deployed on the said applications server (OC4J) in the form of a web service. The Web Service Assembler is used for this. When a client invokes the web service that is executed in OC4J, the Java proxy class in turn calls the operation from the database over JDBC. The result is converted into a SOAP message and returned to the client.

Upon using the Java proxy generated, the implementation is aligned with the SO architecture proposed by Oracle with its “Oracle Fusion Middleware”. This family of products provides the following advantages:

> Interoperability compliant with WS-I Basic Profile 1.0> Guarantee of delivery as per the WS-Reliability

standard> Security compliant with WS-Security> Web services management over Oracle Web Services

Manager> Integration with Oracle BPEL Process Manager

Although it could be technically possible for the database to be a direct web service provider without the need for an intermediate applications server, it is more flexible to be supported by one, not only for reasons of scalability, but also because, given the fast pace of upgrades and adaptations of standards related to SOA that the manufacturers are introducing into their products, it seems more prudent for the applications server to be the one recording the upgrades instead of the database, in which greater stability is desirable.

In analogy with what is indicated for Oracle, IBM DB2 also incorporates capabilities for producing or consuming web services. In the case of the service provider, it is supported by the features Webservices Object Runtime Framework (WORF) and Document Access Definition Extension (DADx), which make it possible to generate WSDL interfaces for those SQL sentences or invocations to stored procedures that it is desired to present as services. To do this, a DADx file is generated and installed together with its associated runtime (Apache SOAP 2.2) on any applications server.

With respect to consuming web services, an IBM WebSphere Studio plug-in provides tools that make it possible to convert an existing WSDL interface into a DB2 function (which returns a table or scalar value). This way, it is possible to access a web service directly from SQL sentences without the intervention of an applications server.

Lastly, as was already remarked in the .NET section, Microsoft provides similar features through SQL Server Web Services Toolkit, available for SQL Server 2000 and equipped with more functions in the new version, SQL Server 2005 (Yukon).

EnvirOnmEnTS wiTh AnSi c Or viSUAl c++ / viSUAl BASic ApplicATiOnS

One example of legacy applications developed in ANSI C and considered as candidates for conversion into services could be exemplified by algorithms that form part of a very specific business process for which implementation through ANSI C was chosen for reasons of performance at that moment, before the modern Java compilers had achieved comparable performance results. Algorithms for the annulment of tenders in liberalised and dynamic markets, or rate calculators for insurance policies, for example, would fall under this group.

“AlThOUgh dATABASES mAy dirEcTly OffEr And cOnSUmE

wEB SErvicES, iT iS mOrE flEXiBlE TO SEEk SUppOrT frOm

An ApplicATiOnS SErvEr fOr rEASOnS Of ScAlABiliTy, And BEcAUSE ThiS lATTEr BETTEr

AdApTS TO ThE UpgrAdES in ThE STAndArdS.”

33

The most flexible option for their conversion into web services is to use an intermediate applications server that will take charge of supporting the standards and validating and converting input and output formats.

If, for some reason, direct integration is necessary without the presence of an applications server, recourse may be taken to market, commercial or free libraries. One example could be Axis CPP and Axis2.Nevertheless, degree of maturity and support of the said products, which, like the standards, are in constant evolution, should be evaluated.

With regard to applications developed with Microsoft Visual C++ or Visual Basic for the Windows platform, whether these are user applications that now require invoking a service or components that it is currently desirable to convert into services, these may be incorporated into service architecture over different paths. This may be done, for example, by migrating the code of the application into .NET or by employing the utilities of the .NET platform to create CCWs (COM Callable Wrappers). Using this type of proxy, a COM client can communicate with .NET components and make them take charge of the details regarding web services (client or server). In the same way, a service offered by a COM component may be consumed by a .NET application, in this case, over an RCW (runtime callable wrapper) type of proxy that will allow the application to handle the unmanaged code of the COM component. In any case, the reasoning applicable may be very diverse, and hence could require previous study.

AlTErnATivE EnvirOnmEnTS

During the last few years, there has been a proliferation of alternative languages with respect to the classical or majority languages for the execution of diverse tasks, such as:> fast generation of dynamic web pages> complete web applications exemplified by forums,

content managers, weblogs or incident tracking systems

> preparation of system administration scripts> preparation of testing scripts.

These generally involve extendable, multi-platform, interpreted execution script languages. Some examples are PHP, Perl, Tcl, Python and Ruby.

In what concerns web services developed under these languages, there are currently basic implementations of the SOAP protocol that permit the generation of web service clients and servers. Some examples are:

> SOAP::Lite (Perl)> NuSOAP, SOAPx4 (PHP)> TclSOAP (Tcl)> SOAPpy, ZSI (Python)> SOAP4R (Ruby)

However, when it comes to dealing with the preparation of SOA services based on these languages and these SOAP implementations, it is important to study their degree of maturity and interoperability in relation to the currently valid standards. There are portals such as SOAPBuilders where it is possible to verify degree of interoperability between different free and commercial implementations in different languages (Java, C, Perl, PHP, Tcl, and Ruby).

Likewise, the Web Services Interoperability Organization (WS-I) provides tools (called “Testing Tools”) to verify whether a web services implementation is compliant with the WS-I Basic Profile, the WS-I Attachments Profile and the WS-I Simple SOAP Binding Profile.

“wS-i prOvidES TOOlS (cAllEd TESTing TOOlS) TO vErify whEThEr A wEB SErvicE

implEmEnTATiOn iS cOmpliAnT wiTh ThE wS-i BASic prOfilE.”

34

Service Oriented Architectures are a reality that is being implemented in the leading companies on the market. Regardless of sector and the size in which they are found, a large number of companies are now in the process of migration to this architecture type.

Although SOA was perceived as a technology for future implementation in the past, it has currently matured and is enjoying great market support, being able to rely on mature solutions among different manufacturers. This situation of maturity does not preclude the existence of different aspects in which it is necessary to continue developing, such as Security, Transactionality and Interoperability, where certain problems may still be found in some situations.

Likewise, in certain cases, aspects of performance in Service Oriented Architecture have been alluded to. Evidently, the use of services incorporating layers and protocols in communication are going to imply a degree of penalisation with respect to direct and tightly coupled communication (for example, the incorporation of a library with functions into our projects), but the benefits to be obtained from the adoption of SOA compensate these possible absences which – on another hand – always appear whenever layers are incorporated into a systems architecture.

As has been analysed in the preceding chapters, the adoption of SOA by a company requires a detailed analysis of its current situation so as to discover the most appropriate manner of carrying out such a project.

The problems and complexity of the project as well as the solutions proposed will vary to a great degree depending on the size of the company, the technologies that it handles and its integration with third parties.

Likewise, in the majority of companies, SOA adoption will be gradual and progressive. It will be important in this process for both the applications developed in the new architecture and those existing in the previous environment to be able to interact as transparently as possible.

The services oriented architectures incorporation to enterprises is broadly recognise like a high relevant

need on the global economy. Following this line, it has been created at the European continent a Technology Platform, NESSI (Networked European Software & Services Initiative), whose objective is to define a development frame for services architectures incorporation, sharing and adding services through all the European countries and all the industrial sectors. At this moment, Atos Origin is in charge of the NESSI Executive Committee Vice-presidency. On the other hand, on a country level, it has been established the Spanish Technology Platform INÉS, with Atos Origin like a founding member and whose objectives are aligned with those from NESSI about promoting and adopting SOA with a nation-wide application.

Lastly, we should indicate that SOA adoption is possible and beneficial in the majority of companies, regardless of their size and the technology they employ. Although in many cases, talking about SOA evokes considerations about J2EE and .NET, other environments and products can be accommodated in this architecture, particularly in the case of EAI products, where different manufacturers have adapted their products to operate in Service Oriented Architecture.

CONCLuSION

“AlThOUgh SOA wAS pErcEivEd AS A TEchnOlOgy fOr fUTUrE implEmEnTATiOn in ThE pAST,

ThiS TEchnOlOgy hAS cUrrEnTly mATUrEd And iS nOw EnJOying grEAT mArkET SUppOrT, BEing

ABlE TO rEly On mATUrE SOlUTiOnS AmOng diffErEnT

mAnUfAcTUrErS.”

35

On the basis of our experience with clients since our first internet implementations, Atos Origin has consoli-dated a numerous group of architects whose expert know-how is integrated into our applications architec-ture line of business, configured along the following service lines:

1) Multi-Channel Platform (MCP): The Atos MCP originated in 2000 as the result of a project financed with PROFIT funds. Since then, it has matured continu-ally, with production installations on clients. It is currently available in J2EE and .NET, and presents excellent levels of productivity and performance (7,200 concur-rent users and 190 pages per second, according to the SUN benchmark for December 2004). The MCP is also used as a reference model in consultation projects.

2) J2EE, .NET, SOA Corporate Application Archi-tectures: Consulting Services to define models for corporate applications adapted to each client, based on market standards.

3) Rehosting: System consultancy and integration services oriented towards the migration of critical busi-ness applications from mainframe environments to open systems, based on market tools and the company’s own experience.

4) Applications Auditing: Analyses of the technical reasons that provoke deterioration in the performance of critical applications. Proposals for corrective action and their implementation.

5) High Availability Architecture: Architectural con-figurations to achieve the level of availability demanded, using technologies of failure tolerance, load sharing, and crash recovery.

6) IT Consolidation Strategies: Optimisation studies on IT resources by way of infrastructure consolidation. Assessment in contracting basic HW and SW.

7) Research & Development on Service Engineering: an important part of the Enterprise R+D activity is invested into the consecution of new implementation, adoption and deployment paradigms of services architectures, as well as service discovery and aggregation, aligned with the Research Strategic Agenda

of NESSI Technology Platforms in Europe and INÉS in Spain. The R+D activities have been oriented to develop new technology solutions to convert to SOA legacy applications within the wide Atos Origin’s added value services offering.

ABOUT ATOS OriginAtos Origin is an international information technology services company. Its business is turning client vi-sion into results through the application of consulting, systems integration and managed operations. The company’s annual revenues are EUR 5.8 billion and it employs 50,000 people in 40 countries. Atos Origin is the Worldwide Information Technology Partner for the Olympic Games and has a client base of international blue-chip companies across all sectors. Atos Origin is quoted on the Paris Eurolist Market and trades as Atos Origin, Atos Worldline and Atos Consulting.

For more information, please visit www.es.atosorigin.comwww.atosresearch.euwww.nessi-europe.comwww.ines.org.es

AUThOrS

Ana Coca, Agustín Domínguez, Esdras Martín, Javier Fernández, José Luís Núñez, José María Cavanillas, Ignacio Pérez, Israel Marcos y Roberto Gutiérrez.

pUBliShing And EdiTing

This White Paper is a product of the Thought Leadership Division of Atos Origin.

For more information: es-marcom@atosorigin.com

All rights reserved. No part of this publication may be reproduced in any form or by any electronic or mechanical means, including information storage, without prior permission in writing from Marketing & Communications department of Atos Origin S.A. Española, Unipersonal.

BuSINESS LINE IN APPLICATIONS ARCHITECTuRE OF ATOS ORIgIN

Atos, Atos and fish symbol, Atos Origin and fish symbol, Atos Consulting, and the fish symbol itself are registered trademarks of Atos Origin SA. December 2008.

Atos OriginAlbarracín, 2528037 MadridTel.: +34 91 440 88 00Fax: +34 91 754 32 52www.es.atosorigin.com

© M

arke

ting

& C

omm

unic

atio

ns, S

pain

12.

08