Use Case Service Design - These services realize specific application use case scenarios, by orchestrating other use case services and lower-level business and domain services. Strong understanding of the particular application requirements is required here.

Presentation Service Design - These services orchestrate the page flow and render the resulting information on a Web page. Strong skills in human factors, HTML, and an understanding of an application flow from a page navigation perspective are required here.

Developer Roles - Successful integration of SODA requires that the developer roles are firmly defined, based on evaluated skill sets, and that the tasking truly reflects their role in the process, as described in the immediately preceding subsections.

Division of Labor - The division of labor for the development teams in a SODA environment should be made logically, based on related/dependent groupings of use cases.

Service Publication and Discovery - The use of a UDDI browser to discover and use services will need to be taught, as will the ways in which a service can be published and versioned (automation of this process is, as for most things, preferable).

Configuration Management - The better SODA tools integrate well with an SCC-compliant source control system, so configuration management, from this perspective, will not change fundamentally. The change comes in dealing with published and versioned services. An SOA-based system often looks up and uses services dynamically. The UDDI registry of services, therefore, should be separated by environments (e.g., development, integration, QA, production), much as the runtime system itself is. The development registry should also be synchronized with the source control system.

Integration with existing software - The existing component-based software will live side-by-side with the new SODA-based software in the source control system. The EJB and utility JARs, as well as existing Web applications, can be imported directly into most SODA tools. Most SODA tools also provide command-line equivalents to the functionality provided in the GUI. This is a standard requirement so that the system as a whole (whether developed using SODA techniques or more "traditional" component/object-based development) can be built using tools such as Ant.

Tools/Integrated Service Environment (ISE)
Within SODA, there is a concept called ISE. ISE refers to the tool suite needed to actually implement the concept of SODA and is the logical evolution of current IDEs. SODA is very dependent on the existence of a robust set of tools to handle interface abstraction, publication, discovery, simulation (mock implementations), and data transformation. It is key that the SODA-enabling tool(s) chosen support these important concepts (SODA's key differentiators). These differentiators are described in the subsections below.

Out-of-the-box Services Library - There has to be an extensive library of ready-made services for common enterprise application functionality (for the presentation, business, and integration tiers). These services must also be readily extensible and configurable.

Services Creation - Obviously, you have to be able to create services easily through graphical wizards. Existing or third-party components should be easily exposable as services through the tool.

Services Assembly (orchestration) - Perhaps the most important feature, in terms of developer productivity, is the ability to assemble (orchestrate) services into business process flows in a graphical, intuitive environment. This must include presentation (page/action navigation) as well as business services flows. Declarative exception, security, and transaction demarcation are also required here.

Services Repositories (tied into source control) - A centralized services repository, that uses a standard such as UDDI, is required. The capability, through the tool, to tie this repository to the project source control system is also desired, although this can be accomplished through an external tool, such as Ant.

Lookup and Dynamic Discovery - The services repository must provide for service browsing, lookup, and dynamic runtime discovery. Use of a UDDI server as the repository generally provides such features.

External Interface Specification (WSDL or other XML Schema) - Services in a SODA environment are generally exposed as SOAP-based Web services, with this feature being an inherent part of that standard. The tool should provide this same capability for services that are not exposed as Web services.

Service Translation (versioning compensation) - The ability to dynamically detect the version of a particular service versus the version of the client of that service and to provide data transformation between the two, if necessary, is desired.

BEA WebLogic Workshop and Other Tools
BEA WebLogic's Workshop (http://dev2dev.bea.com/wlworkshop/index.html) ISE is probably the most complete in terms of enabling SODA within a J2EE environment. It provides support for the key differentiators and allows for a separation of concerns between the interfaces, orchestration of those interfaces, and the underlying implementation. There are certainly many other tools in this space. Some, like Collexa's Web services orchestration product, are complimentary and integrate well into Workshop. Others directly compete. Workshop does have some potential negatives: enabling many of the features currently ties you to the BEA WebLogic platform. Many features have been submitted and accepted by the Java Community Process as Java Specification Requests. With the Beehive initiative well underway in the Apache incubator, along with the associated Eclipse plug-in, Pollinate, vendor lock-in should disappear here. The article "Bridging the Gap: BEA WebLogic Integration" (http://dev2dev.bea.com/pub/a/2004/05/Viarengo.html) details WebLogic Workshop in the context of SODA.