SOA

Proof of Concept (POC)
SODA can provide potential for significant productivity enhancement; however, it is not without its downsides:

• The lack of current standards for tool support dictates a degree of vendor lock-in.
• SODA places much of the development burden on tools. This implies that the tool is adept at the generation of lower-level plumbing code that is either completely hidden from the developer or, if available for customization, can be easily maintained.
• Is the resulting architecture scalable and per formant? Is it extensible?
• There needs to be significant effort given to training the development staff on the SODA tool(s) chosen. The shift in the process by which one develops software is not insignificant.

A POC is required to demonstrate/prove a SODA approach. This POC must be extensive enough to demonstrate/prove at least the following concepts:

• Services-based design paradigm shift. We especially need to dig into the various service layers (realize/utilize at least one domain, business, use case, and presentation service).
• Multi-team development. This includes source control integration and the assignment of specific roles related to SODA (presentation designer, use case designer, business/domain designer, J2EE expert, integration expert, etc.).
• A use case scenario realization that implements a full vertical slice. It is important that this use case scenario touches on all tiers, including (perhaps especially) the integration tier.
• Demonstration of the assembly and orchestration of the following service types:
  - Presentation and presentation flow
  - Basic Web services
  - Business process (workflow)
  - Messaging
  - Back-end integration (EAI)
  - Security
  
• Integration with lower-level J2EE components
• Integration with existing functionality
• Demonstration of the publication, and subsequent look-up/discovery of services and associated metadata (documentation)
• Demonstration of a development, build, deploy, test, and release cycle
• Demonstration of service simulations, to show alleviation of dependency bottlenecks

Service-Oriented Architecture and Domain Pluggability
This section discusses the extent to which an SOA can help better enable business domain pluggability. Pluggability, as defined here, is the capability to swap out one domain implementation (business services and associated domain model) and replace it with another. Pluggability requires that the domain implementation only be exposed through well-defined interfaces (the clients of the domain, including other domains, never know about anything but the interfaces). This can be achieved with a component-based approach; however, there are limitations to this: the clients of the domain are generally bound to particular versions of the component interfaces (at least without jumping through reflection/classloader-related hoops or using some sort of brittle JNDI naming convention).

A domain model, generally, is too fine grained to be directly exposed as a set of services. For this reason, any inter-domain relationships realized within the domain model should be kept to a minimum, in order to achieve pluggability with respect to its clients (the domain services). This obviously implies that inter-domain relationships within the data model are likewise kept to a minimum. The domain model is only exposed to the domain services layer. The business devices (if needed) and use case services layers interact with the domain services. Domain services interact with their applicable domain model and convert the fine-grained, object-oriented interface of the model to a coarse-grained, services-oriented interface. See Figure 3 for a conceptual (example) illustration of how these layers might be defined.

Trade-offs
There are always trade-offs to consider when choosing an architectural approach, and moving to an SOA employing SODA is certainly no different. There are many interpretations of what exactly SOA (the concept of which has been around for a great many years) and SODA really mean. For the purposes of this document, services are defined as coarse-grained interfaces that are often generated by a tool and usually talk XML. These services can be, but are certainly not always, exposed as Web services. The services should be dynamically configurable at both design and runtime, so that a particular service can be reused for many different purposes. The service implementations themselves will be a mixture of custom-built and third party. These services are usually layered and are, for the most part, orchestrated into presentations and business processes. Whenever one talks of XML, layering, and dynamic configuration, performance and scalability concerns enter the conversation. Likewise, SODA's great reliance on tools raises discussions on vendor lock-in. Reliance on particular toolsets also raises questions about software builds, change management, and deployment, and how these tools interoperate with the infrastructure currently in place.

Vendor Lock-in
One of the key value prospects of SODA is how tools will enable presentation and business process orchestration, (nearly) seamless XML/native language data transformations, design/runtime service configuration, registration, discovery, etc. All this is possible without any real all-encompassing SODA standards (there are, of course, piece-part standards such as Web services/SOAP, BPEL/BPML, WS-<fill-in-the-blanks>, etc.). This almost guarantees a certain level of vendor lock-in. The degree of vendor lock-in depends on the tools chosen and the use of those tools.

Performance and Scalability
There is often much concern around the impact to both performance and scalability of an application built on a layered, XML-based SOA. There are questions related to the potential overhead in using something as verbose as XML for intra-application communication and the serialization/deserialization potentially required by both client and service in order to translate the XML to the native language object representation(s). Scalability comes into play as more concurrent users, and larger payloads, interact with the application. Much of this can be mitigated via the judicious design of truly coarse-grained services and the enforcement of communication between well-defined service layers only. Limit long-lived state and ensure that operations are asynchronous where appropriate. SODA tools often help mitigate this concern as well by optimizing the XML transformations (or by natively operating on XML within their presentation and business process flows). In the end, though, there will certainly be more overhead and the early incorporation of application profiling under realistic use patterns must be ingrained into the process going forward to determine where optimization and tuning is required.

Build, Change Management, and Deployment
The tools picked must interoperate with the infrastructure currently in place, or provide the extensibility hooks to easily add this interoperability. Interoperability with the current build (usually Ant) and source control systems, and standard J2EE enterprise application packaged deployment units are all requirements.

Summary
The bottom line is that an SOA, built using the latest SODA-based tools, is certainly not a silver bullet (nothing is). A disciplined SOA approach can help to alleviate dependency bottlenecks somewhat, via data/service abstraction and simulation; however, the dependencies, especially at the domain layer, must still be managed. On the other hand, one of the benefits of an SOA is that the higher-level services can be developed relatively independently, thanks to the service and data abstraction. This allows the presentation and business process orchestrations to be developed independently as well.