SOA: Service Oriented
White Paper (Technical Appendix)
A real technology for a new collaborative philosophy between applications and business processes
CONTENTS (TECHNICAL APPENDIX)
1 SOA in J2EE 4
Introduction to Java 4
J2EE Components 5
Construction of the SOA Service Layer in J2EE 6
Security in Web Services 7
Interoperability in Relation to Security and possible Problems 9
Transactionality in SOA and J2EE 10
Monitoring in SOA and J2EE 11
2 SOA in EAi 13
MOM Characteristics 13
EAI Architecture 15
The Adaptor 17
Web Services 17
Security in EAI 18
Message Broker-based Security 20
Connector-based Security 20
Security based on the Proxy between Connectors and the ESB 21
The ACL Management Service 21
Transactionality in EAI 21
3 SOA in .nET 23
Working with Services 23
Web Services 23
SOA Realities with .NET 27
What does the Future hold for us? 27
Indigo: Windows Communication Foundation 27
Avalon: Windows Presentation Foundation 28
Windows WorkFlow Foundation 28
4 SOA in lEgAcy TEchnOlOgy EnvirOnmEnTS 29
CICS Environments 29
Environments involving Procedures stored on Databases 31
Environments with ANSI C or VISUAL C++/Visual Basic Applications 32
Alternative environments 33
5 cOnclUSiOnS 34
6 linE Of BUSinESS in ATOS ApplicATiOn ArchiTEcTUrE 35
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
inTrOdUcTiOn TO JAvA New technologies are incorporated into the Java platform
through the JCP, by means of a "Java Specification
Currently, Java is one of the leading platforms for the Request" (JSR). In order to create a JSR, the need for
creation of corporate software. The evolution of the Java the new technology or for the modification of an existing
programming language has been extraordinary (see the technology must be explained in a document, along
figure below). It has progressed from its role as a tool for with how this change will affect the rest of the platform.
developing small applets for execution on browsers to Although it is not necessary, it is also recommendable
become a standard multi-platform programming model, to propose a group of experts who will take charge of
now capable of implementing the critical applications of developing the JSR, if this is accepted. Anybody, whether
large companies. or not is a member of the JCP, may propose new JSRs.
The Java platform is not a specific software, but rather, a In this manner, the open and coordinated evolution of
set of specifications defining each and every one of the the standard is guaranteed, without the impositions of
technologies comprising the platform. a single manufacturer. This constitutes a guarantee of
stability over the medium and long term when it comes to
It is necessary at this point to underscore that Java, and selecting this platform as against other possibilities.
specifically J2EE, are neither commercial products nor
a sole manufacturer’s alternative for business software Below is a more detailed description of the J2EE platform
development, but rather a set of specifications in which reflecting its capacity to accommodate SOA services.
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 “SErvicE OriEnTEd
platform), until it became the current free standard.
ArchiTEcTUrE (SOA) iS in ThE
The Java Community Process is the organism that prOcESS Of implEmEnTATiOn
governs the evolution of the Java platform through the
creation of new specifications and the maintenance of
in ThE lEAding cOmpAniES On
those already existing. The JCP defines its own operation ThE mArkET.”
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.
divErSE STAgES ThrOUgh which A JAvA SpEcificATiOn rEqUEST pASSES
ote ed ec eleas t t
Sp R raf allo vie
CV orm the inal al D l B Re pti
&E pF t ete aft F eview Fin rovaleae ce ce Exce
iew aft rou af pl r d pp e an an m
ion ev Dr rt G ly Dr m D R te se en nten Ite
tat PR rly pe r Co blic ublic C Voropo inal ainal R int i te
Ini JS Ea Ex Ea Pu P E P F F Ma Ma EC Vo
1 2 3 4
ys ys ys ays ys ys ys
da da da d da da da
14 -90 -90 last 7 14 30 t7
30 30 las
J2EE cOmpOnEnTS transaction coordinators (DTCs), messaging systems
(message queues), models of objects distributed (ranging
Distributed applications require access to a serie of from RPC, through DCOM or CORBA up to Java’s own
company-hosted services. Typical services include RMI), transaction monitors (like CICS or TUXEDO), etc.
transaction processing, high availability and load J2EE has not invented anything new in this sense, but
balancing, access to databases, messaging, multi- simply defines a standard way of accessing previously
tasking and multi-threading, etc. J2EE architecture dispersed functions that obliged developers to depend
unifies access to these services in a service API. on specific suppliers. J2EE changed this restriction,
Nonetheless, instead of having to access these services permitting competence between companies and giving
over a customised or non-standard interface, application rise to new business models, such as those based on the
programs based on J2EE are able to access these APIs offer of free, open-code J2EE platforms, where benefits
through the J2EE container. are not obtained from the sale of user licenses but from
consulting or support services.
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 OBJEcTivE Of ThE J2EE
the main specifications are those defining the structure plATfOrm iS TO pErmiT
and behaviour of reusable objects (components) called
Enterprise Java Beans (EJB). In addition, there are prOgrAmmErS TO cOncEnTrATE
specifications regarding, among other things, database AS fAr AS pOSSiBlE On ThE
access (JDBC), directory service access (JNDI), SMTP
messaging service (JavaMail), access to a Message SpEcific dETAilS Of BUSinESS
Oriented Middleware or MOM (JMS), access connectors And TO dElEgATE lOw-lEvEl
to legacy environments (JCA), connectivity between
objects lodged in the same machine or in others (RMI
SErvicES TO ThE cOnTAinEr.”
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
cOnSTrUcTiOn Of ThE SOA SErvicE lAyEr in Support for JAX-RPC is included among the principal
J2EE application servers compatible with J2EE 1.4, such as (in
alphabetical order) Apache Geronimo 1.0, BEA Weblogic
The advent of SOA brought the world of IT a conceptual Server 9.0, IBM WebSphere Application Server v6, Jboss
evolution in the manner of tackling interconnectivity Application Server 4.0, Jonas ObjectWeb 4.4, Oracle
between applications and components, rapidly giving rise Application Server Containers for J2EE 10g (OC4J)
to new services of a higher level. J2EE did not ignore this 10.1.3 and Sun One Application Server 8.
movement and included several aspects regarding web
services in its J2EE 1.4 specifications. Web services are Interoperability is one of the key aspects of service
the elements that make up SO architecture. oriented applications. In order for services to be
interoperable, they must be able to communicate
One characteristic that differentiates web services from not only with other J2EE platforms, but also with
other J2EE specifications is that these are designed to implementations based on other technologies such as
present interfaces based on independent open multi- .NET. Once a web service has been deployed and its
platform protocols belonging to the manufacturer, existence published, registered for instance in a directory
while at the same time providing a vehicle for building service (such as UDDI), any client may find it and invoke
interconnected services, with the added advantage that it. Hence, it is impossible to anticipate the type of client
these were loosely coupled. that will act as service consumer.
Thus, an SO architecture may be divided into four layers, In consequence, it must be ensured that the web
as against the traditional three layer arrangement: services created comply with the standard WS-I
Basic Profile (Web Services Interoperability Basic
> Presentation Profile). WS-I is an open consortium of suppliers such
> Service as Oracle, IBM, Microsoft and Sun who emphasize
> Business interoperability between the web services of different
> Persistence platforms, operating systems and languages. J2EE 1.4
establishes compatibility with the WS-I Basic Profile as a
The service layer is marked by the characteristics of loose requirement for the certification of an applications server,
coupling and completeness. J2EE provides a complete which means that the applications server must generate
platform on which to build the service layer in an SO interoperable web services.
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 “SOmE Of ThE mEmBErS Of
from the J2EE developer. In addition to the details of low OASiS fOrm pArT Of ThE Jcp
level management of SOAP and JAX-RPC messages, it
introduces a new paradigm that offers two programming (Java Community ProCess). ”
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
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.
SEcUriTy in wEB SErvicES Authentication: Implementing digital certificates on
the server resolves the problem of its authentication. By
Due to the dissemination of web services and their rapid configuring this server, it is possible to require the client
adoption in the framework of e-business, information to present his own certificate, thus performing mutual
technology companies have found themselves authentication.
confronted by the need to introduce aspects relating to
security in web services that go beyond what is set forth Encryption: The information transferred is encrypted by
in the WS-I Basic Profile. This has affected all service means of a key (generated during the SSL negotiation)
providers, not only those centred on J2EE. During an using a symmetrical key algorithm capable of encrypting
initial phase, every software manufacturer (Microsoft, large volumes of information in very little time.
Sun Microsystems, IBM, etc.) had its own security
implementation, creating a climate of confusion in this Integrity: The unnoticed passage of intentional or
regard while awaiting the deployment of a de facto accidental modifications in the information as it travels
standard. through internet is impeded. This is achieved by using an
asymmetric encryption key employing a MAC (Message
Regardless of the business problem to be resolved by the Authentication Code). This MAC would be the hash
web service, it is necessary to tackle the same problems summary of the message concatenated by a secret
of security that exist in the technologies of distributed SSL session number shared between the client and the
integration or computing. Problems relating to security server.
are fundamentally as follows:
Non-repudiation: In order to solve non-repudiation,
> The client must be authenticated with respect to the it is necessary to resort to the electronic signature of
server. transactions. This is achieved thanks to the WS-Security
> The server needs to be authenticated with respect to specification that describes a standard way of signing
the client. SOAP messages, since SSL does not resolve this
> It is necessary to guarantee the integrity and security problem.
confidentiality of the messages exchanged.
> It is necessary to guarantee non-repudiation of the WS-Security deals with a way of ensuring a secure
transaction. context by means of a multi-point message route.
> It is necessary to determine a client's rights of access,
verifying not only his identity, but also his level of The WS-Security specification includes a standard set of
authorization against internal access control policies. SOAP extensions that make it possible to secure a web
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 “ThE wEB SErvicES crEATEd
intervention of HTTP also exist (such as web services
over SMTP or message queues). HTTP and its security
mUST cOmply wiTh ThE
mechanisms (SSL and HTTPS) solely respond for Ws-i BasiC Profile STAndArd,
point-to-point security. It is necessary for more complete
solutions to incorporate an end-to-end security concept.
which rEvOlvES ArOUnd ThE
The identity, integrity and security of a message and inTErOpErABiliTy Of wEB
its sender must be protected in the different kinds of SErvicES.”
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:
service in order to guarantee integrity and confidentiality. the need for defining a complete security solution in
This in turn is open to other security models including WS-Security, as it takes advantage of the fact that the
PKI (Public Key Infrastructure), Kerberos and SSL. WS- industry has already resolved many of these problems.
Security provides support for multiple security tokens,
multiple formats of electronic signature, multiple secure > Kerberos and X.509 take charge of the subject of
domains and multiple encryption technologies. 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
Applying security to
web services > 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
Transport channel problems.
security level Example:
(WS Security) Encryption of entire message (for HTTP this
means encrypting the entire HTTP message) 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.
Authorization Confidentiality Integrity
Example: Example: Example:
WS-Security defines a SOAP heading element for the
Username Password Message encrypting Security token 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
The specification includes the propagation of as, for example, that transmitted by XML Encryption,
security tokens, message integrity and confidentiality. may be included in the WS-Security heading. This does
Nonetheless, these mechanisms by themselves alone not specify either the format or the encryption of the
do not cover all the aspects of a complete secure signature, but rather determines the mode in which the
solution. Thus, WS-Security represents only one of the security information contributed by other specifications
design layers of a sophisticated security solution for web may be incorporated into a SOAP message.
Fundamentally, WS-Security is a specification for a
The WS-Security specification is one of the first standards security metadata container based on XML.
among web services to support, integrate and unify
multiple security models, mechanisms and technologies, Apart from making use of other existing authentication,
permitting a great variety of systems to interoperate integrity and message privacy protocols, WS-Security
neutrally in what refers to language and platform. specifies a mechanism for transferring simple user
Organisms such as OASIS and different companies have credentials through the UsernameToken element. In order
participated in its definition. In April 2002, Microsoft and to send binary symbols used for encryption or message
IBM created a roadmap for WS-Security called “Security signatures, the BinarySecurityToken element is also
in a Web Services World: a Proposed Architecture and defined. Messages can store information regarding the
Roadmap”. In September 2002 WS-Security v1.0 was caller and the mode in which the message was signed
published and it was approved in April 2004. and encrypted in this heading. WS-Security presents
an end-to-end solution for web service security that
WS-Security tackles the theme of security making use of preserves all security information in the SOAP part of the
existing specifications and standards. This circumvents message.
EvOlUTiOn SEcUriTy TO wEB SErvicES This problem is illustrated by a specific example below:
Given a scenario with the products IBM WebSphere
August 2002 6.0 and Microsoft WSE 2.0 SP3 (the principal founding
WS-Security 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.
OASIS September 2002
ACTIVITIES WS-Core Draft 1
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
May 2003 February 2003
WSS: SOAP Message WSS: Usename Toke
100%, since by default WebSphere 6.0 literally follows an
Security Draft 3 Profile Draft 2 errata in the specification on indicating the value of the
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
inTErOpErABiliTy in rElATiOn TO SEcUriTy And certificate. The request is signed using the private client
pOSSiBlE prOBlEmS key. This in turn encrypts the request with the public key
of the server certificate. The response is signed using
There are instances of existing WS-Security the private key of the server certificate, and encrypted
implementations in commercial products such as with the public key of the client certificate which is
IBM WebSphere, Bea Weblogic Server, SUN JWDP encapsulated in the response. In sum, typical scenario in
(Java Web Services Development Platform), among B2B communication.
others, or in open-code products such as the Apache
WSS4J extension in the case of Java, and in the WSE It is observed that in this scenario, it is not possible for the
extension in the case of Microsoft, distributed separately specific products mentioned to interoperate correctly. This
on Microsoft .NET Framework 1.1, but already fully is due to the differences between the OASIS WSS X509
incorporated into its version 2.0. Token Profile 1.0 standard implemented by Microsoft
WSE2.0 SP3 and the OASIS WSS X509 Token Profile 1.0
In theory, the purpose of all these implementations is non-normative errata followed by IBM WebSphere 6.0.
to adhere to the specification standard and ensure OASIS and IBM also know the problem, and this latter
interoperability, fundamental when dealing with entity plans to publish a fix in the next service pack of its
SO Architecture, in which heterogeneity is usual. product to enable OASIS WSS 1.0 support.
Unfortunately, at present, maturity is still insufficient
in this regard, and it may happen in a real scenario These types of incompatibilities are being resolved as
that a product implements a concrete version of the such new specifications mature and grow in acceptance
specification, while the other end follows a different and dissemination.
version or an errata of the specification, continuing
to raise questions about interoperability in this field. The conclusion is that the scenarios in which SO
Nonetheless, rapid advances are being made in this architecture and its applications are implemented should
connection. be carefully verified. It is convenient to formulate pilot
projects to verify that problems of interoperability will > Loose coupling. The loose coupling of its components
not arise and, if applicable, to seek assessment from a implies little involvement with the environment. It may
technological partner experienced in the market situation. happen that an SOA component invokes other SOA
components executed in outside companies and that
the business process obliges the consolidation of each
TrAnSAcTiOnAliTy in SOA And J2EE and every party involved. The case is complicated
when the components are lodged in heterogeneous
One of the desirable characteristics of SOA lies in the systems and are developed in different technologies.
fact that its components present loose coupling, so that
they are able to form part of diverse business processes > Very extensive transactions in terms of time. The
on the basis of reutilisation without the need for change, concept of transaction isolation applied to transactions
preventing too much impact on the process into which that are extensive in terms of time brings several
they are integrated in case they are substituted by problems with it, such as the possible blocking of
another equivalent component. This requirement has resources.
facilitated an evolution in the concept of transactions.
> Optional transactions. Some business processes may
In traditional models, the transaction is carried out within require that the failure of one operation will not imply
the scope of a specific business, taking different sources the failure of the entire transaction.
of data and the need to maintain the coherence between
them into account. In the world of J2EE, this model of > Propagation of the context of the transaction. If
transaction is implemented through the JTA and JTS the transaction extends to several organisations, a
specifications, which define the contract between the mechanism for the propagation of the transaction
transaction managers, the applications and the J2EE context should be provided.
containers. These specifications provide interfaces for
managing data sources by means of X/Open standards. The previous points underscore that the typical
characteristics to a traditional transaction (ACID) are
In the world of SOA, the definition of a transaction is complicated in the case of an SO architecture. Thus,
complicated, due to the fact that, conceptually, the way efforts have been made to standardize a scenario that
applications operate in this architecture differs from permits the use of transactions within SO architecture.
the way they operate in the traditional model. These
differences lie in aspects such as:
EXPENSIVE Res Reserv (participant)
AIRLINE B mad ation
Reservation AIRLINE A
AIRLINE C Unavaila s
COORDINATOR / erv
COMPOSER mad ation CAR RENTAL
OASIS defined BTP (Business Transaction Protocol) J2EE responds to the new needs of transactionality by
to coordinate transactions between independent launching its reference specification, JAXTX. This seeks
services. The basis of BTP is the fact that none of the to isolate the programmer and the J2EE containers from
parties controls the transaction, but rather, that this is the complications of complex transactions, although this
propagated between them and each party decides aim cannot be covered in the same way as in the case
whether or not to participate in the transaction. If a of JTA/JTS, since this new scenario contemplates that
party opts to join the transaction, it should provide a it may be necessary to add application logic in order to
mechanism for cancelling or confirming this. Each party is deal with these complex transactions.
responsible for its internal blockages.
BTP uses XML messages sent between the coordinators mOniTOring in SOA And J2EE
of each party involved in the transaction in order to
function. Two different types of transactions are defined: One of the most important aspects of an SO
architecture is the information monitoring and auditing
> atomic transactions (all the parties are obliged to finish process. This process may be carried out efficiently
the transaction successfully) in J2EE by means of the JMX (Java Management
> cohesion transactions (not all the parties are obliged to eXtensions) specification.
finish the transaction successfully).
JMX is the technology defining management
Although BTP is not only thought out for operation with architecture - the API, the design patterns and the
web services and leaves the messaging protocol open, services for monitoring and administering Java-based
the use of SOAP makes it possible to use BTP in practice applications.
in web services. The first industrial implementation of BTP
is ascribed to HP, with HP Web Services Transactions The application processes, configuration parameters and
(HP WST) trace levels may be remotely monitored.
This makes it possible, for example to make the
wS-TrAnSAcTiOn/wS-cOOrdinATiOn traditionally used focus more sophisticated in order
to administer services and applications, making it
Microsoft, IBM and Oracle-BEA on their side defined the possible, for example, to make changes to the status/
WS-Transaction and WS-Coordination specifications to information of a clustered application in the framework
cope with the problems arising from changes of scenario. of a high availability environment with several servers in
WS-Coordination takes charge of defining general cluster. Indeed, the most significant applications servers
mechanisms to create, coordinate and record the activities on the market use JMX technology to manage their
carried out by several web services. Each service creates own internal processes. IBM, Oracle-BEA, and Jboss,
and records its activity and its coordination protocol. among others, have followed this scheme for their
WS-Transaction/WS-Coordination are oriented towards web
services since it is built on the basis of SOAP and WSDL. JMX facilitates the management of applications and
services. This technology permits Java developers to
Both BTP and this model respond to the same needs, integrate their applications with existing management
the most important difference between them is that WS- and operation solutions, making it possible to administer
Transaction/WS-Coordination are linked to web services, (by changing application configuration parameters) as
while BTP has no limitations as to underlying architecture. well as monitor these (by obtaining statistics and error
notifications from them).
WS-Transaction/WS-Coordination define two types of
elementary transactions – “atomic” and “business” – the
characteristics of which are similar to those of BTP.
JMX architecture defines three levels: Managed Beans or MBeans are the JMX objects that
present the manageable information in the form of
> Instrumentation Level (Application Layer): The properties and operations. As a previous requirement to
application layer (called instrumentation level) is the implantation of JMX, the components that perform
where the components that facilitate the information services that may be subject to instrumentation are
necessary to administer an application reside. These codified as MBeans or at least have their interface
components are developed in accordance with the published in the form of an MBean, such that the
management needs of each application. For example, invocation of an MBean method updates component
a component may have a method to stop a service status.
within an application.
There are several types of MBeans (Standard MBean,
> Agent Level: The agent level is that which facilitates Dynamic MBean and Model MBean). The selection of
an interface for the administration of the components of one or another must be done according to our needs of
the instrumentation level. instrumentation.
> Adaptor Level: The adaptor level consists of one or
more connectors (or protocol adaptors) that provide
access from remote monitoring systems.
REMOTE MANAGER JMX WEB SNMP
Manager Browser Manager
CONNECTOR LEVEL RMI HTTP SNMP
Adaptor Adaptor Adaptor
AGENT LEVEL MBean Server
INSTRUMENTATION LEVEL MBeans MBeans
SOA IN EAI
EAI (Enterprise Application Integration) is understood to wait for certain information if this is not available at
as the use of methods, principles and technology to the moment of consultation. In this way, the applications
make applications, generally from the Business Support can continue to resolve other tasks and even attend
Systems (BSS) environment of a specific company, to other clients while the consultation being made is
work together jointly or in an integrated manner. resolved.
The term EAI, coined during the 90s, has undergone The manner in which asynchronous communication
considerable evolution with the passing years, from the is resolved within a MOM accounts for the difference
original concept of point-to-point connection between between the two fundamental philosophies of
the applications and systems in a company to the most presentation middleware at present. These two
recent approaches using web services and the internet tendencies are message queuing and message passing.
to present fully distributed services to companies
and clients. Its final objective has always been that of Message queuing is defined as a model of indirect
attaining the most flexible, efficient and competitive way communication in which the communication takes
of integrating processes between applications in order place over a queue. Messages coming from a specific
to provide services to clients. application are sent to a specific queue, which is
identified by its name. Once the message has been
During the years prior to the start of this technology, stored in the queue, the queue manager takes charge
connection was resolved by means of point-to-point of conveying it up to the application of destination.
connections between applications. This highly simple
scheme lost its feasibility as the number of applications The message passing paradigm is associated to
and services increased. a mechanism of direct communication, since the
information is sent to the applications that require it
without the participation of any intermediary element.
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
EAI emerged in the knowledge of the problems inherent cOncEpT, ASynchrOnOUS
in the focus on point-to-point connections, whereby
it rapidly allied with the concept of messaging – and cOmmUnicATiOn.”
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
Message Oriented Middleware introduces a
fundamental concept when it comes to focussing on
and resolving application integration. This concept is
Asynchronous Communication provides a certain
degree of freedom to the applications participating in
the integration, since they do not oblige any application
One characteristic proper to systems based on applications in an organised manner, thus building
message passing is the capacity to implement a Service Bus. The most puristic definitions of EAI
publication/subscription mechanisms. This publication/ contemplate the interconnection of applications
subscription based paradigm makes it possible for a with the medium and the management of message
group of applications interested in specific information exchanges as its sole responsibility. Nonetheless, this
to subscribe to the said information. The application perception has been expanding and currently also
that issues the information publishes it under a specific includes the feature of orchestration.
“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 “EvEnT OriEnTATiOn And
associated. rEAl TimE ArE fEATUrES
The messaging-based model gives EAI with the
prOvidEd By ThE pUBlicATiOn/
capacity to connect to the services provided by the SUBScripTiOn pArAdigm.”
AGENT CALL ADDRESSED ADDRESSED
CENTER SySTEM 1 SySTEM 2
Search for client Search for client
in System 1
Does Create Client
it exist? Error?
Create Client in Create Client
Gather client Create Client
Send Send Send
confirmation confirmation confirmation
to client to client to client
Business Process (User) User interaction
DEFINITIONS Business Activity Business service application
Integration Business Process Business service integration
EAi ArchiqUEcTUrE BPA permits the reception of a high-level definition of a
business process and its rapid implementation on the
Typically, the basic architecture deployed to integrate basis of UML-based schemes.
EAI based applications consists of positioning a series
of connectors or adaptors that connect the applications The figure of the page before, 'Business Process',
to be integrated into the integration bus with an presents an example of a Business Process and shows
orchestrator or BPA (Business Process Automation) how this would be schematically represented within a
mechanism, the component charged with performing BPM tool.
the transformations and message passing paradigm in
accordance with the rules established for the execution As may be observed in the figure at the foot of the
of the Business Process. page, EAI is currently built around diverse components
and tools that transcend the simple concept of
BPA has been fundamental in advancing EAI, more application integration and provide facilities for the
specifically, its implementation in company integration management, deployment and maintenance of
suites. The capacity that these tools provide to design integration and development. These elements are what
business processes such as the orderly and conditioned comprise the current Integration Suites.
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 hAS BEEn fUndAmEnTAl in
cOmpOnEnTS Of An inTEgrATiOn SUiTE
APPLICATION 1 APPLICATION 2 APPLICATION 3 APPLICATION 4
ADAPTOR ADAPTOR ADAPTOR ADAPTOR
Monitoring and Monitoring / Business Process Business Process Deployment and Configuration
Control Complex Event Management Automation management and Status
The role played by the business process manager in process, the execution status of the said process
resolving automated processes has already been set would be stored for its subsequent recovery. From this
forth. A further step in the search for the total integration point onward, the supervisor can be informed of the
of company procedures incorporates elements that are reasons why the exception occurred and can take the
capable of administering long-term processes where appropriate measures to draw up an incident report for
human intervention generally occurs. The workflow the interested parties capable of resolving it. These tools
facilitates the elements necessary to manage these in turn provide facilities for obtaining the message data
processes and, furthermore, introduces the pertinent and manipulating these in order to recover the process
layer of information persistence required to recover the and continue its execution from the point at which the
status of the process the moment it is reactivated. incident occurred.
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.
“ThE cUrrEnT TEndEncy in
Statistics are measured by means of the identification ThE EvOlUTiOn Of inTEgrATiOn
of the Key Performance Indicators (KPI). The KPIs are
distributed along the strategic points of the business
SUiTES iS ThE incOrpOrATiOn Of
process and provide the information that the BAM BAm And cEp.”
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
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
ThE AdApTOr The adaptor specifically adapts to each application
as it incorporates the mechanism through which it
The connection with the services provided by the establishes contact and accesses the services that the
applications takes place over the connectors or application wants to present. It likewise provides the
adaptors of each application. The adaptor is a part communication mode between the service bus and the
that may be supplied by the manufacturer, developed application, such that those services that are defined
by a third company or custom-built on the basis of the in the adaptor container become public and thus may
development kit supplied by the manufacturer. 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,
Manager as the mechanism by which the services become
public. The adaptor acts as a bridge between the
Manager independent worlds of the application and the Service
Bus, translating between protocols in order to establish
Event Loop Service
Container wEB SErvicES
The recent rise of web services has brought about
a clear convergence of integration suites towards
Management the principles on which this technology is based.
In consequence, all the principal manufacturers
of integration suites within the scope of EAI have
Stop incorporated SOAP (Simple Object Access Protocol)
and its interfaces for permitting WSDL (Web Services
Description Language) service definition and coupling
ADAPTOR between them from other applications.
Nevertheless, web services go much further beyond
the mere definition of new service access protocols and
The preceding figure shows the main components of an their service definition language.
adaptor, which are as follows:
As is set forth in the next figure, Web Services define
> Modules for adaptor start-up and stoppage. a series of standards to implement the operability
> Module for loading configuration from the record or necessary to provide access to the services.
> Module for managing event loops.
> Container module for services or call-backs that
provide the functionality necessary to resolve a bus
“ThE rEcEnT riSE Of wEB
> Trace management module. SErvicES hAS BrOUghT ABOUT
> Monitoring module.
> Error management module.
A clEAr cOnvErgEncE Of
inTEgrATiOn SUiTES TO ThiS
SEcUriTy in EAi
In the SOA model, applications are integrated to
the business service producer applications and the
REGISTER OF responses that these provide by means of message
SERvICES UDDI dispatches. Normally, applications are distributed
on different machines, possibly belonging to several
network segments, which fact facilitates possible
WSDL attacks against authenticity, confidentiality and the
Find Publish integrity of the information exchanged.
For this reason, it is necessary to protect both the
SOAP message dispatch to producers and the responses
SERvICE SERvICE that these producers provide the consumer, in such as
Link 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
Regardless of the security measures adopted to
The standards of communication (SOAP) and interface protect the machines on which the applications and
definition (WSDL) have been rapidly assumed and the measures designed to protect communications
incorporated into integration suites, due in part to the between them reside, applications must adopt their own
maturity of their specifications. This notwithstanding, mechanisms to protect information. These mechanisms
the register of services continues to be a pending will include the encryption of the information, digital
task in which, at present, the Universal Description, signatures, or the codes guaranteeing message
Discovery, and Integration (UDDI) standard has not integrity.
enjoyed the same degree of acceptance as its other two
companions. It must be pointed out that these protective
mechanisms imply a slowdown in message processing
As a result, integration suites have resisted the that can become considerable, such that they should
incorporation of implementation elements that would be applied only when necessary.
provide the cataloguing and registration capability
of services such as are specified in UDDI, and it is Following is a description of these mechanisms and
only very recently that they have begun to opt for how to apply them in the development of SOA.
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
“ThE EncrypTiOn mOdUlE
since they are not completely automated. inTErcEpTS ThE mESSAgES
EXchAngEd BETwEEn ThE
ApplicATiOn And ThE ESB And
dETErminES whEThEr Or nOT
ThESE ShOUld BE EncrypTEd.”
With a view to securing integration through SOA The need for an existing connectivity between the
services, EAI requires the following components that, on applications and the ACL management module in
occasion, may be included in the existing middleware: order to execute access control tasks should be taken
into consideration in this scheme.
> 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) “SEcUring ThE SErvicES
mechanisms, both with regard to list administration
(list creation, modification, deletion) and list access on rEqUirES SpEcific SEcUriTy Apis,
the part of the applications (consult user permits). mOdUlES fOr EncrypTiOn And
The following figure shows the security scheme to
employ in integrating applications to SOA, along with
Acl AccESS And mAnAgEmEnT
the three possibilities for invoking the Security API. mEchAniSmS.”
cOmpOnEnTS Of An inTEgrATiOn SUiTE
HOST A HOST B HOST C HOST D
APPLICATION 1 APPLICATION 1 APPLICATION 1
CONNECTOR CONNECTOR CONNECTOR
Security Security Security
API API PROXy API
Api for Security functions to be able to consume the information supplied through
This API provides the services of message this mechanism, all the systems must be mounted on
confidentiality, authentication and integrity and makes the same security paradigm.
it possible for these services to be included in the
applications, more specifically in the connectors linking A refinement to this mechanism would be to deploy a
the applications to the ESB. tool kit permitting the configuration or programming of
this message broker, such that only certain messages
The API conceals the implementation details of the are encrypted, on the basis, for instance, of channel or
security services from the application developers, topic used for publication.
such that application programmers centre on the
implementation of their functions, leaving the security Encryption would thus be more selective and it would
personnel to configure security requirements (encryption not be necessary for all the systems to be included
algorithms to use, length of keys, etc.) and user access among the secure channels, thus reducing the load that
privileges. the encryption of all information may imply.
Normally, APIs may be used in two different ways: In the preceding figure, the message broker is
The programmer may explicitly invoke the security represented by the segment of ESB belonging to each
services provided by the security API, such as for host.
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 Normally, this case arises in the developed connectors
sending and receiving messages over a secure medium in which it is easy to include a security management
of transport. module. Its advantage in comparison to message
broker-based security is that it is easier to control which
module for message Encryption parts of messages should be encrypted and which
This module intercepts the messages exchanged parts should not.
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. “AdminiSTrATiOn ThrOUgh
Acls mAkES iT pOSSiBlE
This component can be capable of establishing secure
channels between systems and thus depositing duly TO AUThEnTicATE SErvicE
encrypted information in the ESB. One example of BUS AccESS, ApArT frOm
this would be the use of SSL in TCP/IP to perform the
AUThOriSing ThE USE Of
SErvicES On ThE BASiS Of
The direct use of this mechanism implies the encryption
of all the data contained in all messages. Consequently,
SEcUriTy BASEd On ThE prOXy BETwEEn cOn- “inTEgrATiOn SUiTES USE
nEcTOrS And ThE ESB
TrAnSAcTiOn mOniTOrS ThAT
The use of security proxies is a specific case of implEmEnT ThE XA STAndArd TO
connector-based security that will be indispensable prOvidE TrAnSAcTiOnAliTy TO
where connectors that do not support security
services are employed, as well as connectors in which BUSinESS prOcESSES.”
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 extent, so as not to affect its response time and comply
transmission. with the “real time” maxim.
> Each application needing authentication shall have its
own security proxy for exclusive use. This is due to This characteristic accounts for transactionality not
the fact that the proxy may use digital certificates that being one of the mandatory points to comply with
authenticate the proxy with respect to the ESB. in suites that implement EAI, but rather, being an
> Each security proxy shall have a different identifier that optional feature which, at times, may even have to be
is unique in the network. resolved by bringing in solutions belonging to third-party
> The communication channel established between manufacturers.
applications and their security proxy must be
protected. It may certainly be said that there are EAI solutions
> The proxy will make use of the security API to protect on the market that provide transactionality as a serial
messages before sending them and to remove the feature, but in fact, these solutions are not EAI solutions
protection from messages received. properly said, but rather, transaction monitors, used
> The proxy must be able to record the information for their capacity to connect to databases in order to
about messages sent and/or received. perform application integration through data exchange.
These solutions do not present the characteristics
ThE Acl mAnAgEmEnT SErvicE proper to EAI as we have described it in previous
chapters, but even then, they may be used to
This service is a server process that distributes implement service oriented architecture, albeit in a very
security information to the applications connected to basic way.
the ESB. This information is managed by the security
administrator and is based on the establishment of Currently, integration suites admit the creation of
relationships with users (roles) and user groups with transaction islands within their business processes.
access permits. A transaction island is a container that holds all the
transactions or operations with other systems that
The security information will refer solely to user require compliance with ACID paradigms (Atomicity,
authorisation for access to certain resources. 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
TrAnSAcTiOnAliTy in EAi perform each and every one of the actions inside the
container. Otherwise, the container itself is charged to
CAs has been previously remarked, the clear event perform the roll-back actions necessary to undo the
orientation of EAI leads it to dispense with storing status operation and restore the entire system to its status
reports, or at least to do so only to a very restricted prior to the beginning of the transaction block.
Integration Suites use transaction monitors that When the applications, or resource managers according
implement the XA Standard to provide transactionality to the scheme set forth by XA, do not observe these
to those business processes that require it, such that principles, it is impossible to comply with the guidelines
when the BPA reaches a transaction block in the course established by DTP, and consequently, it is necessary
of executing a business process, it cedes execution to attempt to execute a transaction roll-back through
to the transaction monitor, which is the element that the adequate organisation of the business process, by
resolves that specific part of the process. implementing the pertinent rules that undo that part of
the procedure that has been executed.
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.
“if ThE ApplicATiOnS inTEgrATEd
It is nonetheless necessary to indicate that the dO nOT cOmply wiTh ThE XA
transactionality is only valid for those applications and STAndArd, iT iS nEcESSAry TO
systems compliant with the XA Standard. Typically,
these applications are the database managers, and at rESOrT TO prOcESS EnginEEring
present, many applications forming part of company in OrdEr TO mAnAgE ThE
infrastructure are based on client/server models, making
it rather difficult to maintain these principles. cOnSiSTEncy Of OpErATiOnS.”
cOncEpTUAl viEw frOm X/OpEn’S dTp mOdEl
1 The application defines the
The application uses the requirements of the transaction with
resources of a set of managers the Transaction Monitor Interface (TX)
The Transaction Monitor and the
Resource Managers exchange
information over the XA interface
SOA IN .NET
The leading software manufacturers are directly involved the while that their content will always remain the same,
in the processes of defining the new standards that regardless of the transport. And… how do we publish
guide the development of IT. our services?
Each of them implements the standards defined in its When it comes to publishing a service, it is possible
own way, enriching their functions with respect to the to opt for different alternatives depending on how the
functions of other manufacturers, competing so that service is going to be used. Depending on the platform
their products may be the winners… and Microsoft is no on which the clients or consumers of the service are
exception. Its involvement in the adoption of XML as a executed, it may turn out to be of more or less interest
support for communication between systems is shaping to think about publishing the services in the server GAC
up as a winning option. or in SOAP. If all my applications that consume the
service are developed on .NET, the easiest workaround
Along with the principal software manufacturers, would appear to be to register the assembly containing
Microsoft belongs to the consortium called OASIS, an the function in the GAC so that other applications
organisation set up for the purpose of developing and may use it automatically. But what happens when the
orienting the adoption of new IT standards. consumer is not executed on the .NET Framework?
There may be applications developed in other
XML support may be found in all Microsoft products. technologies that cannot use this Framework resource.
Due to broad acceptance on the part of other The new standards indicate that web services have an
manufacturers, every day there are increasingly more advantage over other forms of publication, and their
language specifications for the exchange of information adoption on the market is, without a doubt, the best
based on XML. Many sectors have their own specific support that they can rely on.
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 wEB SErvicES
an original version or a new version.
Microsoft clearly backs a web service oriented platform
Microsoft maintains its other tactic, namely, simplicity in based on XML. This medium for publishing services
the handling of its tools. For this purpose, it continues makes it possible for any platform capable of generating
to facilitate the administration and configuration of all its a SOAP request to consume web services developed
products from user-friendly interfaces, contributing SSO on a different platform.
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.
“micrOSOfT, AS A fOUnding
mEmBEr Of OASiS, pArTicipATES
wOrking wiTh SErvicES
in dEfining All TypES Of
In order to consume a service, it is necessary to have STAndArdS lArgEly rElATEd TO
a client that acts as a service requester. The client SErvicE OriEnTATiOn.”
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
Using two of the most widespread technologies published in the web server with the .DISCO extension.
currently in circulation – communication by hypertext These can contain both the URL to locate the WSDL
transfer protocol (http) and message structuring by file representing the operations of the web service to
means of XML – web services are similar in certain be invoked and references to other .DISCO files that
aspects to .NET Remoting, over which they have a reroute the request.
crucial difference: the potential for interoperability with
other platforms. While the implementation of a service In the design phase, if access is had to the
through .NET Remoting implies that the consumer implementation of the web service, various Microsoft
process must be executed on the .NET platform, the IDE tools make it possible to generate a web service
use of web services enables any execution platform proxy, in such a manner as to compile the service call.
other than .NET that manages SOAP/HTTP to invoke On other occasions, it becomes necessary to invoke
the services. Doing so requires the adoption of three the service in a dynamic way, by creating the proxy for
standards already mentioned: SOAP as communication invoking the service operations dynamically.
protocol, WSDL for the description of the functions
offered by the web service and, optionally, UDDI for the There are other manners of requesting the execution
business catalogue based on XML lists. of a service without using SOAP for communication.
Microsoft has its own implementation of a messaging
In addition, there are a large number of specifications system based on message queues, Microsoft
regulating the evolution of web services. These MQ. The possibility of using message queues as a
specifications affect transactions, security, messaging, communications mechanism adds persistence, a
etc. factor that can be crucial on a service platform. When
a service is not available, the use of communication
As a complement to the discovery of web services in mechanisms that provide persistence makes it possible
the absence of a UDDI catalogue, Microsoft offers the to maintain the information about the request so as to
function of dynamic discovery through the Discovery process it when the service becomes accessible once
protocol. The definition of the web service container in more.
a WSDL file is only useful when we know how to locate
and use it. Where there is no service catalogue such However, when it is necessary to execute more than
as UDDI, the files of the Discovery protocol may be one service to resolve a business process, how do we
TRANSACTIONS SECURITy TRANSACTIONS METADATA
> WS-Coordination > WS-Security SECURITy MESSAGING > WSDL
> WS-AtomicTransaction > WS-SecureConversation > WS-ReliableMessaging > WS-Policy
> WS-BusinessActivity > WS-SecurityPolicy > WS-PolicyAssection
> WS-Trust > WS-PolicyAttachment
> WS-Federation > WS-Discovery
> WS-Single Sign-On > WS-MetadataExchange
> SOAP > MTOM (Attachments) > WS-Eventing > SOAP-over-UDP
> WS-Addressing > WS-Enumeration > WS-Transfer
> XML > Namespaces in XML > XML Information Set
ensure coordination during execution? By means of mOniTOring
transactionality? And what happens to security?
Service orchestration may be designed by In service oriented architecture, it is indispensable to
programming, whereby the developer coordinates the be aware at all times of the availability of resources and
calls to the operations offered by different services. This their employment status.
requires an environment that facilitates the coordinated
execution of the services required by the process, that Visual Studio, with its types of System.Diagnostics
simplifies the management of security on all levels, that namespace, facilitates the design and development
brings about the monitoring of the resources employed of parts of the architecture for tracing and auditing,
throughout the execution process and, above all, that making it possible to configure levels of detail for the
is supported by a transaction manager capable of information, apply criteria for the consumption of the
processing several operations as a single transaction events generated, or assign different repositories for the
unit. logs as MSM Queues, DBs, or text files.
And how are services executed? Visual Studio also
SEcUriTy offers an extensive set of performance metres that make
it possible to obtain service status “shots” indicating
Microsoft participates together with Sun in the memory, consumption, number of execution threads
process of defining the basic specifications for and requests processed… providing a complete
the implementation of Single Sign–On. This type perspective that makes it possible to measure service
of authentication enables a user to obtain access implementation quality on the basis of the resources
privilege to several systems through a single petition for consumed.
In order to have a thorough knowledge of the status
When several services offered by multiple platforms of service provider resources, it is possible to use the
are executed in a coordinated manner, this way of advantages of Windows Management Instrumentation.
functioning simplifies security management. This monitoring infrastructure makes it possible to
measure the transaction load that a process requires,
Microsoft integrates SSO into its server products (IIS, the memory consumption involved in the execution of
SQL Server, BizTalk Server etc.), such that once a user an operation, or its response time.
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
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. “ThE pOSSiBiliTy Of USing
mESSAgE qUEUES AS A
mEchAniSm Of cOmmUnicATiOnS
AddS pErSiSTEncE, A crUciAl
fAcTOr On A SErvicE plATfOrm.”