Web Services Example of Reuse via Extension
Let's consider a use-case where a SOA service with a Web Service interface valuates an investment fund in a hypothetical company called Enterprise. Sometimes valuation is needed for fund processing but, in the future, it could be the final action in a business process and the valuation would have to be stored in a database.

The business client has indicated that not all requirements for the valuation are formulated yet but the valuation operation has to be available to end users as soon as possible. The development team recognizes that the valuation would be reused in multiple business scenarios over time, and some of them aren't known yet. If the number of actions associated with the valuation grows and each action to be represented as a service function, there is little chance for traditional service reuse. However, if the new service functions are defined as extensions of the same core operation, we can achieve service reusability with reuse via extension.

Service Interface Definition
The development team creates a Web Services interface for the Valuation Service (see Listings 1 and 2) and defines only one operation - valuateFund(). It's important to notice that the operation name reflects the valuation action for the funds, not for bonds or anything else. This is how an operation type can be specified for service reuse via extension. The operation is associated with request, response, and failure messages and with corresponding message XML Schemas.

The design goal of the interface is to loosely couple message XML Schemas with the interface operation. As Listing 2 shows, each message has its own schema and namespace defined in different files.

Basic Message Definition
With reuse via extension, a Web Service uses the same port (end point) and port type. The port type always contains the same operation with the same basic in/out/failure messages.

The basic "in" message defines the request for fund valuation. The basic "out" message defines the response, i.e., fund valuation. Since the service anticipates potential failures in service resources and connectivity, the interface defines one failure message - serviceResourceUnavailable.

In the Listings 3, 4 and 5 we find XML Schemas for the request message, the response and the failure message. The business action of fund valuation is represented by the element "valuate." It contains three sub-elements that detail the action by specifying a fund name and fund and requester identifiers.

Basic Message Extension
The development team has decided to implement all additional business actions - new functions - in a consistent reuse via extension manner. So, the business action "store" valuation has to be implemented as an extension of the basic message XML Schema. The extension of the schema is imported as a new namespace that defines composite business action - "store."

Let's discuss the implementation specifics shown in Listings 6 and 7. First, all elements related to the business actions are listed in the construct and all of them are optional. This means a service consumer isn't obliged to specify any one of them if it's not needed. The basic response message reserves "emptyRequest" element for such case.

Second, all of the schemas have been designed to expose the namespaces in instance documents (as directed by <elementFormDefault> with value "qualified"). This points to the fact that all related XML documents deal with different namespaces. The service consumer can choose whether to use a particular namespace or skip related elements. That is, the service consumer chooses to use the extension of the service or not with no harm to the existing code. Finally, any element related to a new business action can be added to the <all> independently of the others. For example, a service consumer can specify only the action "store" without the action "valuate" or both in any order. This is possible because the service maintains its internal state. The service is stateless as far as the consumer's invocations go (no state is saved between consecutive calls to the valuateFund() operation) but the results of each business action are cached in the service until the response message is formed and returned. The Service Description states that all business actions in one invocation are performed for the same valuation. In the hidden service implementation, execution of any action checks if the valuation was done already and reuses it in the composed action.

As a result of such a design, a service consumer can choose to work with any available extensions when the consumer needs to and isn't forced by the service provider to update to a new version of the service. Thus the organization can schedule and gracefully manage a transition onto new service functionality for all existing consumers in accordance with service governance policies.

Further Message Extension
At the moment the service was released into production, the business client specified a new requirement: when the valuation stores, certain business consumers and other services have to be notified about this event. Also some business consumers interested in the notification may not be necessary among existing consumers of the Valuation Service.

The development team has decided to implement the new requirement by sending notification messages using message-oriented middleware (MOM). As they agreed before, any new solution has to minimally affect existing service consumers.

Following the reuse via extension concept, the request message schema has to include new business notification action represented by the new element "notify" (see Listing 8). In the definition of "notify" (see Listing 9), the "addresseeID" stands for an identifier of the addressee to be notified. If it's not specified (minOccurs="0"), the notification is restricted, if its value is NULL, the notification may go to everybody as a broadcast, otherwise the notification has to go to a specified unlimited list of addressees as a multicast.

Obviously, the notification may fail while valuation succeeds. Thus the service interface has to include an additional failure message related to MOM or the existing failure message may be extended as shown in Listings 10 and 11. So FundValuationException can contain either a serviceResourceUnavailable or valuationNotificationFailure alert.

To summarize the case, we can see that the development team has implemented two new business features for the fund valuation service - "store" and "notify" - without changing the service interface. It was done by importing additional namespaces into the request message schema and changing the failure messages schema. Service consumers who need only a few features can ignore unrelated schema extensions since they're optional and don't interfere with the basic schema/namespace.