SOA the Platform: Part 1

Upcoming SOA sessions at INTEROP New York make you stop and think


September 12, 2008
URL:http://www.drdobbs.com/web-development/soa-the-platform-part-1/210601294

Frank Teti is a Consulting Technical Manager at Oracle within the SOA practice. He can be reached at [email protected].


As I perused the conference session schedule in preparation for attending the INTEROP New York Conference, I noticed a session called SOA: Hype or Happening?. Although conference organizers tend to favor controversial topics to draw audiences, I think a better concept would be "A Checkpoint on the Progress of the SOA Platform." Nevertheless, I will try to attend that session.

In my minds eye, SOA in the real world has more to do with issues such as:

Debrief on Distributed Computing

The description of the INTEROP session mentioned above states "For many, SOA sounds suspiciously familiar, evoking the same over promised vendor hype of previous failed integration attempts such as CORBA." Albeit, a better distributed computing analogy would be to compare and contrast SOA with the DCE (Distributed Computing Environment) of the early '90s rather than CORBA.

While the DCE was a software system developed by a consortium (similar to CORBA), it represented, for the most part, best of breed exiting technologies such as the RPC mechanism, naming directory service, authentication service, and distributed file system. In a similar way, SOA and the SOAP RPC mechanism represent the technological advance of HTTP a mature and ubiquitous protocol. More specifically, SOA security tokens take advantage of existing technologies, such as, SAML, X509 digital certificates and Kerberos, and the like.

The open question remains as to whether SOA will possibly be deprecated by a new model the way CORBA replaced DCE as a more modern, objected-oriented, distributed framework. Or, truth be told, suffer the same fate as the DCE, which was robust, but was notoriously hard to administer and had a reputation for delivering systems with long development lead times.

To ponder these types of questions are interesting, but better off left to historians and strategist. In my opinion, tactically speaking, SOA is just starting to hit its stride.

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."

Figure 1: Business Process Modeling (BPM) and the SOA Platform

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

SOA the Platform: Part 2

Reinventing Enterprise-Wide Security: Dispatches from an Embedded Journalist at the Edge of SOA: Part I, II and III

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

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.