SOA tools--virtually bridging the legacy divide Part 2
While the first part of this series categorized service-oriented architecture (SOA) tools into those for creation, deployment and management of SOA services, more granular distinctions are needed to indicate the functionality in which specific tools specialize.
Jason Bloomberg, senior analyst with Zapthink, has laid out such categories in Zapthink's Service-Oriented Architecture Roadmap, available at zapthink.com. According to the Roadmap, the following, more granular categories represent the kind of functionality required from SOA mapping through management, as well as a timeline for developing it, although functionality in some categories must be implemented simultaneously.
Identity and access management
Every solution should start with the customer's unique requirements, and those are determined by the customer's users. So, first, organizations must identify those users. For purposes of simplification, let's assume the services that will eventually result will be loosely coupled Web services, although more tightly coupled ones could be created by modifying traditional middleware, for instance. The SOA security architecture can be one of many types, such as a centralized one, in which a top tier of administrators determine security for lower administrative tiers across the entire enterprise, or a decentralized one, in which separate business units manage islands of security.
Identity management allows the organization to establish a single user context throughout the entire SOA environment. As Bloomberg explains, "There has to be a way to manage identities across the infrastructure so as to preserve the user context across the service abstraction as it touches multiple backend data, apps and data sources." Abstraction means the service links and their various operations like data format transformation between legacy applications or other services. But users can be human (users) or code-based (another service or legacy application), he points out, so in either case authorization is required or the person or service may misapply the used or linked-to service. Identity and access metadata built into the service interface determines, for example, whether a user is authorized to use a service.
If the security policies and specific identity and access restrictions applied to specific users won't change with the new SOA, user IDs and profiles that already exist in the legacy infrastructure in places like LDAP directories can simply be transferred to the SOA environment. If they will change, then administrators will have to alter that data.
Governance
Governance lets management create, communicate, monitor and enforce policies that developers and administrators follow to create, deploy and manage services. So policies govern how services are created (before runtime), deployed and managed (during runtime). Policies, therefore, are guidelines for those activities, not the activities themselves.
Creation policies deal with what a service accomplishes in business terms (creates invoices), so designers can create a service that does that in technical terms (ports data from order management to accounts payable). Deployment policies might involve, for instance, determining what business functions need to be interdependent so designers can combine existing services into appropriate composite ones to accomplish those functions. Management policies might involve how the resulting business functions operate dynamically, so administrators can monitor and adjust the created and combined services at runtime. Executives might alter a policy that concerns the way users process invoices in a new division. So administrators may have to deploy a new version of one service in the composite invoice processing service that previously controlled that business function in other divisions, and then monitor and manage it to ensure it's behaving as designed.
Service-oriented management
Management lets administrators monitor and control the SOA environment according to policies laid out by executives and in reaction to dynamic system operations, such as underperformance. It requires tools that manage the servers, applications and services that enable the business functions according to policies. For instance, management tools might perform system security, life cycle management of services, and connect consumers to providers of services at runtime. This is the most complex type of SOA functionality and overlaps with functionality implemented before and after it.
Some business services that can be managed include business processes (the rules that govern the interaction of a business process that links a retailer and supplier) or transactions (if one was completed and by whom and when). But entire applications and the hardware on which they run need also to be managed, so management services also include platform root-cause analysis (what caused a business problem like messages aren't getting to their destinations fast enough).
In general, says Bloomberg, management services guarantee that your dynamic mesh of services is reliable and does at runtime what you expect it to. For instance, do services described in registries perform the activities they claim to? Are transactions between trading partners accurately logged? Are systems proactive in alerting administrators to potential performance problems like an excess of transactions slowing down the network or applications? Do they send alerts if hardware (server) or software (service) malfunctions?
Metadata management
This determines, for instance, how the metadata defining services in registries and repositories lets consumers interact. Registry management determines how a potential user finds a service description in a registry (a directory of services, descriptions of what they do and pointers to where they are), how a repository (where the services are located) publishes service descriptions to the registry, and how a potential user (consumer) accesses the service in the repository (provider). Registries can be centralized or federated. The latter are located in different places throughout an enterprise, and when a consumer goes looking for a service, one registry might refer him to another to find it. Federated registries seem preferable for B2B commerce, which is usually the ultimate goal of companies implementing SOA environments.
Life cycle management services manage the metadata of service registries and repositories to identify the life cycle phase (creation, deployment, management at runtime, retirement) of a service.
Service contracts that accompany services in repositories are comprised of metadata that determines, for example, what transactions the service can perform and in what processes it can operate.
Content-aware networking
This capability lets administrators or services act on data in the network to improve the performance of the SOA infrastructure or extract business intelligence in almost real time from data passing through the network. Bloomberg says usually those types of tools are needed to more quickly process XML traffic that is inordinately increasing with the growth of SOAs and can bog down enterprise LANs and WANs. Service consumers These are devices or applications that work in a client-like way to consume services. They might be browsers that application developers use to access services via registries from repositories to build composite services. They could also be rich clients that can handle text, formatting and multimedia, and can more quickly handle complex composite services containing those data types in supply chain operations. Or they could be mobile clients that do the same perhaps from cell phones for road warriors, or even be portals that make services available in their application portfolios for an entire division or enterprise.
Service-oriented process
In an SOA environment, processes are just complex services and, therefore, are linked to other processes by service interfaces. Process tools let users do the following with vertical industry-specific processes like claims processing in insurance: orchestrate (define the decision points or logic that determines the execution paths in one or more services that comprise a process), compose (define how multiple services are combined) and choreograph (define how processes interact).