Enterprise SOA Developer Scenario

Overview

This scenario concerns an Enterprise SOA developer who works in a team. The team members work on a number of services, but not every developer has detailed knowledge of every other service that is being developed. The goal of the team is to ultimately deliver all the pieces of the SOA that work seamlessly together.

Assumptions

• The SOA consists of many Services, possibly written in various programming languages.
• Client applications to the services are also developed, but possibly not in the same language as the service, so e.g. a client could be written in Java which will interact with a service written using BPEL.
• The team work in a WSDL-centric way.
• Certain services might even have multiple implementations in multiple languages.
• The team is using the Eclipse Team API for access to its SCM.

Usage patterns

The developer will use STP in the following ways:

• He needs full roundtrip support to be able to do developing, deployment and testing.
• He also needs debug support, so that he can set a breakpoint in his Service code and it will break while running inside his favourite ESB runtime.
• He needs refactoring support on the WSDL level. E.g. in a meeting it has been decided to rename an operation defined in the WSDL. He would like to use the Eclipse refactoring mechanism to do the rename and let the renaming support fix all the implementations and clients that depend on this WSDL too. This should work for all programming languages used in the project.
• The final product of the team is handed over to the deployment team as deployable archives. So in addition to being able to directly deploy to an ESB, the tools should be able to produce these archives which are self-contained and can be deployed as-is by the deployment team.
• The developer would like to see an overview picture of the SOA that his team is working on. This will give him an idea of all the entities that exist in the SOA, and allows him to zero-in on his personal work by opening the project(s) that relate to the services he works on. He should at least be able to see and work with the WSDLs of the services he's not actively working on.
• Because he leverages the Team API for SCM integration, he expects STP to fully interoperate with it. He would be even more happy if some of the team tasks could be automated for him. E.g. he selects a Service on the overview picture that he has not yet worked on, so he does not have this code yet on his local machine. Now he wants to start working on it. It would be nice if STP could automatically at this point provide a mechanism to check out the service from the appropriate SCM repository. This way he can easily access the code of any service developed by the team that he's part of.