By nature Web Services is a distributed technology. With distribution comes great flexibility for architectural topologies. Components can be strategically placed in different physical locations to optimize performance, maintenance and business processes. In large organizations one physical location may handle sales services, while another delivers contract management. As organizations build Service Oriented Architectures that stitch together these physically dispersed services, distributed development becomes an interesting challenge to overcome. Many collaborative technologies exist today to facilitate better communications and information sharing among workers, but it's rare to find a distributed development environment.

Enter Mindreef SOAPscope Server. SOAPscope Server is a development platform that provides a centralized work environment designed specifically for SOAs enabled by Web Services. Development teams collaborate in specialized virtual workspaces that manage Web Services definitions, messages, recorded actions, simulations, and notes.

The Development Environment: Creating Workspaces
Mindreef SOAPscope Server is based on the concept of workspaces. As mentioned, workspaces are central repositories that contain the assets of a given Web Services-enabled project. There are three kinds of workspaces:

1. Private - All assets in private workspaces are accessible only to the logged-in user
2. Team - Assets in team workspaces are accessible to any logged-in user
3. Community - Community workspace assets are available to any user in a read-only state, and an editable state to those with accounts on the server

As an example, assume that an organization has separate physical locations for sales, contract management, and master data services (customer, product, etc.). The support teams and developers of these individual services are also located in different physical locations. As part of an effort to improve ties with its trading partners, this company is building an application so buyers can submit price checks and purchase orders using Web Services. During development a workspace will be created in the team area.

When establishing a workspace in Mindreef SOAPscope Server, developers add WSDL definitions referred to as service contracts. As shown in Figure 1, service contracts can be added to a workspace via either a URL or a WSDL file located on the file system. Service contracts can also be added from the developer's other private workspaces, and from all team and community workspaces. For this example, the ContractService and SalesService WSDL files will be added.

With the service contracts loaded, SOAPscope Server presents them to developers in multiple views:

• Overview - Displays the details of a specific service contract as a tree structure. Each operation is an expandable node on the tree in which the operational details are stored including actions and input and output message constructs.
• Documentation - Lists all of the components of the Web Service by namespace.
• Files - Displays the XML files that make up the Web Service definition in a formatted view.
• Coverage - A general listing of usage statistics for a given service. Metrics captured here include total calls, faults, call duration, request size, and response size.

From these views, services can be invoked, analyzed, or updated, and multiple services can be compared to identify differences in their definitions. The developer can also analyze services for best practices. The choices of algorithms to run are Mindreef Basic Diagnostics, WS-I Basic Profile 1.0, and a combination of the WS-I Basic Profile 1.0 and SOAP Binding Profile 1.0. Users have the option of creating their own algorithms from a library of tests.

Testing & Verifying Services
Every time a developer invokes a Web Service from a workspace, the request and response messages are captured and the event is stored as an action. This serves as a powerful mechanism for testing and debugging. When issues with a service are identified, the messages that produce the issue can be stored and re-sent to verify that the appropriate collective actions have been taken.

Individual actions can also be strung together to create scripts. This provides for testing dependent services. Web Service parameters can be configured to extract their values from variables allowing for the results of one service to serve as the input to another. For the example in this article, the ContractService.GetContractPrice has been configured to put its results in variables. The values include contract number and price. Subsequently, the SalesService.SubmitPO operation has been configured to extract the contract number and price from the configured variables completing the chain of operations.

Collaboration
All of the features of Mindreef SOAPscope Server mentioned so far are valuable and serve to assist with developing and testing Web Services. However, SOAPscope Server's differentiating functionality is in its ability for teams to collaborate on Web Service development. Features of the system that facilitate this include:

• Workspace Notes - Notes in a workspace provide a way to document activities, changes, issues, and other useful information to members. For example, if an issue is identified with the ContractService, the action that re-creates the error and the specific inputs that are associated with it may be documented as a note. Members of the maintenance team for the ContractService now have a centralized documentation repository to identify and resolve the issue, a location into which the resolution may be entered, and an action script to re-create and diagnose the issue at hand.
• RSS News Feeds - These feeds provide information about the workspace and the notes entered. RSS feeds always include the first and last note entered in the workspace. So teams that consume services in a workspace may be notified by RSS when changes, updates, or issues are resolved in the workspace.
• SOAPscope Server Integration - SOAPscope Server lets workspaces be exported to a proprietary format called a Mindreef Reproducible Package. These packages can be transferred to any SOAPscope Server server with all assets intact. Packages can also be stored in alternate systems, such as bug tracking tools, for archiving and reference.

Simulation
Simulation in SOAPscope Server refers to the practice of creating dummy messages that serve as placeholders for Web Services. This is particularly useful during the development of composite applications and prototyping where not all services are available. During a simulation, SOAPscope Server acts as a service endpoint, responding with the appropriate message template based on the contents of a request, or throwing a SOAP fault when no matching response is found.

Using the ContractService a new operation has been defined called GetEligibility. This operation will determine which contracts a given customer can buy on, if any. The service itself has yet to be developed, so a simulation will be created for this specific operation.

As shown in Figure 2, the simulation for GetEligibility will be based on the value of the attribute "name" in the incoming XML payload. The response, shown at the bottom of the screen, is a hard-coded XML string that represents a generic eligibility value. Multiple simulations can be created, each configured to react to a specific payload, to accommodate different business cases such as customers being eligible for more than one contract. Invoking the simulation is as simple as sending a request from the service client to the endpoint defined for the simulation.

Summary
Developing Web Services components in a Services Oriented Architecture presents unique challenges. Physical distribution of resources adds to this complexity. Mindreef's SOAPscope Server platform introduces an interesting solution to this challenge by providing a collaborative work environment that goes beyond the traditional communication functions. The system can play a valuable role in organizations building out new services and supporting existing applications. SOAPscope Server is definitely worth a look.