Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

This article originally appeared in the members only BPM Strategies Magazine.  Join today to receive your own copy. 

Today, with an ever-growing base of standards surrounding it, Web services has evolved into a design philosophy for componentization of business services within and across corporate boundaries. This is what is now being identified as a service-oriented architecture (SOA).

Moreover, these business services are self-describing and can quickly be consumed by applications that have no prior knowledge of their existence. For example, a spreadsheet application can locate and use a credit scoring service the day the interface becomes available.

Controlling proliferation and usage of these services, however, requires attention to details that are often complex and challenging. Domains are one way to manage this effort.

The Requirement for Domains and Boundaries

A commonly held view for the value of Web services is a universe of business functions generally available to a host of consumers, thus increasing the overall value of each piece of business software created with each use. The most widely recognized boundary for these services is across departments and corporations.

A company's experience with these boundaries will ensue from their work in developing portals and Web applications. This, however, is not an SOA.

When developing an SOA, the same distinctions that we employ for managing and deploying applications within the organization, with some additions, must be followed. For example, one key distinction is between services for internal or external consumption. These distinctions need to be incorporated into the planning and development of an SOA. Domains are logical entities that can help organize service deployment to match these distinctions.

Here are some of the types of categories of domains that an organization should think about when deploying an SOA:

Security domains control access to a group of deployed services. These services will only be discoverable and accessible to those with appropriate rights and each message attempting to cross the security domain boundary will be authenticated. In this way, security is orthogonal to and not tightly bound to the service, facilitating a high degree of reuse and the ability to deploy the same service into multiple security domains.

The core services domain is comprised of services that will be reused by other services. They will not be generically available for all users on the network, but only to developers of new Web services. Core services domains decrease development costs and lower maintenance costs, but limit the potential for these services to be misused.

Administrative domains allow departments to deploy and govern their own

Web services. These are useful to control discovery to a particular group or business unit. In organizations where Web services deployment is not centralized, governance is a major issue of concern. Administrative domains are one way to formalize the ownership.

Management domains facilitate grouping of services by the demands placed upon them, such as responsiveness, hardware or bandwidth requirements. These domains also allow organizations to deploy services with similar needs and usage patterns in a common domain, as well as maximize CPU utilization to meet capacity for a particular service.

Designing Domains

Here are ways to implement domain boundaries for Web services.

The service registry allows applications to discover the location of services. Implementing a service registry will allow the organization maximum flexibility in deploying services. Each registry can deploy its own registry limiting the scope of services that a particular user or application can discover. For example, the development domain may have direct access to a Web service, but, when deployed, the address may point to a security service to authenticate the request.

Directory services allow companies to group users together by role and can provide access to services based on those roles. Emerging Web services security standards, such as Secure Access Markup Language and WS-Policy can use the information in these directories to help manage access to a group of services. In this way the directory can implement domain boundaries for management and security.

The network architecture you use can limit accessibility and discoverability of Web services. Proxy servers and routers can be used to limit access to a domain of services.

Conclusion

Many vendors will tell you that Web services are simple, incremental and that you can start small and grow as needed. This statement is logically true, but those that have been implementing large-scale Web services applications have learned the hard way that the early services don't die easily once deployed in the public domain.

When deploying a Web service, consider who will use this service, what type of support will the service need, and how responsive will this service be under various loads. Domains are a way to help the organization to characterize the requirements for a service and to limit the overhead in managing that service once it's deployed.

JP Morgenthal is an independent consultant specializing in information technology. Domains are just one part of his overall SOA Blueprint, which is a framework for preparing your organization for deploying an SOA. For more information on the SOA Blueprint, email him at morgenthaljp@avorcor.com.

This article originally appeared in the members only BPM Strategies Magazine.  Join today to receive your own copy. 

Back to Articles, including SOA, BPM & BA