Mindreef

Mindreef Shared Workspaces 

Mindreef SOAPscope Server provides a repository of Mindreef Shared Workspaces^TM. In this way, the Mindreef Shared Workspace becomes the base unit of all collaboration between the varied tools within SOAPscope Server. The Mindreef Shared Workspace contains all the information needed to reproduce a Web services scenario.

WSDL and schema contracts captured in their entirety: When SOAPscope Server collects a WSDL contract into a shared workspace it follows all the import statements to make sure all WSDL and schema files are brought in. This eliminates 'moving parts' when scenarios must be reproduced.

All the messages needed to reproduce a scenario: Messages can be created through SOAPscope Server's invoke and tests, or collected through remotely using Mindreef’s remote collector technology.

Playback: Message playback within a shared workspace can handle the most robust regression testing. Yet the easy-to-use point and click technology allows any user to create a reproducible script, allowing the scenario to be reproduced at the push of a play button. This includes threading variables from a response to a request.

Simulation: Service-oriented architectures have many moving parts at different levels of development. Simulation allows a scenario to be reproduced even when some of the services are not available.

Notes: Workspace notes allow better communication as workspaces are shared.

Applying the Mindreef Support Solution

Supporting a Web service’s clients can be challenging because there isn’t a good way to capture a description of a problem. Clients and services are loosely-coupled and are often written in different languages using different Web service toolkits. That makes it hard for a client developer to build a reproducible test case for a problem that has any meaning for a service support engineer or developer. Instead, the client developer typically sends some XML fragments representing portions of request and response messages via email. Mindreef SOAPscope Server provides a powerful alternative in the shared workspace, which can act as a “reproducible problem” that helps service support engineers close issues more quickly.

If the Web service has a copy of Mindreef SOAPscope, he can build a workspace that contains messages that demonstrate a problem. If he has access to a SOAPscope Server server, he can build a workspace that contains messages and a set of actions that can be replayed to dynamically recreate the problem. In either case, he can send the workspace becomes a reproducible problem that can be sent to the service’s support team.

When a service support engineer receives a workspace containing a reproducible problem, he has everything he needs: a copy of the contract the client is using and a set of messages that demonstrate the issue. If the workspace was created with SOAPscope Server, it may also contain a set of replayable actions. If the workspace was created with SOAPscope, the support engineer can quickly convert the recorded messages to actions.

With the actions in place, the support engineer retargets the actions’ endpoint to a test server and verifies that the service is not behaving correctly. He adds any relevant notes to the workspace, and then creates an issue in the team’s issue tracking system. The issue includes a link to the workspace in the service team’s Mindreef SOAPscope Server server and the bug is assigned to a developer.

The developer who receives the bug opens the referenced workspace. She uses the re-playable actions to reproduce the client’s problem. She plays them back against her development box. With breakpoints set in the service code, it’s easy for her to pinpoint the problem and fix it. She submits the fix to source control; it will be picked up by the build process and deployed as an update to the service.

The tester responsible for vetting the new service build uses the same reproducible problem workspace to verify that the bug has indeed been fixed. He adds the workspace to the library of workspaces he maintains to regression test the service as part of the nightly build. When the service fix is verified, he notifies the support engineer that the bug has been fixed.

Once the updated service is deployed, the support engineer notifies the client that the service has been fixed. He also passes the workspace to the service architect to help her gain insight into the problem and how she might want to rework the service to avoid similar issues in the future. By closing the loop this way, feedback from service clients can provide input to the executable specifications for the next generation of the service.

 Creating Exectutable Specs for Web Services

Web services architects create WSDL contracts as part of the design process. The contract is core to both service and client development efforts. Unfortunately, a WSDL contract alone does not convey any information about the dynamic behavior of a service – the order in which operations must be invoked, the different ways a given operation can be used, etc. This information is typically captured in prose form, usually in a written specification. For teams using Mindreef SOAPscope Server, this information can also be captured in shared workspaces as a series of recorded actions and simulated reactions that demonstrate aspects of the dynamic behavior of a service. The workspaces act as “executable specifications” that show how a service is used. They help the architect verify that a service fulfils its requirements.

Once an architect has created a set of executable specifications, she can share the workspaces with the service developers. They can use the service contract to generate skeleton code for the implementation. The executable specifications in the architect’s workspaces help the developers understand what the service is supposed to do. By remapping the action endpoint to point to their service implementation instead of the workspace’s simulation, they can verify that their service implements the behavior the architect requires. This process can be automated as part of a nightly build using SOAPscope Server’s Web service-based Integration API.

Executable specifications are also useful to testers, who can use them to verify the correctness of a service implementation. They can incorporate the workspaces into their regression tests. They can also make additional copies of the workspaces to create a variety of test cases. Support can use an architect’s workspaces to help understand issues reported by clients once a service is in production. The executable specifications serve as a comparison to client use cases, and can be used as samples that show clients what the expected behavior is.

In short, when an architect uses workspaces to capture executable specifications for a service’s behavior, she is creating an artifact that can be leveraged by other team members to help ensure that a service behaves the way she intended. At every step in the service lifecycle, development, test and support engineers can exercise a service to see if it provides the desired behavior.