[Series Links: Part I / Part II / Part III / Part IV]
Recently, the company I work for purchased a web services management platform solution from SOA Software. This post starts a short series where I will highlight the key features of the platform, and, how to integrate BizTalk with this solution.
SOA Software provides us with that “last mile” web services capability set that should help my organization realize our vision of a truly enterprise SOA. Specifically, SOA Software provides us with four key functions:
- Centralized management, including automatic service discovery
- Fully UDDI 2.0 compliant service registry (UPDATE: UDDI 3.0 compliance as well)
- Application of service “policy” via configuration
- Full-featured monitoring and customized alerting
In this first post, I’ll do a very high level overview of each of those functions.
Centralized management, including automatic service discovery
Each of our web servers will have a SOA Software “discovery” agent installed which detects when new web services are deployed to the box. The supported application servers include Websphere, Weblogic, Tomcat and IIS. So this plays very well in a Microsoft, or non-Microsoft shop. Once a web service has been discovered, it can be centrally managed. “Managing” a service can mean applying security policies, establishing service level agreements, apply access/deny rules, and more.
Fully UDDI 2.0 compliant service registry (UPDATE: UDDI 3.0 compliance as well)
It’s nice that SOA Software provides us a service registry out of the box. No need to purchase and integrate another company’s registry solution. The registry has a fairly rich “search” capability where I can search for service by name, usage, category and more.
What are categories? Once a service is managed, you can group the service using user-defined categories. Much nicer than having a registry that just shows a dump of every service with no way to organize them.
Application of service “policy” via configuration
While you could potentially do without the previous two features (even though it makes life significantly easier), the SOA Software Policy Manager service is where you really get your money’s worth. Without TOUCHING the code or configuration files of a deployed service, you can apply a “policy” to that service. Because each service is hosted on a web server with a SOA Software management agent, all service requests can be intercepted. SOA Software acts as an intermediary between the service client and service provider. A service policy may include:
- message logging
- authentication
- compression/decompression
- encryption/decryption
- validation
- much more …
Those are examples of “management” policies. I’ll also show you “SLA” policies, and more in the later post. Each method of a given service can have a different policy attached. I can’t stress how cool this stuff is. When someone builds a service, they don’t have to do anything special for this service management capability. All of it occurs at the management point, not development point.
Full-featured monitoring and customized alerting
A robust monitoring module is so important if you want to evaluate service usage trends in your organization. I can capture the payload of the SOAP messages coming in and out of the services. This includes the ability to see the services before/after policies have been applied. The view below shows my message after a SAML token has been applied.
I can also see various reports about service response time, usage and more. So far, that is just passive reporting. I have to go query for data to discover a problem. What if I have a SLA set up, and NEED to be very proactive about service interruptions or problems? You can subscribe to alerts already configured, or, create your own. I can build an SLA Policy to ensure that if response time goes above a certain amount, or the number of SOAP faults exceeds an acceptable amount, then send me an email message.
In the next few posts, I’ll show more details about these key subsystems. Finally, I’ll show how BizTalk can call one of these SOA Software-managed services. The service *caller* requires a bit of code (in order to inject the headers necessary to conform to the policies), but SOA Software has made it fairly straightforward.
Richard Seroter's Architecture Musings 
One thought