[Series Links: Part I / Part II / Part III / Part IV]
In the previous post, we did a high level look at SOA Software and the core modules of that platform that my company is using. Now, let’s dig a bit deeper in one of the base subsystems, the Management Server.
At its core, the SOA Software Management Server allows you to configure your services by applying appropriate policies. The Management Server also provides the monitoring component, but we’ll discuss that in the “monitoring and alerting” post that will follow this one. Here we’ll focus a bit more on registering and managing services using SOA Software.
To manually register a service, you can start from the SOA Software Service Manager Dashboard. The wizard window asks you for the WSDL of your physical service.
Then you can choose which operations on the service you wish to manage. “Managing” the operation gives you the ability apply policies, record and monitor data, and so forth.
Finally, you choose a default policy to use. This can be changed after the wizard is complete.
Now, SOA Software has the concept of a “virtual service”. These virtual services act as proxies that can be deployed on different machines, and, may be an aggregate of operations from multiple “physical” services. For instance, I may create four different web services that interact with a “vendor” object. Maybe a few operations on two of those services are going to be publicly exposed to outside parties. I can create a single “virtual service” made up of operations from two of those services, and deploy that “virtual service” to a locked down box in the DMZ. The same “physical service” may be part of multiple “virtual services”. Now because you can apply different policies to each operation in a service, it’s conceivable that you attach different policies to the same “physical service” (by virtualizing it) in order to target different audiences. Maybe the “GetVendor()” operation, when used internally, goes through a particular virtual service that only confirms that the user has a valid Active Directory account. However, when “GetVendor()” is exposed publicly, THAT virtual service operation may require a policy that does encryption/decryption AND authentication. Or, you may have a different service level agreement (SLA) for external parties than for those internal users. No problem, just apply different SLA policies to each individual virtual service. When I create a virtual service, I can choose which operations, from which services, to include.
Note that the physical services being aggregated could be on different servers, and even different application server platforms. No reason I can’t have a virtual service that combines related operations from services in IIS 6.0 and Weblogic.
Services may also get “auto discovered” if they are deployed to a box with the SOA Software agent running. Once a service is managed (either through auto-discovery, or manually), you open up a wealth of management options for that particular service. The most eye-catching part is the real-time feed of usage data.
This Flash object updates in real time so that you can see each service call and how long it takes. By mousing over the bars, you can see specific details about the time the operation took to execute. Nice!
You may think that with all these “virtual services” floating around that it could be a challenge to remember what the correlations are between services. Have no fear, the “Service Relationships” widget provides another Flash-based view of the connection between virtual and physical services.
By moving your mouse over the “services” in this window, you can see the details about each service in the relationship tree.
Finally, the Portal provides plenty of ways to see metadata about services and perform maintenance tasks. The “Actions” widget associated with each service exposes various functions.
You can view a copy of the WSDL, virtualize a given service, and much more. One of my favorites is the “Test Service” function. This actually allows you to execute the service itself. My initial thought was that this would be similar to the ASP.NET Web Services testing page that is shown in IIS. That is, if you have simple type parameters (ints, strings, etc), then test away. However, the default ASP.NET Web Services test page doesn’t allow you to test complex type parameters. HOWEVER, the SOA Software web services tester actually parses out the complex type and lets you test those as well!
That’s great stuff. Unexpected, and very useful.
The SOA Software Management Server is a great way to centralize management and ownership of services. The ability to generate proxy services that abstract the underlying services has enormous implications for distributed environments. In the next part of this series, I’ll tackle the Policy Manager subsystem.
Richard Seroter's Architecture Musings 