The Big Picture
A successful SOA platform is inextricably linked to the business modeling effort it inherits (see Figure 1). Within the Modeling and Analysis tier, Six Sigma process experts and business analysts apply their understanding of the current business process and use hierarchical modeling and a process methodology to map out the "to be process."
Within the Business Modeling tier, business and solution architects collaborate and further refine and expand the complexity of the models.
Within the IT BPM and Service Orchestration tier, the SOA infrastructure, integration interfaces and BPEL instructions and engine(s) are specified. Within advance development organizations, the models implemented can support round tripping with the BPA and can handle frequent process changes.
SOA Implementation Considerations
Orchestration versus Choreography. Orchestration relies on a central process that takes control of the participating Web services and coordinates the execution of different operations with the overall business process. Alternatively, using choreography, each Web service is specified such that it knows about the service with whom it will interact.
On the surface, it appears that orchestration is a more flexible model, however, it really depends on the process design. BPEL supports either approach, executable processes let you specify the exact details of business processes (i.e., orchestration) or abstract business protocols allow specification of the public message exchange between parties only (i.e., choreography).
SOAP versus REST. While a service registry or service bus should support either model, the REST model does not support WS-* standards. For example, the SOAP model is specified to allow for attaching security tokens, such as, Username/Password, SAML token, X.509 certificate and Kerberos tickets to a message header.
Alternatively, REST Web services can still take advantage of the same security models, however, these constructs are not specifically engineered into the protocol. Additionally, some organizations even well established, business partners may only support the REST model or simple HTTPS communication. SOA development organizations need to be prepared to support both models, unless you SOA architecture is completely internally focused.
Pipeline versus HTTP Dispatcher and Command Pattern. Pipelines are well formed, HTTP Dispatcher and Command-like Patterns that route and manipulate messages as they are consumed by a proxy service. At a high level, the service bus processes logic in the HTTP request object, then sends a response back to the calling client. More specifically, nodes are configured to route messages through the message flow, and stages and actions contain rules for processing and transforming messages.
A pipeline is a named sequence of stages representing a non-branching one-way processing path. Pipelines belong to one of the following categories: Request, Response and Error pipelines handle errors for stages and nodes in a message flow as well as service errors.
Quality of Service and Transaction Management. Supporting reliable messaging really is a not so much a function of the transport protocol, but the transaction protocol. When messages are routed to another service from a route node, the default quality of service is exactly once if the proxy service transport is defined as JMS/XA. So, the way to guarantee delivery is to support JMS/XA; otherwise, messages delivery is not consider reliable and messages may be duplicated. While this approach optimizes delivery reliability, performance is degraded. So, design and SLA are important to the protocol decision.
Asynchronous versus Synchronous Behavior. Within a standard service bus the request and response flows in a proxy service execute in different threads. Service callouts are always blocking. Whereas, an HTTP route or publish action is non-blocking for request/response or one-way invocation, if the quality of service is expected to be "best effort." JMS route actions or publish actions are always non-blocking, but the response is lost if the server restarts after the request is sent if the service bus does not have persistent message processing. The point here is that the Web service model supports either transport method. So, again, it really depends on the design and service level expectations.
Message versus System Alerts. Unlike SLA alerts, notifications generated by the message flow in the SOA are primarily intended for business purposes, or to report errors, not for monitoring the system. Essentially, generated alerts are based on message context in a pipeline, to send to an alert destination. Other business information within the SOA should be contained in a message logs and be available through predefined management reports on the proxy services themselves.
Implications
Although, I have always hated the concept of evangelizing about technology, I do believe that you have to have a certain amount of faith in a technology you are working with to be successful. With respect to SOA, faith comes with a deeper understanding of the concepts and technologies.
For More Information
SAML, JAAS, & Role-Based Access Control: Part 1 and Part 2.
Enterprise Service Bus: Part 1 and Part 2.
Web services, Java and XA for distributed transactions
Using Web services as distributed transactions and the role of XA
