| |
SOA Software Service Manager 5.0 Workbench 5.0 Product Review
Platform-independence, adapting to client consumption and service provider needs, and situational awareness
By: Paul O'Connor
Aug. 30, 2007 11:45 AM
Many enterprises are currently reorganizing their people, processes, and technology around services. A few are holistically revamping their enterprise architectures around SOA and embarking on roadmaps to achieve grandiose business goals.
Far more enterprises are trying to deal with the unexpected emergence of services and service integration requirements resulting from platform upgrades, portal mashups, ESBs, and service-oriented business requirements such as external partner federation. No matter how they come to SOA, enterprises quickly realize that they need to manage and govern services.
When these enterprises look out over the SOA governance landscape they see a jungle of registries, ESBs, Web services management systems, XML gateways, legacy identity and access management systems, ever-extending platforms, governance interoperability standards, and raw management standards. Knowing that "governance" is an almost primal need for IT management, technology marketing regimes have tried to fill the void with their brands. The result has been a great deal of confusion. It was with this state of affairs in mind that I recently had a chance to take a close look at SOA Software's Service Manager 5.0 and Workbench 5.0. I approached the run through of the product from the perspective of an enterprise architect tasked with governing and managing a Web services integration environment. This is a very common use case in my experience and falls squarely into the second type of services adoption pattern mentioned above that focuses more on the "nuts and bolts" of governance. Before proceeding, I think it is essential to state a set of "nuts and bolts" governance requirements:
• Cradle-to-grave management of the service lifecycle
- Making sure the right service is available at the right time with a compliant interface description and with the right governance policies
- Management of the approvals processes for each stage of the service lifecycle with custom workflow
- Service/schema versioning support
- Service development artifact repository and traceability
- Collaboration environment for service stakeholders
• Seamless registry/repository integration
- Intuitive user interface
- Customizable roles/responsibilities, organizations, and views
• Discovery and value governance
- Registry, search, and reuse enablement
- Client collaboration and demand management
• End-to-end security policy and trust management
- Authentication, authorization, encryption, non-repudiation
- Access control policy via legacy I&AM system integration, as well as integration with emerging fine-grained access control systems
- Integration with XML firewalls
- First-mile and last-mile security policy enforcement
- Audit logging
- Integrated PKI management to support federation
• Runtime management, monitoring, and SLA enforcement
- Monitoring, metrics collection and storage, alerting, problem root cause analysis
- Custom dashboard creation
- Unknown service discovery and management
- Seamless SLA and contract management, intelligent routing and rejection based on SLAs
• Mediation
- Semantic mediation policies
- Technical mediation of transport protocols, message styles and exchange patterns, security token formats, reliable messaging styles
I have purposely left out other aspects that are sometimes included in the broader sense of SOA governance, e.g., business process analysis/modeling, asset management, portfolio management, information modeling, etc. Instead, the focus is on "nuts and bolts" governance: a set of functions that are common to almost every conceivable SOA, but nowhere near enough for some. I was glad to get a chance to put SOA Software's integrated registry/repository/management tool through its paces and found its value proposition to be quite compelling against this "nuts and bolts" governance requirements set.
Background on SOA Software
I started tracking SOA Software last year when it acquired Blue Titan and its mediation technology to go along with an established runtime governance and management tool. At that point it was apparent that they had a roadmap to get to an interesting point in the space. Then they announced Workbench at the end of 2006, which is a design-time governance tool that completes the end-to-end governance and management cycle. Workbench and Service Manager are licensed separately; both include a registry/metadata-repository that they share when working in concert to provide a single participant experience. But the best part of SOA Software's vision, in my opinion, is that they are platform independent in that they include management/enforcement agents for every platform you can think of, every identity and access management system you might own, and both .NET and Java (for policy delegation out of code), and stand-alone mediation points for virtualization. For anyone doing governance on an enterprise, line-of-business, and likely even a departmental scale, this is a must. Governance must be adaptive and cannot entail re-platforming services. With this in mind, you might want to take a close look at SOA Software as you move down your own governance path.
Architecture and Installation
Service Manager and Workbench share a common administration server, which comprises a set of five individual processes working in concert with redundancy for fail-over. The admin server comprises the registry, repository, Web admin interface, and enforcement network management server. You can also reuse any existing UDDIv3 registry. Then there is a network of management points in the form of agents and stand-alone intermediaries. As previously mentioned, agents are available for virtually every conceivable platform service container, including all the app servers, ESBs I am aware of (except the open source ones), and the Microsoft stack as well. Installation was a snap and entailed little more than identifying an instance of one of the supported databases (Oracle 9i and above, MS-SQLServer 2000 and above, or DB2 v8.2) and supplying an admin username and password.
Initial Configuration and Workbench View
Figure 1 illustrates the management console browser app, which is a standard portal interface. Like any portal, the management console is personalized to each role and each organization. Notice the activity tabs across the top of the console. These switch the focus between the major focal points in the tool. The "Workbench" tab reflects the design view of the tool (separately licensed as mentioned earlier) and is where developers and administrators who collaborate on service life cycle, versioning, and workflow spend the majority of their time. Speaking of collaboration, one neat feature of the tool is its collaboration space associated with each service. Each service has its own forum in which developers, administrators, and architects can collaborate on service details. Coupled with the ability to attach unstructured data like design docs, UML diagrams, test plans, and the like, along with workflow history, traceability and process adherence is automated to a large degree. This can really be looked at as a CMMI enabler and streamlining vehicle.
On the left side of the Workbench view is the registry navigator. This is where the tried/true enterprise taxonomy is configured. In the example, I have configured a fictitious enterprise called "ACME Financial," as well as an "Account Services" service provider sub org (which hosts the "AccountManagerService" in view) and an "Account Services Clients" sub org that ostensibly consumes the service internally. Then there is an external partner organization called "ACME Distributors" that also consumes the account manager service. Notice that each organization and sub-organization has a "Services," "Contracts," and "Management Points" folder to contain associated artifacts. We will shortly see that it is the contracting process in the tool that generates much of its power. However, before moving on let me point out some of the interesting actions on the right side of the view.
There are three types of services that the system knows about: registry services, physical services, and virtual services. Registry services are those that are somewhere in the design process but not yet necessarily managed in a container. You don't even need a WSDL to create a registry service, just a thought that a service of some sort is needed. Once it is entered into the registry, workflow and collaboration ensues toward the ultimate provisioning of a production service in a managed container. Along the way, compliance policies are applied to service artifacts as configured in policy templates associated with each life-cycle stage in the process, which is itself configurable. There are stock compliance policies that ship with the tool, like WS-I Basic Profile 1.1 compliance. Custom polices are added as XQuery expressions against service artifacts like WSDLs.
Registry services that are managed at some point become physical services. Physical services can also be created immediately if the container they are to run on has an agent. Just work your way through a simple wizard to associate a WSDL and management point and your service will be under management, and at the beginning of your established publishing cycle. Virtual services are hosted on stand-along management points and are used, not surprisingly, for mediation. The tool has compelling mediation capabilities including semantic mediation (XSLT transforms), transport mediation (SOAP to MQ, BEA-JMS, etc.), message styles (SOAP to POX, RSS, and REST), message exchange patterns (synch/asynch), reliable messaging formats with correlation, and security token formats (like Kerberos to SAML). With the addition of the Blue Titan mediation platform, the tool is able to mediate across a dizzying array of standards versions and differing standards interpretation impedances. I would go so far as to say that it is very difficult to effectively govern without a pretty far-reaching set of mediation capabilities.
Contracts and SLAs
The heart and soul of the tool is its contract and SLA management functionality. Contracts are active in the sense that they govern the utilization of services at runtime and track the relationship between provider and consumer from relationship inception through versioning and SLA changes. This is the fulfillment of the closed-loop governance vision and SOA Software has trademarked the contracting process in the tool, calling it an "Active Contract"TM. Contracts are negotiated between consuming organizations and service providers and can be applied to services down to the operation level. The tool provides configurable workflow around negotiation of service capabilities (highlighting the importance of mediation again in the context of being able to meet client demands), policies, and SLAs. Figure 2 illustrates a common SLA policy template being configured in the tool and which tracks average response time, usage count, and fault count. Figure 3 illustrates the creation of a dynamic management policy with a service consumer throttling rule. A contract could be negotiated that would establish an SLA based on the template created and a dynamic management rule that would throttle access to the service for client requests from the consuming organization under the contract when the SLA was violated and the associated alert issued.
Monitoring and Auditing
The tool provides excellent monitoring and auditing functionality. Alerts can be set up for performance and policy violation metrics, tailored to different consumers, channels, and thresholds. Dashboards are customizable to services, service groups, organizations, and roles. Audit trails provide a comprehensive view of policy violations and actions taken. The integrated view of service performance with respect to contracted policies in the context of the service life cycle and position in the enterprise taxonomy leads to great situational awareness. This is the beauty of closed-loop governance.
Other Features
In the interest of time and space, I will lump together some of the remaining features of the product that I can think of. First, I should mention rogue/unknown service discovery. Embedded management points that spot service traffic in their containers that are not in the registry cause those services to appear as "discovered services" in the Workbench view. Policies can be configured to deal with such services, e.g., block them, alert administrators, etc. Also, there is a whole aspect to the tool that deals with value governance. Value governance is a phrase that refers to being able to manage service consumption in business terms. By assigning arbitrary value to service transactions, even basing the value on the message context, e.g., a dollar value indicated by an XPath expression into the message SOAP Body, a value model can be created around strategic services. Such a model can support a pay for play charging model, which certain businesses (think SaaS) desire. The one last feature that bears mentioning is the Java and .NET delegation APIs. These APIs allow service clients to delegate service calls to a delegator, which interacts with the tools's policy repository to create a compliant service call based on the security policies in force for the service.
Conclusion
Governance is an overloaded word in SOA, and indeed an overloaded concept. Most enterprises that I am aware of would do well establishing a subset of the broader governance aspects tailored to their immediate needs - "nuts and bolts governance." To be effective, governance must be platform independent, adaptive to client consumption and service provider needs, and closed-loop in the sense that situational awareness is provided. I think SOA Software's recent revision of Service Manager (version 5.0) coupled with Workbench 5.0 serves these functions in fine fashion.
|
|