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 GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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 Road
Suite 450
Schaumburg, IL. 60195
1-888-477-0001
If you have suggestions for this publication, send an e-mail message to: docs@issintl.com. 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

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 2

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

Table of Contents
1

INTRODUCTION..........................................................................................................................4
1.1

Purpose........................................................................................................................................4

1.2

Scope...........................................................................................................................................4

INTEGRATION CHALLENGES.................................................................................................5
2.1

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

2.2

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

2.3

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

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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 3

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

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, standardsbased 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.

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 4

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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 cant adapt to new and
changing business requirements. The majority of applications that need to be integrated simply
arent, 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.

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 5

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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 providers 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.

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 6

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 7

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 8

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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 transportlevel 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, WSSecurity 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 WSReliableMessaging 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,

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 9

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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-toagency, 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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 10

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 11

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

since the goal of the SOA is to allow the creation of new, complex applications on top of these
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, multithreaded 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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 12

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

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.
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 shortduration, ACID transactions (WS-AtomicTransaction) and long-running transactions (WSBusinessActivity).
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 organizations 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
CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 13

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

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.
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

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 14

ISS BEST PRACTICE GUIDE

SERVICE-ORIENTED INTEGRATION
6/15/06
VERSION 0.8

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
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 crossapplication 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.

CONFIDENTIAL

2015 INTEGRATED SOFTWARE SPECIALISTS, INC.

PAGE 15