Web Services are rapidly emerging as important building blocks for business integration. They are finding important applications in business-to-business, business-to-consumer and enterprise application integration solutions. As such, Web Services are critical to business architecture, and their reliable execution must be assured. Reliability must be a first-rank consideration for organizations deploying such solutions. The management of computer systems and applications is a discipline that is well developed and extensive. It has recently evolved to encompass Web Services.

The Web Services market provides many choices for developers requiring a service management system. While the features of these systems vary, each requires developers to create manageable services. In this article we will show how Web Services developers can incorporate manageability in their applications. We will first briefly survey the parts of instrumentation that are relevant to our discussion. Then we will detail service management principles and patterns.

Instrumentation Requirements:
Management systems usually collect information from Web Services. To collect this information, the management system uses an agent-manager model. The agent-manager model might deserve its own article, but for our purposes, here's the agent-manager model of the WSM in a nutshell: A manager is an application with the Web Service Management that communicates with management agents via management protocols. An agent is an application installed in the managed resources. A management protocol is the two-way communication channel between the manager and the management agent."

The table on following page illustrates the information categories and the details.

Web Services Management Principles
Web Services-based applications will have characteristics over the traditional application that make management a little more challenging as follows:

• Web Services are described with XML and are accessible using standard interoperable protocols and transports. Therefore, applications based on Web Services will be able to use services that execute in many diverse environments - systems, languages, platforms and enterprises.
• Web Services-based applications will cross enterprise boundaries more now than applications used to. As a result, it must be possible to interact with the management aspects of these applications across enterprise boundaries, preferably using the same communications pipes and technologies already agreed on among the companies.
• Web Services define a standard mechanism for publishing, finding and interacting with their Web Services. Management systems have traditionally defined such a mechanism, both standards-based and proprietary, for publishing, finding and interacting with manageable resources. Management systems that support Web Services should interact with the Web Services publication and discovery practice.
• Web Services have a natural loose coupling that means a service should be able to "find" its management services - using the Web Services paradigm - at runtime rather than having them statically bound or internalized during development. As a result, the Web Services, as well as the management services, are more portable to different execution environments.

Thus, when considering the nature and usage models of Web Services and the challenges of managing them, several specific management principles emerge. We will summarize them here, and then treat each in detail with some illustrative example.

• Separate management interface principle means to define the business interface separately from the administration or management interface.
• Use of architecture pattern principle means architectural patterns that define components that make up the solution and the relationship between the Web Services and the management system.

There are several reasons for this, as we now describe.

• The search for a Web Service usually involves looking for a standard or mutually agreed-to interface. Mixing management operations with those that are formally part of the business interface will interfere with the search for the service based on interface contents by changing the signature of the interface.
• It will allow business partners to see and use management interfaces that are irrelevant to their interactions with the Web Service. Likewise, it will clutter management consoles with business operations when it should only display management operations.
• Providing a separate service and port in the WSDL document for the management interface enables more targeted publishing of business and management service ports in the WSDL. The service in the WSDL document for the management interface of a Web Service doesn't have to be published in a public UDDI registry along with the business interface described in the business service port, since only management applications will be interested in them. If it is published in a public UDDI registry, the service in the WSDL must be categorized as "management" so the management system can find it. The management interface will most likely be published in a private UDDI registry that caters to management systems as a client rather than business systems as a client.

An example of a generic, overly simplified management interface that could be implemented by any manageable Web service is shown below.

public interface ManageableService
{
    public String getServiceID();
       // return an ID string for
          the managed service
    public String[ ][ ] getMetrics();
       // return an array of metric
       names and a corresponding array
       of values
    public String[ ][ ]
        getConfiguration();
       // return an array of config
           property names and a
           corresponding array of values

    public String getAdminInterface();
       // return the WSDL document
       that describes this interface
    public Boolean isAvailable();
       // return true if service is
       responding, false if the service
       is experiencing delays
}

There might also be a custom manageable service WSDL interface that contains the interactions for the specific administrative or management operations of a Web Service. An example of operations in this kind of WSDL would be "TraceOn()".

The following WSDL illustrates a generic management interface.

<wsdl:message name_''
      GetServiceIdOutput''>
<part name_''value'' type_''
      xsd:float'' />
</wsdl:message>
<wsdl:message name_''GetMetricsOutput''>
     <part name_''name'' type_''xsd: string'' />
       <part name_''type'' type_''xsd: string'' />
     <part name_''value'' type_''xsd: string'' />
</wsdl:message>
<wsdl:message name_''GetConfiguration
       Output''>
       <part name_''name'' type_''xsd: string'' />
          <part name_''type'' type_''xsd:string'' />
           <part name_''value'' type_''xsd:string'' />
</wsdl:message>
<wsdl:message name_''GetAdmin InterfaceOutput''>
           <part name_''AdminInterface
       WSDLurn'' type_''xsd:string'' />
</wsdl:message>
<wsdl:message name_''GetAvailability Output''>
           <part name_''value'' type_''xsd:integer'' />
</wsdl:message>

<wsdl:portType name_''Generic
       ManagementInterface''>
           <wsdl:operation name_''
       GetServiceId''>
                    <wsdl:output 
       message_''tns:GetServiceId
       Output'' />
           </wsdl:operation>
           <wsdl:operation name_''
      GetMetrics''>
             <wsdl:output message_''
       tns:GetMetricsOutput'' />
           </wsdl:operation>
           <wsdl:operation name_''
       GetConfiguration''>
             <wsdl:output message_''
      tns:GetConfigurationOutput'' />
           </wsdl:operation>
           <wsdl:operation name_''
       GetAdminInterface''>
            <wsdl:output message_''tns:
      GetAdminInterfaceOutput'' />
           </wsdl:operation>
           <wsdl:operation name_
       ''IsAvailable''>
           <wsdl:output message_''tns:
       IsAvailableOutput'' />
           </wsdl:operation>
</wsdl:portType>

This WSDL illustrates the custom management interface:

<wsdl:message name_''Change AvailabilityInput''>
        <part name_''action'' type_''xsd:string'' />
</wsdl:message>
<wsdl:message name_''Change AvailabilityOutput''>
        <part name_''newState'' type_''xsd:string'' />
</wsdl:message>
<wsdl:message name_''setTraceInput''>
        <part name_''action'' type_''xsd:string'' />
</wsdl:message>
<wsdl:message name_''changeStockExchange''>
        <part name_'' exchangeName'' type_''xsd: string'' />
</wsdl:message>

<wsdl:portType name_''StockQuote
       ManagementInterface''>
         <wsdl:operation name_''setTrace''>
            <wsdl:input message_''tns:setTraceInput'' />
         </wsdl:operation>
         <wsdl:operation name_'' changeStockExchange''>
            <wsdl:input message_''tns:
       changeStockExchangeInput'' />
         </wsdl:operation>
         <wsdl:operation name_'' changeAvailability''>
             <wsdl:input message_''tns:
       ChangeAvailabilityInput'' />
              <wsdl:output message_''tns:ChangeAvailabilityOutput''
       />
          </wsdl:operation>
</wsdl:portType>

Architectural Patterns
There is a set of patterns that provides sufficient guidance to simplify the development of manageable Web Services. Developers can choose the pattern that applies to their Web Services behavior and requirements. These management patterns are architectural patterns that define components that make up the solution and the relationship between the Web Services and the management system. They show the placement of function and the flow of information.

There are four patterns and the diagram in Figure 1 illustrates the different WSM architecture patterns. These are the Architecture patterns with their definitions, when and how to use them:

1. Event Generator Pattern (EGP)
This pattern offers a very simple approach to instrumentation. By using an event collector, the Web Service can be completely isolated from the details of the management system under which it operates.

A convenient approach to implementing this interaction is to create an event collector Web Service that exposes a simple interface for receiving events. The Web Services call on the event collector interface causes the events to be forwarded to the management systems that have registered for them.

The event collector interface can be quite general and simple. Minimally, it must include a method that allows it to receive the management event. For example:

Public interface EventCollector {
  Public void deliverEvent (string id,
     String source, String severity,
     String text);
}

This interface should identify the Web Service, specify the cause of the event, indicate the severity of the condition and provide additional information in the form of unformatted text. When the Web Service initializes, it can dynamically discover a Web Service that implements this interface as described by a published WSDL document. Alternatively, the Web Services developer can statically bind the Web Service to the event collector. The event types are application-defined and are not constrained by the event collector. If an event collector supported delivering events to interested management services via Web Services, it could also provide a WSDL-described port that other Web Services could use to ask the event collector to invoke their "receive event" operation based on certain conditions or contents of event.

When do you use this pattern?
This pattern is applicable to Web Services whose:

• Processing contains events and metrics of interest that are not already collected by the Web Services execution environment.
• The service doesn't require runtime operations or dynamic configuration control.

• The Web Service doesn't publish a management object.
• The Web Service doesn't support being invoked for operations or reconfiguration by the management system.
• The Web Service neither implements facilities to listen for or respond to management requests nor implements the generic manageable service port.
• The Web Service doesn't have a custom management port.

<wsdl:message name: "Event">
      <part name="id" type="xsd:string" />
           <part name="source" type="xsd:string" />
           <part name="severity" type="xsd:string" />
           <part name="text" type="xsd:string" />
</wsdl:message>
<wsdl:message name="requestEventInput">
         <part name="idpattern" type="xsd:string" />
           <part name="sourcepattern" type="xsd:string" />
           <part name="severityrange" type="xsd:string" />
           <part name="textpattern" type="xsd:string" />
           <part name="receiverWSDLPort" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="EventCollectorInterface">
       <wsdl:operation name="deliverEvent">
          <wsdl:input message="tns: Event" />
       </wsdl:operation>
</wsd:portType>
<wsdl:portType name= EventRequestorInterface">
       <wsdl:operation name="requestEvents">
             <wsdl:input message="tns: RequestEventsInput" />
               <wsdl:output message="tns:RequestEventsOutput" />
       </wsdl:operation>
       <wsdl:operation name="deliverEvent">
               <wsdl:output message="tns:Event">
       </wsdl:operation >
</wsdl:portType>

2. Non-Interruptible pattern (NIP)
The Web Service contains instrumentation and sends events and publishes management information to a management presence. Unlike the Event Generation Pattern, the Web Service makes a standard object available to the management system that contains the identity and metric information as well as details of the current configuration. Notifications of changes to the management object can be sent via events specified for that purpose or by resending the updated management object to the management system.

The management object could be any of several types. For Web Services being monitored by a JMX management environment, the object could be an MBean. Some management systems also support the Common Information Model (CIM) so the web service could alternatively create a CIM object to fill this role. It could also create a custom object, but such an approach may require some kind of bridge code to make the object understandable to the management system. MBeans or CIM objects are more workable choices.

When do you use this pattern?
This pattern is useful over the event generator pattern when:

• There are great amounts of potentially complex management data that may be frequently updated.
• When the management is not real-time sending the entire management object periodically rather than every time a value is updated tends to be more efficient
• It also allows a set of changes to be sent so they are consistent with one another rather than sending a set of events, some of which may not arrive in order or at all, leaving the management system's version of the management object in an invalid or inconsistent state.
• A particular management system requires the data in a particular format. The receiver of this information gets data already in context of the management object it understands
• Web Service doesn't support being invoked for operations or reconfiguration by the management system

• The Web Service doesn't have to implement any facilities to listen for and respond to management requests or implement the generic manageable service port
• The Web Service doesn't have a custom management port.

3. QueryAble Pattern (QAP)
The QueryAble Pattern is related to the Event Generation Pattern in that the Web Service doesn't require configuration or operational control but, in this case, the service may send events and implement a management interface that can be called by the management system. The management system can retrieve configuration and metric data directly from the managed services. This is essentially read-only management. The managed Web Service supports being invoked by the management system to obtain current metric and configuration data, but not being controlled or altered.

When do you use this pattern?
This pattern is applicable to Web Services with a high rate of change in metric values or large numbers of complex metrics so that sending events to signal changes represents too much overhead. [Simplify your sentences where possible.]

How does it work?
The Web Service can support a management object and supports being invoked for query operations by the management system. The management data may be represented as complex data types and objects. Management systems would typically retrieve the management data when they need it or poll for entire sets of related management data rather than one or two metrics. In this pattern:

• The Web Service implements facilities to listen for and respond to management requests
• The Web Service may implement the generic manageable service port
• The Web Service may have a custom management port

4. Operational Pattern (OPP)
In this pattern, the management system can retrieve configuration and metric data and obtain events from managed service and can set configuration data thus changing the application's operation. It can also invoke operations on the managed Web Service.

When do you use this pattern?
This pattern is applicable to Web Services with reconfiguration requirements and can be done through the management systems.

How does it work?
The Web Service must implement methods that can be called by the management system and must have a structure designed to allow for configuration changes. In this pattern:

• The Web Service can support a management object and supports being invoked for operations or reconfiguration by the management system.
• The Web Service can implement facilities to listen for and respond to management requests
• The Web Service can implement the generic manageable service port.
• The Web Service can have a custom management port.

Summary
Web Service developers need to balance management requirements and complexity implications. They would be advised to separate the management interface from the business interface and push the core metric collection down to the Web Services management system. The Patterns discussed here give increasing amounts of information and control over the Web Service to the management system. Any of the patterns may send events directly to the management system or through an event collector.

The QueryAble Pattern and Operational Pattern will usually use a management object as well. These two patterns must support two-way communications. They must both implement a way for the management system to initiate communications with the Web Service. Only the operational pattern allows the management system to control the Web Service. Both Event Generation Pattern and Non-Interruptible Pattern use send-only communications and don't implement any way for the management system to initiate communications with the Web Service. Events are generally more generic and easily translated to be understood by any management application; therefore, the Event Generation Pattern is more portable than the others.