SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine, ERP Journal on Ulitzer, VITO Report

Article

The Well-Spoken SOA - How Well Is Your SOA Running?

Understanding the elements of an SOA in the context of management, security, governance, and the power of words

The American comedian and actor Steven Wright once said, "It doesn't make a difference what temperature a room is, it's always room temperature." Words are wonderful that way. They can give you a little blast of pleasure when used cleverly, but like everything else they are subject to fashion. For example, I was speaking at a technical conference recently when I overheard a person whom I know, who is well-respected in this field, say something along these lines: "You have to know how well your SOA is running. Knowing the overall health and responsiveness of your SOA is very important. You've got to get a handle on your governance." The goal was laudable, but the wording was off target.

I've heard the word governance fall from people's lips with increasing frequency recently, which is a good thing. Lately though, it seems to me that there has been an unfortunate blurring of the usage and definition of the word governance with another important word that also ought to be on the tip of the tongues of most people involved with SOA today, and that word is management. Monitoring and controlling the overall health and responsiveness of your SOA is largely a function of management, not governance.

The person whom I mentioned above probably knows this, at least in his better moments, but fashion is a powerful force. Trust me on this. You may consider yourself an up-to-date person both technically and in your style of language and dress, but I assure you, fashions change. Many years from now, photos of you wearing cloths that were once considered the height of fashion may cause your very own children to turn on you. There is no defense against the younger generation when they sense vulnerability any more than you can convince a shark in the midst of a feeding frenzy to try tofu. Speaking from a theoretical perspective, naturally, my advice is to be prepared for the likes of "Gee, Dad, how could you have possibly gone out in public dressed that way?"

A good response is to flash your progeny a peace sign and beat a hasty retreat.

Similarly, in order to spare our dear readers the potential embarrassment of explaining to future generations of telepathic IT people what an SOA was and why we even cared about it, it seems prudent to review and solidify our own architectural understanding. Let us consider the functional elements of an SOA starting with those elements responsible for the actual creation and execution of services. Later, we will focus on other essential elements such as management, governance, and security, and we'll examine their role in the SOA and their relationship with the rest of the IT infrastructure upon which the SOA depends, as well.

Creation and Execution of Services
Many well-known types of enterprise software such as application servers, integration servers, and large business systems have evolved to provide the essential elements needed to create and run services in an SOA. Most often these are Web services based on protocols such as SOAP, but can include other types of services based on technologies such as CORBA or Java RMI as well. These newly evolved entities are often called service platforms. Service platforms minimally provide a service runtime environment for the execution of services, but are often bundled with tools that provide many other capabilities. Most commonly, they include development tools that provide the ability to develop and deploy services to that same runtime environment. Therefore, it is no surprise that most application servers and their associated development environments have been transformed and remarketed as service platforms.

SOA is also about breaking down the barriers between previously isolated legacy application silos and reusing these capabilities in new, more flexible ways. Therefore, both integration servers and messaging middleware vendors, which often have more specialized mechanisms in order to work with legacy systems, have joined the service platform game as well. In fact, a wide range of diverse platforms and technologies are transforming themselves into services platforms. For example, many application vendors such as SAP are also offering service platforms that provide the added benefit of leveraging the business application itself.

Many of these service platforms feature embellished tools that are helpful in designing and creating a modern SOA, including support for many Web services standards. These platforms are usually capable of composing simple Web services into more complex composite ones, and frequently provide orchestration engines so you can more easily create high-level business processes out of these services. They are designed to aid reusability by making it easy find new services via discovery mechanisms (typically UDDI registries), another element of SOA, which they often include as part of a complete service platform package.

Despite their architectural, technical, and functional diversity, one thing that many service platforms have in common these days is that they increasingly follow the current fashion of calling themselves an Enterprise Service Bus or ESB (a previously fashionable word was "fabric," but that has now fallen into disfavor). In my opinion, this was a smart move from the marketing perspective because it creates the impression of an indivisible and essential component. After all, what computer can operate without its bus?

However, unlike a computer bus, elements of an SOA related to the service-oriented applications themselves such as development, runtime, orchestration, transformation, guaranteed message delivery, or registry can also be provided by more specialized stand-alone products, depending on the needs of the organization. As these capabilities become increasingly mature and commoditized (a challenge that J2EE application servers started to face a few years ago), many organizations have already found that they have multiple ESBs and point-products with overlapping capabilities.

Service Platform Limitations
For many organizations, the success of the SOA may ultimately be more dependent upon other SOA elements, such as operations management and security management. As different types of service platforms proliferate, the management and security challenges become more difficult. Why can't service platforms easily provide these capabilities in an SOA? They often promote themselves as "all you ever need to build an SOA." In fact many service platforms do provide limited management and security capabilities. However many service platforms are quite rightly focused on maximizing the benefits of their own technology stack, rather than leveraging and increasing the value and utility of all service platforms that participate in an SOA. Indeed, the service platform vendor may have limited experience or incentive to leverage the management and security capabilities of any platform but its own.

More Stories By Paul Lipton

Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Paul Lipton 04/18/06 02:32:28 PM EDT

No, UDDI is not fated for the dustbin of history, but neither is it the only way to share or distribute policy information. The notion that UDDI must the the center of the universe and holder of all policy is equally absurd. It simply won't happen for practical and historical reasons. Policy will be distributed all over the place; in legacy, identity management, and operations management policy repositories, to name a few. Each of these repositories is optimized to support certain types of policy best at runtime (where it counts). We had best learn to live with that and plan for it.

SOA Web Services Journal 09/01/05 10:23:38 AM EDT

The Well-Spoken SOA Web Services - How Well Is Your SOA Running? The American comedian and actor Steven Wright once said, 'It doesn't make a difference what temperature a room is, it's always room temperature.' Words are wonderful that way. They can give you a little blast of pleasure when used cleverly, but like everything else they are subject to fashion. For example, I was speaking at a technical conference recently when I overheard a person whom I know, who is well-respected in this field, say something along these lines: 'You have to know how well your SOA is running. Knowing the overall health and responsiveness of your SOA is very important. You've got to get a handle on your governance.' The goal was laudable, but the wording was off target.