SOA Management | A Practical Guide to Enterprise Architecture

An SOA will eventually become the backbone of your business. The business case for it is too compelling for it to be otherwise. The more central your SOA becomes to your business, the more you will require an effective set of management tools. The SOA attributes of loose coupling and decentralization of service modules mandate a centralized control structure. The ideal end result is for your SOA to be loosely coupled but tightly managed.

Existing network management tools that are not designed for SOA management are inadequate to manage an SOA for the following reasons:

They are usually binary in nature; they can tell if an application is up or down. Applications are now composed of interacting modules; information about the health of the modules and of their connections is what is required.
They have no awareness of business processes.
They have no understanding of the concept of grouping modules into functional units.
They have no way to effectively manage the security requirements between the modules in the SOA network.

To put it in perspective, the management needs of an environment of monolithic applications are simple and not survival critical. The management needs of a client/server environment are more complex but still seldom critical to the survival of the business. Some N-Tier applications are mission critical and, as a result, come under the control of a management system. Effective SOA management can be critical to the continued existence of the business.

SOA management is a complex issue. We suggest examining your needs around the following topics before examining SOA management solutions:

Performance information
Monitoring and management of running services
Monitoring and management of network issues
Dynamic method for a service to find and bind to its management agent or services
Management of SOA security issues
Management of SLAs
Management of the evolution of services and the service life cycle
Management having the capability to be extendable across enterprise boundaries

Performance monitoring, the ability to examine individual services, and good network monitoring and management are obvious needs. These are bottom-line, absolute, must haves.

Vendors such as Confluent, Amberpoint, and Infravio provide offerings in the SOA management domain.

Your management solution should not require the static linking of your service modules to the application that it is monitoring and controlling. Rather, the linkage must be dynamic and discovered when the module starts up. On the complex end, this can mean a contract in a registry. On the simple end, it can mean building the ability to blindly send and possibly receive events and messages. Any management and monitoring scheme for an SOA must follow SOA principles.

Distributed service environments offer a plethora of points of attack. It is vital that proper security permissions be set among all the modules in your SOA. In a Windows environment, do all your services run with system privileges? On your J2EE application server, how accurately and precisely have you set the security descriptor? Managing all the permissions and roles is an error-prone process when done by hand.

Most of the services in your SOA will support SLA. In addition, the system as a whole will have a global SLA. Having a single point that can document how well you are performing against your SLAs is another strong reason for a services management tool.

Another very useful function that your SOA management tool can perform is to handle service life-cycle issues. You create and deploy this wonderful service. A few defects are surfaced and corrected, so your service modules start to have version numbers. You do a redesign but keep the contract. Initially, you only want to expose this service to a few trusted consumers, while keeping the rest on the old version. The beta run goes well, and the new component is deployed. A couple of the consumers are unable to utilize this new version because of obscure hardware issues, so they have to get the old version when they access the service. In theory, contracts and interfaces are supposed to be immutable for all time. In fact, in some cases you will have to change the contract and deprecate the old service. You should be able to turn to your SOA management tool to handle these issues.

Eventually, you will be consuming services from other enterprises and providing services to businesses other than your own. Ideally, your management tools will be able to manage and monitor not only your own services, but also the outside services upon which you depend. Also, in some cases your business should allow other enterprises to manage and monitor any of your services that they are utilizing. We realize this is a little like asking the lamb to lie down with the lion. If the service is being provided as part of how that business makes its money, you have a much stronger case when you ask the company that is selling you Web services to have visibility into their network and to the service you are utilizing. In the case of Canaxia, it is extremely unlikely that the company will grant any sort of monitoring to its suppliers when it puts up its supply-chain integration Web services. However, if the economic stakes were high enough, that could change.

On the other hand, the introduction of a management system into your SOA environment will bring the following benefits:

Increased visibility into systems operations. In the Systems Architecture chapter we discussed the need to provide management with information about the functioning of the IT infrastructure. A good SOA management tool can help you realize that goal.
Of much greater importance is that an SOA management tool has the possibility of allowing visibility into the performance and health of the business processes. An SOA isolates the business processes into discrete sets of modules, independent of transport or resource access functionality, so they can be looked at in isolation.

Everything said in this section applies to Web services as well. In fact, many of the existing SOA management tools are specific for Web services.

For those who want to buy, the best course would be to pick your SOA management platform early in the process of building your SOA and build it into your SOA as it evolves. Every store-bought management platform will have an approach to SOA. You will be allowed to do some things and not others. Trying to force-fit a well-developed SOA into a management tool could be a painful and expensive process.