For organizations serious about pursuing an SOA (Service Oriented Architecture), knowing the strengths and weaknesses of your development organization is important to improving the process. To paraphrase Harry Callahan in the movie ‘Magnum Force,’ “ A man's gotta know his limitations.”
Review the Plan
Typically, organizations report on important technology initiatives in their technical strategy or five-year plan, which usually includes a release strategy. Recently, I was a member of a team that was responsible for updating a five-year technical plan. The plan clearly stated an intention to move to an SOA; however, a technical architecture review of recent implementations revealed no evidence of any progress in that direction. Although, it was not politically correct, as an enterprise architect, I felt compelled to state my findings in the update to the plan. Indeed, a key ingredient to a realistic strategy is to access your organization’s SOA maturity and site any evidence of progress along the way.
BEA and IBM both have online SOA assessment surveys (BEA’s survey, and IBM’s survey, registration required for both), and I recommend taking those assessments. However, these assessments are, in my opinion, are just marketing tools, but they are free, too. In general, from an SOA standpoint, most organizations fall into one of two categories:
Mature Organization - They know how to construct services and are ready to move to a more enterprise-wide model, which would include an ESB (Enterprise Service Bus).
Neophyte Organization - They are still struggling with developing Web services and how and when to deploy them.
Fostering a Services Mentality
When object technology was considered a new technology, technologist recommended that organizations needed to adopt a mindset that objects needed to be documented and catalogued, which would then foster reuse. An SOA provides reuse in that a single Web service is implemented for say a member or provider lookup for the enterprise, instead of direct JDBC or HTTP access (see Figure 1), and published in the UDDI.
For organizations that have significant experience with DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM ( D istributed Component Object Model) and/or RMI (Remote Method Invocation), which are consider distributed object technologies, reuse and service orientation is fundamental to the model. For those organizations, shifting to a Web service based architecture service-orientation is not at all new. For organizations who have limited experience with any of those technologies, pursuing an SOA will be a steep learning curve.
SOA = Distributed Computing
In the 90’s, I spent two years on a large DCE project. It took me about that much time to be productive in that environment, even though I was an experience C++ programmer, in hindsight; I was not the only one struggling. The project architects being good object designers specified a system with your standard presentation, business and data access tiers. The DCE implementation of the design model was implemented as three separate DCE servers, instead of a more manageable, de-normalized model. That is, collocating possibly presentation and business tiers or business and data access tiers, essentially package layering not project or server layering. In distributed object architecture, servers are used for clustering and load balancing, and to a degree for application layering. (The New World of Clustering)
Within the application architecture, marshaling data from one server to another using the DCE RPC (Remote Procedure Call) and a conformant array became a technical feat in and of itself. The point is that organizations new to distributed technology, such as Web services and SOA that do not significantly augment their staff with experienced technologist will most likely end up constructing architectures that are suboptimal. It is further recommended that an inexperienced organization cut their teeth on a “mission important but not necessarily critical” project.
SOA Model 1 and 2
Although some EAI architects may take umbrage to this computing analogy, but the difference between an SOA with and without an ESB is analogous to the difference between a hub-and-spoke architecture, often referred to as a message broker, and point-to-point application integration. Basically, Figure 2 depicts a more simplistic point-to-point SOA, while Figure 1 includes an SOA with an ESB.
Figure 1: SOA (model 2) including an ESB
Mature Organization SOA Path – Establishing an ESB
While enterprise architects may be evaluating commercial ESBs, such as, BEA, IBM, Oracle, etc. (see Enterprise Service Bus: Part 2), more tactical eCommerce Application architects feel the need for an immediate solution. Interim solutions can range from wrapping Spring services to using open source ESBs, such as, IONA's Celtix, or Mule. Mule is a (popular) distributed object broker that can handle interactions with services and applications using disparate transport and messaging technologies. I am also aware of one large pharmaceutical company that is using Tibco's Business Works as an "interim" SOA solution, before deciding on IBM or BEA.
For application architects that are pursuing a custom solution, the functional definition of an ESB represents a very complex software application. An SOA, including an ESB, is capable of dynamically transforming Web service payloads, in a deterministic way, through a metadata enabled, policy-driven, configuration environment and intelligently routing the messages to the corporate pipeline. Figure 1 depicts an SOA that includes an ESB.
Communication from the client to the ESB or ESB to the business service can be over HTTP, JMS, SMTP, or FTP. Other core features would include pluggable connectivity, Web services via Axis or GLUE, declarative and programmatic transaction XA support, a REST API for web-based access to events, JCA Resource Adapter(s) for deployment in J2EE 1.4 compliant Application Servers and PGP Security for message signing and encryption. Clearly, an open source solution rather than a custom solution is the more pragmatic route when a commercial solution may not immediately be at hand.
Figure 2: SOA (model 1) can still provide communication from the client to the business service over HTTP, JMS, SMTP, or FTP.
Neophyte Organization SOA Path - Developing Robust Services
Organizations in this group are still grappling with when and how to deploy a Web service and convincing their organization to design with Web services in mind. Web services can be implemented as POJOs, EJBs, servlets, etc. If an organization is already using EJB, it is strongly recommended that Web services be built using a Stateless EJB. An EJB is an autonomous component that includes build-in application functionality. Additionally, the EJB spec is a mature; whereas, some of the WS-* specs that the Web services developers will be working with will not be nearly as mature. Essentially, you do not want to have too many new technologies in the SOA mix.
Using EJB to Implement Services
Whether an organization is implementing a model 1 or 2 SOA architecture, they can still use an EJB to implement services.
- An EJB can be implemented as a coarse-grained session façade that encapsulates the business logic to be used as a Web service.
- Web Services should be stateless and Stateless EJBs can be pooled for optimum application runtime performance.
- Transactions can be managed declaratively by the EJB container.
- With EJB the EJB 3.0 specification entity beans, which really never caught on in the developer community, have been replaced with JPA. Java Persistence API provides a simplified, light-weight, OR mapping framework.
- Stateless EJB may be exposed as Web services using the metadata annotations defined in JSR 181 (Web Services Metadata for the Java Platform).
- An EJB can be enabled to use XML Signatures or Encryption. Alternatively, WebSphere (WAS) 5.1 supports WS-Security; WAS 6 supports WS-Security "approved" spec level.
- For WAS 5.0, which is going out of service in September 2006, SSL and basic auth is available. With basic auth, m ethod-level security can be enabled declaratively with an EJB using Java 2 Security and JAAS (Java Authorization and Authentication Service). LDAP or OS repository can be used to contain the DIT (Directory Information Tree) for user RBAC (Role-based Access Control).
- An EJB can be implemented using either RPC-style or document-style Web services. RPC-style Web services are more efficient and behave more like a standard business object. Document style is more flexible because you can use schema.
SOA within most organization’s architectures is really at a stage where Web (HTTP) servers were in the early days of internet-style computing. In those days, architects were trying to find ways to use Web servers either for serving static pages or basic reporting. In a similar fashion, today’s architects are introducing Web services either for looking up reference data or other basic computing constructs.
To look at SOA any different than the other distributed object models previously mentioned is a rookie mistake. Technological advance in computer technology is much more fluid than it appears in that a new technology in many cases borrows from and improves on an existing related technology. The new feature within Web services is that it is a distributed technology engineered for the Internet. Essentially, there are application requirements where SOA makes senses and application requirements were it is inappropriate.
Other related articles by the author: Enterprise Service Bus:
Yet another Paradigm Shift or better Orchestration of Old Technologies, The ServerSide.com, August 2006
Develop A Service-Oriented Architecture Methodology, WebSphere Advisor 20 06
Use Enterprise Generation Language in a Service-Oriented Architecture
About the Author
Frank Teti is an industry analyst and principal architect. He can be reached at email@example.com.