SOA: Service Oriented Architecture

898 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
898
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
36
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA: Service Oriented Architecture

  1. 1. SOA: Service Oriented Architecture White Paper (Technical Appendix) A real technology for a new collaborative philosophy between applications and business processes 1
  2. 2. 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 BTP 11 WS-Transaction/WS-Coordination 11 JAXTX 11 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 Security 25 Monitoring 25 Transactionality 26 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 2
  3. 3. ABSTRACT 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. 3
  4. 4. SOA CONCEPTS 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 on ati e ific ote ed ec eleas t t Sp R raf allo vie w CV orm the inal al D l B Re pti on &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 4
  5. 5. 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 5
  6. 6. 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 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. 6
  7. 7. 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: 7
  8. 8. 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 XML messages. 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 SOAP message Transport channel problems. security (SSL) 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. services. 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. 8
  9. 9. 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 April 2002 WS-Security WS-Security members of OASIS), it is verified that, in principle, both Addendum 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 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 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 9
  10. 10. 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: Atomic set es Reserv HOTEL ation EXPENSIVE Res Reserv (participant) erv made AIRLINE B mad ation (participant) e Res Reserves erve s Reservation AIRLINE A made (participant) s Prepare OVERBOOKING Res ble erve AIRLINE C Unavaila s (participant) Res COORDINATOR / erv COMPOSER mad ation CAR RENTAL e (participant) 10
  11. 11. BTp JAXTX 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 administration architecture. 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. 11
  12. 12. 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. JmX ArchiTEcTUrE REMOTE MANAGER JMX WEB SNMP Manager Browser Manager SERVER CONNECTOR LEVEL RMI HTTP SNMP Adaptor Adaptor Adaptor AGENT LEVEL MBean Server INSTRUMENTATION LEVEL MBeans MBeans Application 12
  13. 13. 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. 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. “middleWare introduCes A fUndAmEnTAl 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 (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 13
  14. 14. 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.” BUSinESS prOcESS AGENT CALL ADDRESSED ADDRESSED CRM BPA CENTER SySTEM 1 SySTEM 2 Search for client Search for client Create Client in System 1 Does Create Client it exist? Error? NO YES Create Client in Create Client System 2 Gather client Create Client data Error? 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 14
  15. 15. 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 AdvAncing EAi.” cOmpOnEnTS Of An inTEgrATiOn SUiTE APPLICATION 1 APPLICATION 2 APPLICATION 3 APPLICATION 4 ADAPTOR ADAPTOR ADAPTOR ADAPTOR SERVICE BUS Business Activity Monitoring and Monitoring / Business Process Business Process Deployment and Configuration Control Complex Event Management Automation management and Status Correlation Repositories 15
  16. 16. 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 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 16
  17. 17. 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, CONFIGURATION Start-up Manager as the mechanism by which the services become public. The adaptor acts as a bridge between the Configuration Manager independent worlds of the application and the Service Bus, translating between protocols in order to establish communication. Event Loop Service Container wEB SErvicES The recent rise of web services has brought about a clear convergence of integration suites towards Trace Management the principles on which this technology is based. In consequence, all the principal manufacturers of integration suites within the scope of EAI have Monitoring Stop incorporated SOAP (Simple Object Access Protocol) Manager 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. repository. > Module for managing event loops. > Container module for services or call-backs that provide the functionality necessary to resolve a bus Business Service. “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 TEchnOlOgy.” 17
  18. 18. 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 CONSUMER PRODUCER 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 detected (integrity). 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.” 18
  19. 19. 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 ACL ACL DB CONNECTOR CONNECTOR CONNECTOR CONNECTOR Security Security Security API API PROXy API ESB 19
  20. 20. 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. cOnnEcTOr-BASEd SEcUriTy 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 information exchanges. 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, cliEnT idEnTiTy.” 20
  21. 21. 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. 21
  22. 22. 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 2 1 The application defines the APPLICATION 1 The application uses the requirements of the transaction with resources of a set of managers the Transaction Monitor Interface (TX) TRANSACTION MONITOR RESOURCE MANAGER 3 The Transaction Monitor and the Resource Managers exchange information over the XA interface 22
  23. 23. 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 23
  24. 24. 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 SOA prOTOcOlS 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 MESSAGING > SOAP > MTOM (Attachments) > WS-Eventing > SOAP-over-UDP > WS-Addressing > WS-Enumeration > WS-Transfer XML > XML > Namespaces in XML > XML Information Set 24
  25. 25. 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. authentication. 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 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. “ThE pOSSiBiliTy Of USing mESSAgE qUEUES AS A mEchAniSm Of cOmmUnicATiOnS AddS pErSiSTEncE, A crUciAl fAcTOr On A SErvicE plATfOrm.” 25

×