Web Services Network Infrastructure Best Practices

EBSOA Best Practices

Web Services Infrastructure

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 GUIDEWEB SERVICES INFRASTRUCTURE

7/31/2006VERSION 0.9

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


7/31/2006VERSION 0.9

Table of Contents

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

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

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

2 BEST PRACTICES........................................................................................................................5

2.1 IMPLEMENT SERVICE registries USING OPEN STANDARDS..........................................5

2.1.1 Service Registry Recommendation for the State of Iowa.......................................................6

2.1.2 UDDI Introduction................................................................................................................7

2.1.3 Define Business Entities........................................................................................................8

2.1.4 Understand the Role of WSDL in UDDI...............................................................................9

2.2 Describe your services through WSDL design...........................................................................9

2.2.1 Apply Design Guidelines.......................................................................................................9

2.2.2 Integrate with UDDI............................................................................................................10

2.3 Understand which wire formats and protocols fit your needs..................................................10

2.3.1 HTTP...................................................................................................................................11

2.3.2 SOAP...................................................................................................................................11

2.3.3 JMS......................................................................................................................................12

2.3.4 WS-ReliableMessaging........................................................................................................13

2.4 USE A WEB SERVICES GATEWAY....................................................................................13

2.4.1 Process Execution................................................................................................................13

2.4.2 Design Considerations........................................................................................................13

2.4.3 Don’t Forget Security..........................................................................................................14

2.5 manage and monitor your environment....................................................................................14

2.6 DO THE GRID.........................................................................................................................14



7/31/2006VERSION 0.9

1 Introduction

1.1 PURPOSE

This best practice guide provides a good understanding of the logical component blocks that need to be in place in a Web Services infrastructure and includes explanations on best practices and recommendations in order to support, maintain, configure and monitor web services execution and interactions. Once these logical component blocks are well understood, this document will proceed to explain their roles in the foundation framework and how they interoperate with each other.

1.2 SCOPE

This document does not go into detailed best practice concepts related to load balancing, failover, replication, IP spraying, DNS round robin, reverse proxy, etc. Subjects related to hardware configuration and server node layout are beyond the scope of this document. This best practice document will not be specific to commercial or open source products that enable a Web service network infrastructure. If more details regarding these subjects are needed, they can be found in the Platform Infrastructure best practice document.



7/31/2006VERSION 0.9

2 Best Practices

The definition of infrastructure is “the underlying base, foundation or basic framework of a system or an organization”. The infrastructure provides a series of interconnected structural elements that provides the framework to start building and deploying on top of it.

When designing an infrastructure, the primary goal is to set up the basic framework so it can support a Web Services implementation. Once it is set up, the infrastructure has to be deployed having system operations, administration, manageability and monitoring in mind. From an operational perspective, when you need to deploy a new Web Service, it should be hassle free, easy to monitor its status, and easy to manage its day to day operation.

There are four critical components for a Web Services infrastructure:

Service Registry & Discovery Web Service Description Web Service Wire Formats Web Service Gateway

Their interrelationships and best practice discussions on using which method to deploy them will be discussed in detail later.

2.1 IMPLEMENT SERVICE REGISTRIES USING OPEN STANDARDS

A good Web Service implementation has three principal actors: a service provider, a service requestor and a service registry. A service provider publishes a service to the registry, and a service requestor finds a service description by querying the service registry.

A Web Service Directory is a registry-based approach that hosts information about a service but not the service itself. In this centralized registry, requestors can query information about services based on metadata or any other criteria supported by the registry. Once the information about the queried service is found, the registry delivers a service description that is used by the service requestor to bind to the service and execute it.

Service requestors are usually regular users or business analysts that want to fulfill a specific need and perform a search on the service registry through a web portal or search engines built for this purpose. The next step for the service registry is to find what services are available that might meet the needs of the requestor. Service providers could be application developers or technical users that, through an API, publish the Web Service information so it can become searchable in the service registry. These technical users can also query the registry in order to find other services that they can leverage to build and publish new services.



7/31/2006VERSION 0.9

The best approach to implement a service registry is by using open standards, which should be platform independent. The structure of this registry, the way the service information is stored, the protocols and means to find services information in this registry should be based on an open specification that will not lock-in the registry services information in a proprietary product.

2.1.1 Service Registry Recommendation for the State of Iowa

The Iowa EBSOA initiative is a strategic long term project that involves taking steps to achieve greater adaptation and associated EBSOA maturity over time. Given the size and complexity of this initiative, the EBSOA maturity time-line will span years. We see a great future in Universal Description, Discovery, and Integration (UDDI) as a service registry implementation and recommend that the State of Iowa consider it, along with associated UDDI management technology as a long-term strategy. As Gartner says, “UDDI is one of the foundational cornerstones of Web Services (along with SOAP and XML).”

However, UDDI and the associated tools market are still evolving and at a rapid pace. Current UDDI enablement technologies are complex and expensive. Vendors, trying to capture major market-share of the projected billion dollar UDDI technology market place, are racing to deliver new products that are better and cheaper.

For organizations that are new to SOA and web services, adopting UDDI can be frustrating. In our opinion, it adds a level on complexity that is not necessary or initially valuable for new SOA adopters.

Given the above, and due to the current SOA maturity level of the State of Iowa, we recommend that the State of Iowa delay adaptation of UDDI at this time. Instead, we recommend that the state initially adopt a simpler form of service registry and grow into the need for UDDI and related management tools.

For the PoC, EBSOA Expansion Plan for the PoC and for the initial levels of maturity, we recommend that the state adopt a simpler approach for service registries. For now, our recommendation is to implement a service registry in the form of a Website and Enterprise Content Management (ECM) system, where all service descriptions are published, categorized with meta-data information like:

Service owners Stage agency, programs or bureaus responsible for the service Web Service documentation and specification. A hyperlink to the Web Service Description Language (WSDL) file that

describes the service Ways to browse and search published services



7/31/2006VERSION 0.9

This services registry website can be built internally for minimal cost. It can then be accessed and shared state-wide by service providers and consumers alike. This capability will enable services to be catalogued and published for re-use. This approach will meet the state’s needs while its SOA governance processes and technology implementation evolves through time. Once the catalogue of web services grows to a level where a more robust management system is required, a more robust alternative should be considered.

UDDI is one strong service registry alternative. UDDI is not perfect although some form of UDDI will be needed for the future. By then, we believe that the industry will have matured enough to warrant adaptation of this technology. We encourage the State of Iowa to continuously evaluate the latest iteration of UDDI and consider it for the future.

The following points are a brief explanation for the future, it includes a description and implementation tips for UDDI.

2.1.2 UDDI Introduction

The UDDI project was created and is maintained by the OASIS consortium. UDDI is one of the major building blocks for building a SOA solution; it provides a platform independent way of describing services and discovering businesses through standard internet protocols and integrates them in the network.

At the technical level UDDI consists of a conceptual cloud of Web Services and a programmatic interface that enables service description. The UDDI specification consists of documents related to each other and an XML schema that defines a SOAP-based programming protocol for publishing and discovering Web Services.

One of the major advantages of UDDI is that it is a cross-industry effort that is driven by the major platform and technology providers that are members of the OASIS consortium. There are three types of information that can be published to the UDDI registry:

White pages—Provides basic contact information about a company, such as business name, address and contact information. It also provides unique identifiers like DUNS, which is a unique nine digit sequence widely accepted for identifying businesses. In summary, white pages allow service consumers to discover and locate business services based on business information.

Yellow pages—Describes a service based upon categorization and classification of information; in the UDDI world this categorization is called a taxonomy.

Green pages—Describes the service that the business offers. It provides technical information on the behaviors, supporting functions, and access points for the service.



7/31/2006VERSION 0.9

The UDDI specification structures an information model based on composed data structures called entities. The main entities are called businessEntity, businessService, bindingTemplate and tModel. There is an informational structural model that ties all four entities together, which defines the business that is exposing the service, the service description itself, the binding mechanisms to the service and specifics related to how to interact with the service.

Before embarking on a UDDI implementation one needs to first understand the capabilities and core concepts of UDDI and how to deploy it in the organization. More details on the UDDI specification can be found at the OASIS UDDI’s website at http://www.uddi.org. It is also highly recommended that one has a strong understanding of the use cases that drive the adoption of UDDI in the organization. Based on the requirements of the organization, UDDI should be designed having the following in mind:

Runtime binding

Design-time discovery

Reporting

Define policies based on how the UDDI registry is going to be managed, how it is going to be deployed and identify standard procedures for publishing services in the registry. Define who will have access to the registry and auditing requirements. How will the business entities and service metadata be modeled? Determine how the Web Services are going to be published and what type of access point is going to be used for the Web Service, which in most cases is a URL. Standards on defining the kind of data that is going to be provided with each service should be specified (documentation, policies, XML schema, etc.).

Once management policies are in place, the risk of polluting registry data will be minimized. Other things to keep in mind are conventions for naming businessEntity elements in the registry and identifying what information for business entities is mandatory.

2.1.3 Define Business Entities

In order to model a business entity in the registry using the businessEntity element you need to define elements that constitute a business entity. Is it going to be a service provider? Is it going to be an application, a business unit, or represent an external organization? Keep in mind, you should standardize ways to give user friendly, unique IDs to these elements in the UDDI registry. Avoid using Global Unique Identifiers (GUID). Also, factor in that businessEntity elements are the only element types in a UDDI that can be associated with contact elements. Determine an organizational chart, or to be more specific, the relationships between businessEntity elements in the registry.


http://www.uddi.org/


7/31/2006VERSION 0.9

2.1.4 Understand the Role of WSDL in UDDI

When it comes to WSDL, make sure that it is integrated and used in the UDDI registry. WSDL elements should be mapped to UDDI business entities and operations into the UDDI registry. With a UDDI solution in place, WSDL documents should reside in the registry. A few examples of mapping operations would be categorization of taxonomies. In order to identify an entity as an operation or as a service, operation reference taxonomy should map a service with its operations, and input/output reference type taxonomies should link an operation with its input and output types.

2.2 DESCRIBE YOUR SERVICES THROUGH WSDL DESIGN

WSDL stands for Web Services Description Language and is a standard created by the World Wide Web consortium (W3C). WSDL allows service providers to create a formal description document that contains information about service locations and interfaces. Service consumers can bind to the service through these formal service descriptions and can find out how to interact with the service through supported network protocols and data types. In this way, WSDL specifies an interface contract with the service consumer using a XML predefined format. In sum, the XML grammar that is described in the WSDL document contains the following elements:

Interface information that describes all functions Data type information for message requests and responses Binding information about the concrete protocol that is going to be used for the service Address information that specified a combination of the binding and network address

to be used The message itself which is an abstract definition of the data that is being transmitted

WSDL is used mostly to describe SOAP services.

One thing to take into account is that WSDL is not used to discover or find services. This is why UDDI is a critical part of the infrastructure and it should work together with WSDL in order to provide consistent service information. WSDL documents should be linked to UDDI registries and it should provide complementary information found in the UDDI registry.

2.2.1 Apply Design Guidelines

Try to use UML as much as possible to design the interactions and leverage development tools, WSDL and UDDI-aware tools to ease document and code generation.

Pay close attention on the target programming language platform where your service will be implemented. WSDL may be interpreted slightly differently based on target platform. It is very important to establish design standards for XML schemas that are going to define the



7/31/2006VERSION 0.9

WSDL documents. The design approach for the XML schemas will affect the WSDL design and the implementation of generated classes in the target platform. Some popular XML schema design patterns are the Russian Doll and the Venetian Blind design patterns.

2.2.2 Integrate with UDDI

As mentioned before, by establishing processes, standards, and policies in order to publish WSDL information into the UDDI, WSDL and UDDI should play together nicely. First, the WSDL interface definitions need to be created for a specific service. Service types will be defined and described with one or more service interface definition WSDL documents. The service interface definition includes all the information explained before (bindings, data type information, address, message, etc). The next step is to register the service interface definition in the UDDI as tModel elements and the pointer to the actual WSDL document will be specified in the tModel’s overviewDoc field. Such tModels are called wsdlSpec Models.

Developers that create business services should make sure that these services comply with the standard service definitions. Developers should retrieve the wsdlSpec Model manually or through the development environment that supports UDDI queries. Through these processes, the WSDL definition document is retrieved. Tools that support WSDL document management and definition will then be used to generate the implementation that supports the standard interfaces and bindings.

As a last step, the service should be deployed and registered to the UDDI registry. Preferably, using automated tools for UDDI and WSDL, the UDDI businessService data structure is generated and then registered.

2.3 UNDERSTAND WHICH WIRE FORMATS AND PROTOCOLS FIT YOUR NEEDS

Open Wire Formats are protocols that are understandable by any service allowing Web Services to exchange data and messages. Wire Formats describe the method used by which their service request and response messages are encoded and transported between the Web Service and its consumers. It enables open communication by using open protocol standards. The protocols used for Wire Formats are:

HTTP SOAP JMS WS-ReliableMessaging



7/31/2006VERSION 0.9

2.3.1 HTTP

If pure HTTP is used, the only operations that can be performed are:

HTTP-GET: Expects all the operation requests and arguments to be encoded as part of the Web Service URL. Think of it as a regular URL that specifies the resource needed (the Web Service), and the arguments that are going to be passed to the service (the query string of the URL).

HTTP-POST: The Web Service addressable entry point (the name of the resource) and its arguments are specified in the payload area of the HTTP-POST request as name and value pairs. The difference between HTTP-POST and HTTP-GET is that HTTP-GET passes all the information as part of the URL and HTTP-POST passes all necessary information as part of the HTTP header. It works the same way as a HTML form that is posted through the FORM HTML tag.

The main advantage on using HTTP as the main protocol to execute Web Services is that HTTP is a protocol supported everywhere and the service can be called through any web browser, even on PDAs or other devices that widely support HTTP as a communication protocol. The other advantage is that HTTP is a protocol that is mostly open on firewalls. The main disadvantages of using HTTP is that it is a protocol that wasn’t designed to transport application data, it is stateless by nature, and it doesn’t guarantee reliability on the message delivery. Also, if complex data types are required to send over the wire, a simple HTTP-POST will not be enough in order to specify the message format correctly.

2.3.2 SOAP

SOAP is a network and communication protocol that implements a basic messaging framework used for exchanging XML-based messages over the network. SOAP typically uses HTTP as its transport protocol. It was created to replace the XML-RPC protocol and extend it with more features.

SOAP-based Web Services can implement two messaging patterns, the RPC or the document style pattern (also known as the message-style or document-literal encoding). The RPC messaging pattern basically consists of a direct call from a client that sends a message request to execute an operation on the server, where the service provider resides. In turn, the service provider immediately sends a response message to the client. The SOAP request message consists of an XML message where the method parameters, return value, name of the operation to be called are specified. The data types of these parameters and return value are supposed to map directly into the data types of the service that resides on the server. These parameters and data mappings can be easily configured in a WSDL document and also can be used by the client-side code in order to generate the necessary stub code to call the service.



7/31/2006VERSION 0.9

On the other hand, the document-style pattern is a more abstract solution where it sends the XML document with any metadata that might be needed to transport it across the network. In summary, an RPC approach describes something specific, and the document-style approach can describe basically anything. Pros and cons exist when using any of these messaging patterns. The RPC messaging pattern is more specific to the service call, which means it is tied to the implementation on the server; hence it is easier for the server developer to use. RPC style documents are faster to implement and require less work. However, problems might arise if the interface on the server changes because the service requestor would break the contract established with the service provider. Also, RPC style documents cannot have one-way transmissions, which mean that a request will always expect a response, even if it has to be a void response. In summary, try to use document style messaging whenever possible, it might take more work but the effort will pay off in the long run.

Some other tips of advice. Try standardizing on the SOAP message style and format. Its default application layer protocol is HTTP, but it can also be used with SMTP. Use XML schemas whenever possible to achieve WSDL reusability. Standardize on XML naming schemas and pick a comprehensive XML development tool for document styling.

You should also be aware of SOAP limitations and weaknesses. SOAP is heavy on XML and is much slower than other competing technologies and is also slower than binary network protocols such as RMI. Although it’s easier for humans to read when compared to other standards, especially binary. Performance issues might not be a problem if the message to be sent is not too long. Regardless of its performance issues, SOAP is an adopted open standard; it’s a widely accepted approach for Web Services.

2.3.3 JMS

Java Message Service is a Message Oriented Middleware (MOM) protocol and API that is used to send messages between two clients. It was designed to achieve interoperability and message exchange asynchronously. The main advantage is that the sender does not need to know anything about the receiver and once the client sends the message, it can assume that the message was delivered. JMS guarantees message reliability. Both the sender and receiver don’t need to be available at the same time in order to achieve communication.

The main advantages of using JMS are that it offers reliable transport against HTTP, can easily implement asynchronous messaging, and allows for easier integration with legacy systems. The main disadvantages are that the client and the server must have a JMS compliant product on both ends. JMS is technology specific and will only work if both parties use Java as its programming model. Try to use open standards that are technology agnostic, although JMS is worth noting as an available choice.



7/31/2006VERSION 0.9

2.3.4 WS-ReliableMessaging

As opposed to JMS, WS-ReliableMessaging offers the same features of JMS, asynchronous messaging and message reliability without locking the solution into a specific technology. WS-ReliableMessaging allows both parties to have different messaging infrastructures and provides MOM features. Use this Web Service specification as much as possible when MOM features are needed. If security needs to be implemented using this specification, consider using other Web Service specifications like WS-Security and WS security related standards.

2.4 USE A WEB SERVICES GATEWAY

A Web Services Gateway should be seen as some kind of service broker and router. It is a runtime component that provides configurable mappings between service providers and requestors. These mappings are based on WSDL documents, which are usually deployed at the firewall and have access to internal services. The services defined on the WSDL document can be mapped internally into different transport channels. These act as components that hide all the Web Services implementations from the callers, which is useful when security is a high priority. Try to use Web Services Gateways whenever possible to protect and encapsulate the Web Services inner plumping in your environment. This way, service requestors will never have to know the real implementation of the Web Service.

2.4.1 Process Execution

Web Services Gateways are all about transport channels. Since the gateway is the only entry point for service requests, these arrive from the outside Web services realm through the channel configured in the gateway. The gateway in turn gets the requests and translates it into the real representation of the service. Through the use of filters during this process, the request can be monitored, logged, intercepted, managed in any way and even transformed. Once the filtering process is complete, the gateway uses the correct provider in order to execute the appropriate Web Service. The gateway acts as the real client of the service. The response to the original service requestor flows back to the origin the same way.

2.4.2 Design Considerations

When deploying a Web Services Gateway, make sure to use UDDI to get the interface definition and service description of the service. Avoid storing the WSDL documents on the Web server since they don’t provide any discovery mechanisms and UDDI provides a way to organize and classify services. Consider using the Exposed Broker runtime pattern as a standard way of deploying your Web Services Gateway.



7/31/2006VERSION 0.9

2.4.3 Don’t Forget Security

It is true that a Web Services Gateway provides a way to hide and protect your Web Services. But as a Firewall protects internal network assets and information, networks still leverage internal security initiatives such as data encryption, authentication, and secure communications. The same applies to a Web Services solution. If you are going to use a Web Services Gateway, do not assume that security shouldn’t be a concern. You still must have a security architecture in place for your Web Services environment. For more information, see the Web Services Security Best Practices document.

2.5 MANAGE AND MONITOR YOUR ENVIRONMENT

A Web Services network deployment infrastructure wouldn’t be complete without mentioning a few things about management and monitoring. Once you have UDDI, Web Services Gateways, transport and application protocols in place, security, etc. you need to manage, monitor, and take control over your environment. Since Web Services are about platform independence, and the underlying technology is not important, it wouldn’t make much sense to start using platform specific products to manage and monitor a Web Services environment. This is why Web Services Distributed Management (WSDM) and WS-Manageability exist. They evaluate the wellness of your Web Services infrastructure. Other options available for management are JMX and Windows Management Instrumentation (WMI). However, since these are platform-specific, it is highly recommended you adopt WSDM for Web Services Management since it’s the standard that is gaining more traction by the IT industry.

Once you implement your management solution, make sure you draw the line between management concerns and business concerns and that you have a dashboard located at a central operational site where you can monitor the Web Services environment. At press time, the biggest players in the WSDM arena are: CA, HP, IBM and Amberpoint.

For more details about management and its role in your network and platform infrastructure deployment, see the Platform Infrastructure Best Practices document.

2.6 DO THE GRID

Grid Computing enables throughput computing by connecting theoretically unlimited networked nodes and makes them work in a virtual computer architecture, distributing process execution across a parallel infrastructure. As of now, grids are the ultimate scalability and flexibility solution allowing huge computational processes to be distributed across the network.

It is not necessary to deploy a grid on your first Web Service initiatives, but when you design and architect your infrastructure, keep in mind that eventually you will go grid. Since Web Services are loosely coupled, it makes sense to think about them deployed in a grid environment. Grid Computing technology has been re-factored and re-architected to reflect the use of WSDL to implement the concept of a WS-Resource Framework which addresses the stateless nature of the Web in a grid environment.



7/31/2006VERSION 0.9

Web Services working on a Grid Computing environment are called Grid Services. The environment defined to support Grid Services is specified in the Open Grid Services Architecture (OGSA) developed within the Global Grid Forum (GGF) and one of the implementations belongs to The Globus Alliance. OGSA leverages Web Services related specifications like WSDL and SOAP although it’s agnostic to the transport level handling of the data.

As mentioned, the Globus Alliance provides an open source implementation of OGSA on The Globus Toolkit 4.0. Although this implementation is still on preview releases, pay close attention to its progress and start getting familiar with the technology.

For more information about OGSA go to the OGSA’s The Globus Alliance website at http://www.globus.org/ogsa

Grid Computing concepts are explained in more detail in the Platform Infrastructure Best Practices document.


http://www.globus.org/ogsa

Documents

Web Services Network Infrastructure Best Practices