Dependency Abstractions - Abstraction is the key to SODA (along with self-description and discovery): abstraction of services implementations, abstraction of concrete data typing, and abstraction of activities such as the plumbing behind user interface and business services development.

Refocusing the Division of Labor - A SODA approach provides enough automation, implementation abstraction, and simulation support to allow for a more logical, vertical division of labor. Each team can take on a full vertical slice of related functionality and not be consistently dependent upon another team (who may be taking a different approach), as is the case with the current horizontal division.

Enabling Business Process Design - SODA allows the designer to develop both the presentation and business services functionality graphically, concentrating on the process flow, from Web page to back-end integration interaction. Services can be graphically configured out of the box, as can data transformation. The SODA tools behind the scenes automatically generate implementations of enterprise architecture and J2EE design patterns.

Service Publication and Discovery - SODA tools usually provide (or interact with) a Universal Description, Discovery, and Integration (UDDI) server (or other similar registry), thereby allowing the easy publication of services and their associated metadata to a centralized registry. Conversely, these tools provide for the discovery of services previously published to the registry. This allows a designer to discover and reuse a service with a couple of clicks of the mouse. If the service isn't available and the designer needs to configure one, he or she can then publish that service for others to reuse. The J2EE and Integration experts, who might need to build a service from scratch or extend an existing one, will also use the SODA tools to do this, providing them the same accessibility to the UDDI registry. EJBs and POJOs can be constructed using the chosen IDE and the resulting JARs imported into the SODA tools. This process can be glued together using Apache's Ant (http://ant.apache.org/).

Leveraging Diverse Skill Sets/Varying Levels of Expertise - SODA allows developers of all backgrounds who have an understanding of the business domain and use cases to quickly be productive in orchestrating use case process flows and formulating the data content and transformations that take place as the flow progresses. Presentation experts will perform orchestration of presentation flows. Integration/EAI experts can, in parallel, configure the services and data transformations that are required to wire together process flows between systems and businesses. J2EE gurus can work on custom implementations of discrete pieces of functionality where this is not provided with an out-of-the-box service. They can use the SODA tools to expose these implementations as services and then publish them for others to discover.

Integrating SODA
Process
Transitioning the development team to a SODA approach will require not only a process change but a cultural one as well. The key changes required are described in the following subsections, but the overriding emphasis in each case must be: 1.  A re-thinking of the way in which the domain, business, use case, and presentation components are realized (designed and implemented). In traditional processes, there often is no distinction between business services and use case services, while presentation services are not really thought of as services at all. In order to achieve domain independence (domain pluggability) while at the same time achieving business independence, the use case/business services distinction must exist. In addition, the components that make up both the Web page presentation as well as the page navigation are considered to be first class services in the SODA world: the orchestration of page navigation is really no different (mechanically) than the orchestration of business process flow. The orchestration and assembly of domain, business, use case, and presentation service layers is one of recursive composition:

• A presentation service is realized by the orchestration of action services within a page flow, their interaction with use case services, and finally, passing off control to one or more view services for rendering on the page.
• A use case service is realized by the orchestration of other use case services, as well as lower-level business and domain services.
• A business service is realized by the orchestration of other business services, as well as lower-level domain aervices (across more than one domain).
• A domain service is realized by the orchestration of other domain services (provided they are in the same domain).

J2EE/Integration Component Design - Development staff whose J2EE and integration technology skill sets and experience outweigh their knowledge of the business and business modeling should be assigned to build out and/or extend lower-level components upon which all other services are built.

Domain Service Design - There will need to be a strong emphasis on domain service design (that is, services that interact with the domain model in a use-case independent manner). It is important that the domain services be narrowly scoped, cohesive, and discrete. The set of services tied to a particular domain should allow that domain to be used independently of other domains.

Business Service Design - In the cases where services are desired that are use case-independent and yet require interaction with lower-level services across domains, a separate layer of services should be realized. This layer should be distinct and separate from the individual domain services, yet it should not be melded into the use case services tier. Business services, for the purposes of this document, are services that span individual domains while remaining independent and reusable across use-case realizations. Use case services, meanwhile, are application specific, and are not meant to be reused across systems. The relationship between use case services and business services is analogous to the relationship between the application service pattern (www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm) and the session facade (www.corej2eepatterns.com/Patterns2ndEd/SessionFacade.htm).

• Figure 1
• Figure 2