EBSOA Best Practices: Service-Oriented Integration

EBSOA Best Practices

Service-Oriented Integration

This document was prepared by Integrated Software Specialists, Inc. (“ISS”) and is to be considered confidential and proprietary to ISS and Iowa Department of Administrative Services.

ISS BEST PRACTICE GUIDESERVICE-ORIENTED INTEGRATION

6/15/06VERSION 0.8

Copyright 2006 by Integrated Software Specialists (“ISS”), Inc. and The State of Iowa Department of Administrative Services (“DAS”). The copyright to these materials and any accompanying software is owned, without reservation, by ISS and The State of Iowa DAS. These materials may not be copied in whole or part without the express written permission of ISS and The State of Iowa DAS.

iOpen™, iOpen ABie™, iOpen ABef™, iOpen ABes™, iOpen ABin™, iInspect™, iDetect™, and SureStart™ are some of the trademarks owned by ISS. Other trademarks and trade names in this documentation are owned by other companies and are used for product and company identification and information only. All rights reserved. ISS is the owner of other registered and unregistered trademarks. The above list is not exhaustive.

Contact Us

Integrated Software Specialists, Inc.1901 N. Roselle RoadSuite 450Schaumburg, IL. 601951-888-477-0001

If you have suggestions for this publication, send an e-mail message to: [email protected]. Your message is answered by our ISS Documentation Group.

Visit our home page at http://www.issintl.com for more information about ISS products and services.

CONFIDENTIAL 2023 INTEGRATED SOFTWARE SPECIALISTS, INC. PAGE 2


6/15/06VERSION 0.8

Table of Contents

1 INTRODUCTION............................................................................................................................4

1.1 Purpose........................................................................................................................................4

1.2 Scope...........................................................................................................................................4

2 INTEGRATION CHALLENGES................................................................................................5

2.1 current it landscape.....................................................................................................................5

2.2 SOA and Web services...............................................................................................................5

2.3 point-to-point web services.........................................................................................................6

3 BEST PRACTICES........................................................................................................................7

3.1 validate the use of web services..................................................................................................7

3.2 avoid point-to-point integration..................................................................................................7

3.3 ensure web services interoperability...........................................................................................8

3.4 promote robustness with advanced web services........................................................................8

3.5 service-enable legacy functionality.............................................................................................9

3.6 allow different types of consumers...........................................................................................10

3.7 apply enterprise integration patterns.........................................................................................10

3.8 test often, test early...................................................................................................................11

3.9 guarantee transactional interoperability....................................................................................12

3.10 achieve acceptable performance.............................................................................................13

3.10.1 Manage large and complex SOAP messages and binary files..........................................13

3.10.2 Avoid chatty calls..............................................................................................................14

3.10.3 Use Literal Message Encoding for Parameter Formatting..............................................14

3.10.4 Execute performance/load tests early...............................................................................14

3.11 provide control and visibility of integration environment.....................................................15



6/15/06VERSION 0.8

1 Introduction

1.1 PURPOSE

This best practice guide provides a high-level overview of Service-Oriented Integration, which is a method of integrating systems utilizing Service-Oriented Architecture (SOA).

Information in this guide covers the following topics:

The integration challenges that state governments currently face and how SOA and Web Services represent a compelling solution to overcome those challenges.

Best practices of integration initiatives to leverage the power and flexibility of Web Services strategically within and outside an agency, which means building loosely coupled, standards-based SOA.

1.2 SCOPE

Service-orientation represents the next major trend in enterprise computing, and as such, requires a new perspective, techniques, and tools for implementing technology solutions that meet the needs of business.

The best practices described in this document only touch upon Service-Oriented Integration. Other SOA-related topics such as Data Standards, Service Modeling, Web Services Security, Web Services Infrastructure or Platform Infrastructure are covered in other ISS EBSOA best practice guides.



6/15/06VERSION 0.8

2 Integration Challenges

Existing and emerging business and technical practices are leading the need for a new approach to integration. Business drivers such as changes in economic conditions and regulatory compliance require significant changes in the way organizations view application integration and data sharing.

However, there are major challenges to overcome. Organizations are concerned with connectivity issues. This prevents them from moving forward with automating business processes. Also, information is locked up in applications within different departments and organizations, and it is both time-consuming and costly to acquire, move, and utilize data. Techniques such as ETL, batch transfer, replication and file transfers are probably the most popular means of integration today.

2.1 CURRENT IT LANDSCAPE

Current IT architecture is the result of years of accumulating numerous enterprise-scale, integration solutions, including Mainframe, Midrange, DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), MOM (Message-Oriented Middleware), EAI (Enterprise Application Integration), .NET, Java EE and now Web Services.

In this environment, enterprise applications continue to be treated as silos of information. This is attributed to ineffective integration infrastructure that does not exist or can’t adapt to new and changing business requirements. The majority of applications that need to be integrated simply aren’t, and those applications that are integrated suffer from overly complex integration approaches. These applications have become unmanageable over time, due to a lack of cohesive integration strategy that can be applied broadly.

2.2 SOA AND WEB SERVICES

Service-Oriented Architecture (SOA) provides a cost-effective solution to the integration problem that most organizations are facing. SOA is an architectural style for building software applications that use services available in a network such as the Web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of well-defined business functionality that is consumed by clients in different applications or business processes.

Web services have taken the concept of services and implemented it as services delivered over the Web. Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI). These standards provide a common approach for defining, publishing, and using Web services.



6/15/06VERSION 0.8

2.3 POINT-TO-POINT WEB SERVICES

Most existing Web Services implementations consist of services that address a limited set of business functions between a defined set of cooperating parties, and they use HTTP (an unreliable transport) as the communication mechanism. These implementations have demonstrated the efficacy of the Web Services technologies in integrating heterogeneous systems both within and among organizations.

By enabling or adding Web Service interactions using existing Internet or intranet infrastructure between systems in an architecture, many individual point-to-point integrations have been created. Although the use of SOAP/HTTP and WSDL has many advantages, there are some shortcomings with these technologies.. Control over service addressing and routing is dispersed between client invocation code, adapter configurations, and the DNS infrastructure. There is no single point of infrastructure control that promotes a point-to-point integration style. In addition, service consumer and provider code tend to be bound to service invocations over specific protocols and to specific addresses. There is no capability to substitute a service provider’s implementation for another without changing the service consumers.

These implementations are known to be difficult to maintain and evolve, hence the broad use of Enterprise Application Integration middleware supporting hub-and-spoke integration patterns.



6/15/06VERSION 0.8

3 Best Practices

3.1 VALIDATE THE USE OF WEB SERVICES

Management needs to make conscious decisions about where it utilizes Web Services and make these decisions based on technical requirements that address business needs. In some cases these decisions will involve trade-offs, but with proper requirements gathering and prioritization, many of these choices will be obvious and easily justified.

Web services should only be employed where you have clear requirements that justify them. The justification can be either:

Quantitative: Where interoperability is possible between disparate systems with different programming models.

Qualitative: Where positioning your business assets to align with a corporate strategy will result in measurable benefits (i.e.: reuse of legacy code to enable Java EE, .Net, and Web applications to provide aggregated services).

3.2 AVOID POINT-TO-POINT INTEGRATION

Although basic Web Services technologies, particularly SOAP, WSDL, UDDI and HTTP, offer a certain expectation of service to SOA by simply using existing Internet and intranet infrastructures, many enterprise requirements demand higher qualities of service, and that requires a dedicated infrastructure. This infrastructure must support established basic Web services technologies, established middleware communication technologies such as MOM, CORBA, .NET, Java EE, EAI, databases, and, eventually, emerging standards such as WS-ReliableMessaging, WS-Security, among others.

These requirements to provide an appropriately capable and manageable infrastructure for Web Services and SOA are coalescing into the concept of the Enterprise Service Bus. The Enterprise Service Bus (ESB) is a standard-based, distributed integration platform that combines messaging, Web services, event-driven architecture, message transformation, and intelligent routing to loosely connect and coordinate the interaction of numerous enterprise applications across the organization and extended organization with reliability and integrity. The ESB is a key component of an Enterprise SOA that provides multiple levels of infrastructure support to services including:

Separation of transport (communication protocols) from service implementation to stress both location transparency and interoperability

Governance around implementation-independent service interfaces

Definition of services that provide encapsulation of existing business functionality



6/15/06VERSION 0.8

Some people think an ESB is a product that can be acquired from a vendor while others think it is a set of standards. In our opinion, it is really infrastructure capability that can be built in-house using technologies and tools that your organization may already own.

One of the primary reasons for adopting an ESB is that it can solve point-to-point problems in an efficient manner and deliver high performance.

3.3 ENSURE WEB SERVICES INTEROPERABILITY

The fundamental premise of Web Services is that standardization, predicated on the promise of easy interoperability, resolves many of the long-standing issues facing business today. However, the technologies and specifications that various organizations are defining for Web Services are in flux.

For Web Services to be successful, these specifications must provide interoperability that is in the best interest of all industry participants. For this reason, the Web Services Interoperability (WS-I) Organization was created. Among the deliverables that WS-I is creating are profiles, testing tools, use case scenarios, and sample applications.

A profile consists of a list of Web Services specifications at specified version levels, along with recommended guidelines for use, or the exclusion of inadequately specified features. The basic profile (WS-I Basic Profile) consists of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications that promote interoperability.

The testing tools monitor and analyze interactions with and between Web Services to ensure that exchanged messages conform to the WS-I profile guidelines.

Sample applications are being developed to demonstrate the implementation of applications that are built from Web Services Usage Scenarios, which conform to a given set of profiles.

3.4 PROMOTE ROBUSTNESS WITH ADVANCED WEB SERVICES

WS-ReliableMessaging, WS-Addressing, WS-Security and WS-Policy are standards that support an interoperable foundation of secure, reliable, and large-scale Enterprise SOA. Without these advanced specifications, Web Services are restricted to unreliable protocols, expose end-to-end message flow to security risk, are difficult to integrate with existing security infrastructure, and are restricted to simple request-reply interactions, which limit their usefulness in large-scale Enterprise SOA.

WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with a message exchange. It decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web Service message.

WS-Policy provides a flexible and extensible grammar for expressing the quality of services aspects, non-functional requirements, and general characteristics of entities in a Web Services-based system. WS-Policy defines a framework and a model for the expression of these properties as



6/15/06VERSION 0.8

policies. Policy expressions allow for both simple declarative assertions, as well as more sophisticated conditional assertions. WS-Policy defines a policy to be a collection of one or more policy assertions.

WS-ReliableMessaging describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The protocol is described in this specification in an independent manner allowing it to be implemented using different network transport technologies. To support interoperable Web services, a SOAP binding is defined within this specification.

WS-Security is the basic building block for securing Web Services. HTTP-S and BASIC-Auth authentication are often used to secure Web Service communications. While this simple transport-level security is sufficient for simple, point-to-point Web Services, their use is vulnerable to security breaches in multi-hop networked interactions. WS-Security provides a general-purpose and extensible mechanism that can support multiple encryption technologies, trust domains, and security tokens used for authentication or authorization. Because WS-Security per-message encryption and signing support messages from many users on a single connection, WS-Security solves the scalability issue inherent in transport-level security mechanisms such as HTTP-S. In addition, WS-Security specifies how to encode X.509 certificates and Kerberos tickets, making it simple to integrate with widely-used security infrastructures.

For more information about the security aspects of Web Services, see the Web Services Security document.

Using these specifications together provides significant synergies. WS-ReliableMessaging itself requires WS-Addressing. The multi-hop complex service interactions supported by WS-Addressing can be secured end-to-end with WS-Security. Lastly, to achieve any significant level of scale in a loosely-coupled environment, WS-Policy is a practical prerequisite for use of WS-ReliableMessaging and WS-Security, as it provides a general mechanism to define the conditions under which they are to be used with a given service.

3.5 SERVICE-ENABLE LEGACY FUNCTIONALITY

The idea of using platform-independent Web Services technology to provide non-invasive access to back-end mainframe applications offers value because it enables organizations to cost-effectively reuse valuable legacy assets without adopting expensive and risky rip-and-replace strategies.

However, implementing Web Service access to back-end applications is not a simple task due to the fact that not all back-end applications benefit from being opened up. The key is to identify the applications that can benefit from front-end Web Services access, and then select those that will provide the most benefit.

Legacy systems can be service-enabled by defining a Legacy Service Gateway (in WSDL) between disparate software systems such as databases, Java EE, CORBA, .NET, Mainframe (e.g.: CICS,



6/15/06VERSION 0.8

IMS), packaged applications, etc; and, by providing SOAP applications that can receive SOAP messages and convert them into message-level or API-level invocations of the legacy systems.

In this manner, when a service consumer needs legacy functionality, it sends SOAP messages over HTTP to a legacy service gateway, which in turn, converts the SOAP messages into the corresponding native format expected by the legacy application. The legacy service gateway sends the native messages to the legacy application through a standard-based connector (.NET, JMS, JCA, ODBC, JDBC, etc). The legacy service gateway is also responsible for converting any responses from the legacy system into SOAP messages and routing them back to the service consumer.

It is important to point out that service-enabling legacy functionality may also provide a clear way to phase out legacy systems in favor of newer custom-built implementations or package applications.

3.6 ALLOW DIFFERENT TYPES OF CONSUMERS

SOA is extremely effective at implementing multi-channel applications. A multi-channel application is designed to provide any consumer with access to a common set of business services. Consumers employ a diverse set of end-user technologies such as Internet, call centers, voice, agency-to-agency, and WAP applications when utilizing a multi-channel application.

Multi-channel applications need the architectural elements that mediate between the diverse consumers and the internal communication infrastructure and business services (support for common data formats and protocols, support for common message exchange patterns, protocol bridging, message transformation, etc). Additionally, multi-channel applications need the communication infrastructure to provide the enterprise-wide middleware and messaging systems that connect internal systems and provide them with enterprise qualities of services (intelligent routing, multi-level security, associated Web Services standards). Supporting the architecture are the services responsible for providing uniform access to business services (service lookup, message transformation and validation), as well as security and system management/monitoring services that cross all layers of the architecture.

3.7 APPLY ENTERPRISE INTEGRATION PATTERNS

Delivering integration solutions is a challenging task. There are many conflicting drivers and even more possible “right” solutions. Most vendors provide methodologies and best practices. These instructions tend to be very much geared towards their products. The end result is they do not offer the global perspective often required for establishing strategic direction.

Patterns are a proven way to capture experts’ knowledge in fields where there are no simple “one size fits all” answers. Each pattern poses a specific problem, discusses the considerations surrounding the problem, and presents an elegant solution that balances the various forces or drivers. In most cases, the solution is not the first approach that comes to mind, but one that has evolved through actual use over time. As a result, each pattern incorporates the experience base that



6/15/06VERSION 0.8

senior integration developers and architects have gained by repeatedly building solutions and learning from their mistakes.

Gregor Hohpe has identified sixty-five (65) patterns so far and organized them into the following categories:

Integration Styles document different ways applications can be integrated. These patterns present somewhat of a historical account of integration technologies. All subsequent patterns follow the Messaging style.

Channel Patterns describe the fundamental attributes of a messaging system. These patterns are implemented by most messaging systems. This section focuses on the interrelationships between different features and highlights implementation trade-off made by different vendors.

Message Construction Patterns describe the intent, form and content of the messages that travel across the messaging system. The base pattern for this section is the Message pattern.

Routing Patterns discuss mechanisms to direct messages from a sender to the correct receiver. Message routing patterns consume messages from one channel and republish the message to another channel that is determined by a varying set of conditions. The message content is not modified. The patterns presented in this section are special cases of the Message Router base pattern.

Transformation Patterns change the information content of a message. In many cases, a message format needs to be changed due to different data formats used by the sending and the receiving system. Data may have to be added, taken away or existing data may have to be rearranged. The base pattern for this section is the Message Translator.

Endpoint Patterns describe the behavior of messaging system clients. They illustrate different ways in which applications can produce or consume messages.

System Management Patterns provide the tools to keep a complex message-based system running. Messages are generated, routed, transformed and consumed. The solution has to deal with error conditions, performance bottlenecks and changes in the participating systems. Message management patterns address these requirements.

For more information, review the Enterprise Integration Patterns Web site at:

enterpriseintegrationpatterns.com.

3.8 TEST OFTEN, TEST EARLY

A key requirement for an SOA is that the underlying components are available at anytime. As the number and breadth of SOA implementations increase, maintaining sufficient quality has emerged as a significant challenge. Web Services consists of distributed components or applications, developed in different languages and running on multiple platforms, connected by synchronous or asynchronous infrastructure. In an SOA solution, it is difficult to anticipate the usage of the services since the goal of the SOA is to allow the creation of new, complex applications on top of these



6/15/06VERSION 0.8

services. This requires the team to be more stringent in specifying exact interfaces for services and to test for all possible scenarios.

It is necessary to have an SOA quality platform that meets the needs of multi-disciplinary (and sometimes distributed) teams that must work together during all phases of the SOA lifecycle. In general, tools should provide comprehensive support for the different aspects of software testing such as:

Functional and Regression testing entail Unit, Compliance, Process and Data-driven testing:

Unit testing: validate that each Web Service operation functions as stated

Compliance testing: validate that the Web Service returns results compliant with its definition

Process testing: validate that a sequence of Web service invocations fulfills a required business process

Data-driven testing: validate that any of the above-mentioned tests works as required with data input from external sources (e.g.: database or another Web service)

Non-functional testing verifies scalability, robustness, and fail-over requirements

Performance and load testing (refer to section 3.5.4 for more details)

Coverage analysis drives the quality of the unit testing as it discovers sections of code that are not being adequately exercised by your unit tests. In addition, it is helpful to determine whether test suites are getting out of date or not.

Static Code analysis is the term applied to the analysis of software that is performed without actually executing programs built from that software. It helps to:

Look for potential problems or bugs related to correctness, performance, multi-threaded and internationalization by doing data flow analysis

Generate design quality metrics for each component, which measure the quality of a design in terms of its extensibility, reusability, and maintainability to effectively manage and control package dependencies

Determine cyclomatic complexity, which measures the number of linearly independent paths through the source code

3.9 GUARANTEE TRANSACTIONAL INTEROPERABILITY

In a Web Services world, solutions are constructed from the interconnection and operation of Web Services. To obtain a reliable outcome, involved services must universally agree on an undisputed resolution. Transactions are an accepted approach used widely in systems that meet this requirement. One of the most important aspects of transaction processing technologies is their ability to recover an application to a known state following any type of failure.



6/15/06VERSION 0.8

Many Web Services may require only the transaction processing capabilities inherent in the underlying execution environment. Others may require multiple Web Services interactions to be grouped into a larger transaction unit, including a transactional context within SOAP headers so that the transaction can be coordinated across multiple execution environments.

Web Services transactions specifications extend the concept of the transaction coordinator, adapt the two-phase commit protocol for Web Services, and define new extended transaction protocols for more loosely coupled Web Services and orchestration flows. Web Services transaction specifications include:

WS-Transactions family (from BEA, IBM and Microsoft) consists of an extensible coordination framework (WS-Coordination) as well as specific coordination types for short-duration, ACID transactions (WS-AtomicTransaction) and long-running transactions (WS-BusinessActivity).

WS-Composite Application Framework (from OASIS) defines a model and service for composing multiple Web services in composite, transactional solutions. WS-Context defines a standalone context management system for generic context. WS-CoordinationFramework defines a coordinator for the basic context specification and the pluggable transaction protocols in the WS-TransactionManagement specification. WS-TransactionManagement defines three transaction protocols for the pluggable coordinator: ACID, long-running actions (compensation), and business process management.

WS-CAF is similar to capabilities provided by WS-Transactions.

3.10 ACHIEVE ACCEPTABLE PERFORMANCE

Successfully optimizing performance for Service-Oriented Integration is a combination of experience and discipline in being systematic in your organization’s approach to measuring criteria, analyzing information, and making sound adjustments. First, good decisions will need to be made during the architectural and design phases. Then, once there is an operational solution, utilize an iterative process to fine tune services by capturing measurements from simulated loads and making adjustments and measuring again to understand their influence.

3.10.1 Manage large and complex SOAP messages and binary files

One of the biggest technical and performance issues for Web Services occurs when a user or application is handling large binary files. Encoding binary data as XML produces huge files, which absorbs bandwidth and measurably slows down applications. For some devices, it slows down so much that the performance is considered unacceptable.

The W3C published recommendations that work with SOAP to address the specific issue of improving Web Services performance by providing standard methods and mechanisms for transmitting large binary data. By enabling a more efficient way to serialize and transmit a SOAP message (XOP and MTOM), and by sending all the data needed to process the message, even when the data would not be readily available (RRSHB), Web Services become faster and more usable.



6/15/06VERSION 0.8

XML-binary Optimized Packaging (XOP) provides a standard method for applications to include binary data along with an XML document in a package. As a result, applications need less space to store the data and less bandwidth to transmit it. XOP works at the XML Information Set (Infoset) level, allowing the same abstract representation of a XML document to be serialized in different ways.

Message Transmission Optimization Mechanism (MTOM) uses the features provided by XOP to address SOAP messages. MTOM defines a "Transmission Optimization" feature that enables SOAP bindings to optimize the transmission and/or the wire format used to transfer a SOAP message. It also defines a concrete implementation of this feature, using HTTP and XOP to send the various binary parts as well as the SOAP message in a MIME envelope, reducing the bandwidth and the time used to encode/decode such data.

Resource Representation SOAP Header Block (RRSHB) gives applications a local shortcut to resources. It allows SOAP message recipients to access cached representations of external resources. This is important, as there may be times when there are either limits to bandwidth or access of files. It gives the recipient the option of using either the original file that may be identified by a URI, or to use a cached copy that accompanies the actual SOAP message. Used with MTOM, it enhances greatly the speed and of processing as the external data is already present when the recipient starts processing the message.

3.10.2 Avoid chatty calls

Network round trips to and from a Web Service can be expensive. This issue is magnified if clients need to issue multiple requests to a Web Service to complete a single logical operation.

As a performance rule, strive to design coarse-grain services that themselves accept all necessary parameters and information, thereby allowing the service provider to accomplish as much as possible on behalf of the consuming application. The goal is to minimize the number of requests a consumer makes in order to accomplish a set of business tasks. This will ensure minimal effects due to network latency, system I/O, and thread/process wait states that when aggregated with multiple requests, can result in significant delays.

3.10.3 Use Literal Message Encoding for Parameter Formatting

The encoded formatting of the parameters in messages creates larger messages than literal message encoding (literal message encoding is the default). In general, you should use literal format unless you are forced to switch to SOAP encoding for interoperability with a Web Services platform that does not support the literal format.

3.10.4 Execute performance/load tests early

Consumers of Web Services must have assurances that Web Services meet acceptable performance criteria in normal conditions and under stress. The goal of performance or load testing a Web Service is to find how a Web Service scales as the number of consumers accessing it increases. In addition, to gather the performance and stability information of the server such as throughput, CPU



6/15/06VERSION 0.8

usage, the time taken to get a response from a Web method, etc. when there are, for instance, 5, 50, 200, 500 concurrent users or more.

Therefore, select easy-to-use tools that realistically inspect, invoke, and simulate load on a Web service either interactively or as part of an automated build/integration process; and identify performance bottlenecks and failures within your Web Service applications.

NOTE: Performance best practices for the implementation language of a service will apply as well.

3.11 PROVIDE CONTROL AND VISIBILITY OF INTEGRATION ENVIRONMENT

Current IT environments are a complex collection of heterogeneous systems management technologies and solutions. These heterogeneous IT resources rely upon an ever increasing variety of heterogeneous management technologies. Yet, it is often difficult to achieve an acceptable level of integration among different enterprise management systems to provide an overall view of cross-application and end-to-end business processes.

The ability for organizations to manage a diverse, dynamic and distributed environment will become critical as they roll out Web Services, which can process thousands or even millions of messages in a day. This management aspect includes controlling the life cycle of the service and collecting information about existence, availability, and health. For example, system administrators need to find out whether or not a given Web Service is ready for consumption, or why a key server became unavailable, or if a legacy system is overloaded, or the reason why a request is taking too long.

These questions precipitate the need for standards enabling the integration and accommodation of the full variety of means for managing IT resources. Standards such as JMX (Java Management Extensions), WMI (Windows Management Instrumentation) and WSDM (Web Services Distributed Management) are good examples.

For additional information on Management of Web Services, review the Platform Infrastructure best practice document.


Documents

EBSOA Best Practices: Service-Oriented Integration