SOA tools--virtually bridging the legacy divide Part I
Managing behavior of entire services or processes, though, is different yet from managing "events" in the service--particular messages, whether they are complete transactions or parts thereof, for example. If they are parts of one, then the message will necessarily be asynchronous--one service waits for a response from another service to continue the message--and longer running than a simple, discrete, straight through message. Says Rogers, "Multiple events have to be captured, audited and correlated to determine that a situation has transpired to thus trigger a process to take off." Tools for those activities are then also needed.
Once a service extends beyond an organization's firewall, security becomes an issue. For identity management, for example, an SOA will require IDs for both humans and system elements. A business process comprised of services but governed by business process logic can process documents that are handled and approved by humans--so a human decision and act determines where the document goes next--or data that's automatically processed by systems--so the content of the data and a rule in a rules engine determines the disposition of the data. Authorization also comes into play--human and system user profiles, says Rogers, determine who or what has access to certain services in a registry.
Issues like that also bring up other higher-level areas of concern, like policy management and governance tools, which at this point are still scarce. For instance, Rogers points out that organizations will have to "come up with certain policies about how you bring a service from creation into production, what are the different steps to go through to get it authorized, etc." She adds that larger organizations will actually have different registries for different divisions and therefore different policies for managing each.
Policies, in turn, require a governance structure by which, says Bloomberg, executive management can create and communicate policies so that employees follow them, and management can ensure they're being adhered to as issues arise. Without such, an SOA in a big organization can quickly spin out of control.
A tricky, but unavoidable, transition
This represents just a sampling of tool types needed in an SOA. To get a complete view of how complicated a process achieving an SOA actually is, one might refer to guides like ZapThink's SOA Implementation Roadmap at zapthink.com.
However, while these are many of the activities that SOA tools perform, most products are not limited to performing only discrete activities. Most major platform vendors offer suites or programs that purport to take the customer from planning an SOA through the full spectrum of creation, deployment and management of services.
Other specialists focus on areas like registry management, management of service life cycles, security and so on. Part 2 of this article will examine the majors' strategies for evolving compelling and competitive, multicapable SOA products and explain their efficacy as well as look at key niche players' products in areas like registries and security.
This is valuable information because, despite the confusion about SOA in the potential customer base, some consultancies aggressively predict that somewhere around three-fourths of large and half of small and medium businesses will have adopted some form of SOA by 2006.
John Harney is president of ASPWatch, a consultancy focusing on market, partner and technology strategy for ASPs, e-mail johnharney2@netzero.com.