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

Theoretically, you could use any type of service platform in an SOA because your loosely coupled service consumers should not need to know what platform you are using, anyway. Also, as SOAs become increasingly complex and volatile, with messages being dynamically routed to services based on content, load, identity, and even the current prices or service levels of particular services, it might very well be that the underlying platform of a particular service is not the same from one day to the next. Under these circumstances, depending upon any one particular service platform to consistently apply your enterprise management and security policies across all other types of service platforms is likely to be problematic.

SOA Management and Security
Platforms specific to SOA management and security have evolved to meet these challenges. In an SOA, services are message-centric. Most SOA management and security products function at the service-message level (for example, by monitoring and controlling SOAP traffic). They are designed to transcend the management and security limitations inherent in service platforms, and to supply more sophisticated capabilities while working well in a heterogeneous SOA. They typically offer support for SLA (Service Level Agreements), QoS (Quality of Service), fault reporting, policy definition and storage, auditing, and related capabilities across multiple service platforms.

Many SOA management systems also share some characteristics with service platforms, showcasing message translation or routing capabilities as "active management." Strictly speaking, this is not really management, per se. This is a capability shared by many elements of the SOA today including service platforms and even hardware. In my personal opinion, careful architecture and design, rather than dogmatic adherence to the idea of one central translation or routing point, is likely to serve most businesses better in the long run. Where you put your routing and translation may very well vary according to the task and the requirements.

At any level of the technology stack, management is about visibility and control. Historical record keeping and auditing are also important. Security and management often use similar technologies and tech- niques, but view things from a different perspective. For example, a denial-of-service attack is clearly a security issue (it may actually be intended to draw attention from a coordinated internal attack and is clearly an attack on the business in its own right), but it is also a management issue impacting load, performance, reliability, and more. Thus, management and security are closely related and some SOA management products are beginning to combine functionality in both areas, thus enabling SOA management and security policy to be defined and coordinated using a common interface, and providing a unified administrative perspective.

The market is crowded with numerous startup companies that sell various products in this space, although some have been acquired or have chosen to reinvent themselves in areas outside of management and security, in response to increasing pressure from the leading Enterprise Management vendors. At the time that I am writing this, CA has had a solution on the market for over a year and HP is believed to be preparing to ship a product of its own very soon.

The SOA Does Not Exist in Isolation
It is important to note that most low-level services are themselves only a thin tier that encapsulates and depends upon a much deeper layer of existing business processes and logic. These business processes depend upon custom applications as well as on packaged applications such as ERP and e-mail systems. These systems work both in tandem with and depend upon other IT infrastructure such as application servers, Web servers, messaging and integration middleware, operating systems, storage, servers, routers, and so on. If any one of these diverse entities experiences a problem, it can have an effect on services at the SOA level.

The problem is that while an SOA management solution can certainly identify a problematic service by monitoring message traffic, it is not able to trace the underlying cause of a service's problem down to a particular infrastructure entity; nor can SOA management software monitor or control the lower-level infrastructure entities themselves to dig more deeply into the problem. The challenge becomes even more daunting when multiple infrastructure entities are contributing synergistically to a problem. In other words, the underlying business logic and the supporting IT infrastructure are completely invisible to the SOA management platform. How can the business determine the true root cause for SOA-level service problems caused by the underlying IT infrastructure?

The answer lies in the existing enterprise management and security systems that are already responsible for the overall health and security of the enterprise IT infrastructure. These existing enterprise systems have sophisticated event correlation and root-cause analysis that they apply with good effect to the existing IT infrastructure. In fact, the need for comprehensive, multitiered management and security is one reason why it is very common for well-managed and secure businesses to have sizeable investments in these enterprise systems already in place. In short, these systems often have established event correlation capability and are already helping to run the existing business processes even before most IT organizations began to consider an SOA.

It is these underlying enterprise management and security systems that must be leveraged to do the heavy lifting in order to perform the necessary event correlation and analysis for all of the parties invested in the SOA's success, including operations, security administrators, development, and line-of-business personnel. When SOA management software is appropriately integrated with existing enterprise management and security systems, it becomes possible to explore and to truly understand the operational and security state of the entire business from one end to the other, from the services that constitute the enterprise SOA down to the lowliest network device. But the bottom line is that in order for the existing enterprise management systems to perform this comprehensive event correlation and root-cause analysis, it is essential for SOA management and security systems to function, not in isolation, but fully integrated with the enterprise security and management systems that are already helping to run the business.

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.