pick your style:  default | greenhouse | golden | original   

Masvent provides business solutions that mainly backboned by software systems as its core competence. The business solutions are developed and tailored to address and solve the client's problems.

more on masvent solutions...


SOA Lessons Learned

by Frank Teti
Source: www.softwaremag.com

Not all SOA and Web services architectures are created equal; three different companies implemented completely different SOA projects and learned important lessons along the way.

Although CORBA has less than a handful of program language bindings, Web service clients can be a Java Server Page, servlet, or Java application, or an executable written in languages such as C++, Perl, Visual Basic, JavaScript, and so on - a truly ubiquitous protocol.

However - to paraphrase the inimitable comedian Chris Rock - you can drive a car with your feet, but that doesn't mean it's a good idea. With respect to Service-Oriented Architecture (SOA) and Web services, just because an application architecture is viable doesn't necessarily mean you should implement it.

This article critiques a set of unique SOA projects from a technical management perspective. The companies evaluated are a retail establishment, a pharmaceutical firm, and a communications company. Type of industry is really not that relevant; however, the lessons learned are generally applicable.

Assessing the Corporate Style

One thing that all of the companies evaluated had in common was that they would probably not consider themselves to be early adopters. Years ago, when I was spending more time doing software product evaluations, I was trained to identify whether a company was conservative or cutting-edge when it came to technology purchasing decisions. This factor was important to the overall evaluation decision.

In general, from a SOA standpoint, most organizations fall into one of two categories:

Mature organizations that know how to construct services and are ready to move to a more enterprise-wide model, which would include an Enterprise Service Bus

Neophyte organizations that are still struggling with developing Web services and how and when to deploy them

Note that organizations that may not consider themselves to be cutting-edge, or even want to be, may find themselves in that category as the result of a series of inadvertent decisions.

An Online Retailer

This company needed to replace and retire its tier 1 Enterprise Resource Planning (ERP) applications globally. The technology organization would be characterized as being a COBOL/CICS mainframe shop for back-end operations, including order entry and fulfillment. On the front end, it was all Microsoft, with the standard Microsoft client-server and personal applications in place.

In an effort to stay more modern, the retailer needed a new platform to rewrite the enterprise applications. Having recently attended a Gartner SOA conference, the company's high-level executives decided that the best strategy would be to use Web services to bridge technology between the front-end Microsoft environment and a back-end mainframe. One of the objectives was to preserve their investments in Microsoft technologies, including the investment in manpower.

This organization also still viewed the mainframe as an environment that was more secure and easier to administer than a farm of smaller processors. IBM had sold it on using WebSphere Application Server (WAS) on a zSeries. Although the company was new to Java and J2EE, it had solid experience running mission-critical applications on the mainframe. Additionally, it used IBM's WebSphere Studio Application Developer (WSAD) 5.0.1, including the Rational UML design plug-in. WSAD was, at the time, IBM's core-application J2EE interactive development environment, built on Eclipse.

Enterprise-wide SOA projects and programs usually need a business case, return on investment (ROI), or a metric of some kind to justify the considerable software costs and, more importantly, the manpower costs, including retraining cost. The retailer wanted to retain its IT staff, even though the resources in place were not the type of resources needed to accomplish its new technical direction, which was essentially SOA and J2EE.

Early SOAP Web services prototypes using WAS on the zSeries indicated that MIPS utilization for SOAP Web service was considerably higher than the existing COBOL application. In a retail online environment, performance is king. The zSeries is optimized for I/O-intensive, robust database management systems and queue parallel-processing applications, not really for the CPU-bound parsing required for SOAP message processing with WAS. At this point in time, not many organizations globally were using mainframes for running WAS; building applications for this target environment was not an easy path forward. SOAP Web services, XML and XSLT, Command and HTTP Dispatcher patterns, and even a form of custom AJAX were evaluated as enterprise-wide standards.

The company not only found itself with a cutting-edge architecture, but also had to retrain staff in object-oriented design and programming. A more conventional architecture would have been a better choice here, where the zSeries occupies its more traditional role as a data server, not as a middleware server. Besides that, implementing a set of tier 2 applications would have been a better approach for the development teams, rather than sticking to the myth that design tools result in quicker and easier implementations.

A Mid-Sized Pharmaceutical Company

This company wanted to build SOA applications using Swing as a Web service client, including a browser for presentation services, instead of using a more server-side approach. The firm's philosophy was that Swing provided a richer user interface (UI), and using Swing ensured a certain amount of programmer productivity. However, this architecture provided a daunting environment from a security perspective.

Within the SOA, the organization wanted to use WS-Security - more specifically, signed Security Assertion Markup Language (SAML) tokens - as the authentication policy for their Web services. WS-Security truly represents a security paradigm shift, because it applies security at the very granular message level, instead of at the transport level. (More detailed information on WS-Security can be found at www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss.)

SAML is really engineered for server-to-server authentication (and authorization). High-end JEE application servers are engineered to validate and generate SAML tokens. SAML assertions are communicated by a Web browser through cookies or URL strings. Needless to say, this type of functionality does not exist in a Swing application.

In order to provide single sign-on (SSO) and secure Web services using SAML tokens, a fair amount of custom coding needed to be developed. In this case, one of the programming tricks was that the SAML assertions had to be bound and injected into the SOAP document's envelope header in order for the Java/Swing application to secure the payload programmatically. Additionally, the Java/Swing application had to invoke the SAML provider directly to acquire the SAML token, instead of having this functionality be part of the source website. Essentially, the Swing/Java application needed to reproduce functionality that would normally be part of a source site for SAML security.

This company also found itself with a cutting-edge SOA, primarily because it did not want to adopt more-standard conventions for implementing SAML within a SOA. Since the organization was reluctant to consider using server-side approaches to building the presentation layer, its decision implied that it was more important to provide a high-productivity front-end application environment than it was to provide an environment that was easier to administer and manage from an application and security standpoint. Although UI constructs such as JSF, NetUI, and AJAX were recommended, the development effort using Swing/Java application was already under way.

Although the architecture was more complex from a security access and privileges standpoint, it did confer certain advantages when it came to credential provisioning.

A Large Communications Company

At the other end of the spectrum of approaches to implementing an enterprise-wide SOA are the super-pragmatic firms that create Centers of Excellence (COEs) in order to set standards and reference architectures for the development groups. This firm rightly identified security as a core focus of the COE.

Within former distributed technologies, such as Distributed Computing Environment (DCE) security, using Kerberos within a DCE cell was inextricably linked to using the DCE Remote Procedure Call (RPC). Within Web services technologies, there is nothing in place that preempts the use of a SOAP RPC call without security. It is my opinion that because of the distributed nature of Web services technology, many organizations are putting Web services applications into play where sensitive information may be compromised.

A pragmatic approach to SOA security design is to analyze the tier 1 projects under way. Projects such as B2B integration or enterprise-wide Electronic Bill Payment and Presentation (EBPP) rationalization are good candidates. The overall objective is to prescribe the appropriate Web service security model, based on specific business use cases. (See Fig. 1.)

SOA Lessons Learned

Tactically, the consultant needs to integrate (to a degree) with the project teams, but not be embedded. Otherwise, the security team establishing standards runs the risk of becoming part of the application project, and while the project team might enjoy the presence of full-time security experts, the objective is to establish firm-wide standards, not necessarily to design and develop a security model for a single project.

Essentially, this is a bottom-up approach. Methodological purists might take offense at this approach because it isn't high-level, but in my opinion, as long as the strategy implements solid industry standards and the solutions are repeatable, in the long run the outcome will be as desired.


It is abundantly clear to me that a technology organization should know when it is on the cutting edge or approaching the cutting edge. An indicator that a company is navigating uncharted territory is when it calls a technology effort a proof of concept (POC), when in reality it might be just exercising the core functionality of an application. The term POC should be invoked when developing or integrating technology for which there is no readily available reference architecture.

If you are new to a technology, and you like being a late adopter, stay with standard approaches to implementing the target technology. If it sounds as if I'm discouraging creativity, then I guess that's the downside of being conservative.

Try to stay away from decisions by committee. With large-group decisions, everyone feels compelled to add value by contributing in some way to the decision. The conscientious effort of a group, in the final analysis, may turn out to mangle the original intention and scope of the effort.

If you are a high-level technical person, follow the Web services specs - WS-Security, WS-AtomicTransaction, JSR181, JSR 109, JSR 921, and the like. Conceptually understanding technology is a great aid to development groups, which tend to be myopic and get caught up in implementation details. As a colleague of mine often says, "Someone has to understand the big picture."

Frank Teti is a client architect at BEA Systems, Inc., specializing in SOA.


Special Offers

Wait for our next special offer on our products.

Subscribe to our RSS here

Masvent provides business solutions that mainly backboned by software systems as its core competence. The business solutions are developed and tailored to address and solve the client's problems.
Home | Contact | Blog | Feedback | Site Map | RSS | Share Terms of Use | Privacy Policy  Copyright © 2007-2014 PT. MASVENT TECHNOSOFT All Rights Reserved.