Effective SOA Governance Doesn't Always Require a Registry and Repository
By Chandu Natarajan, Principal Software Engineer, WebLayers, Inc.
Editor's note: Missed our SOA in Action Virtual Conference? Replay sessions
on demand here.
There's no question that a registry and repository can play a critical role
in the success of service-oriented architecture. After all, as part of a larger
governance strategy, a registry and repository can be key to managing service
artifacts and their lifecycles, eliminating redundancies and encouraging reuse
-- the core benefits of SOA that have been touted over the years.
However, if a company with a small, centralized IT team has created a handful
of services, is a full registry and repository necessary? Couldn't the information
just as easily be tracked using existing tools?
Most companies already use a repository (such as a source control system) to
store SDLC artifacts during design time. In many environments, metadata about
these artifacts and their associated services and lifecycles is managed using
existing collaborative workflow tools that are often tightly integrated with
these SDLC repositories. Therefore, storage and management of both service data
(repository) as well as metadata (registry) already exists in some form within
many organizations. If runtime audit capabilities are additionally needed, this
can also be achieved using simple log queries and archiving techniques.
Meanwhile, some architects question whether or not the learning curve associated
with adopting a registry and repository is worth it in the long run. While each
company building an SOA will have to decide whether or not the investment in
a registry and repository will pay off, it is very important to understand that
effective governance is absolutely possible without one.
Like any IT decision, it comes down to identifying the needs of the business
and selecting the right tools that fit appropriately. For some companies, a
registry and repository may be overload if they only need to manage a few services.
For others, however, a registry and repository is the logical next step for
managing and organizing a vast amount of services and their lifecycles, artifacts
and various other technologies that may make their way into the SOA as it is
exposed to different environments through customers, partners, or distributors.
Yet, what seems to be erroneously and inextricably linked is the notion that
effective governance is not possible without a registry and repository. Of course,
governance can and does complement a registry and repository. However, a governance
strategy doesn't require a registry and repository to help architects enforce
policies and obtain greater visibility to mitigate the risks associated with
developing software that's designed to support the business goals of the SOA.
The role of the registry is to serve as the central location for identifying
information about services that have been created and deployed. Ideally, the
registry enables you to better understand those services and their associated
governing policies. Working hand-in-hand with the repository where the service
artifacts are stored, a registry facilitates the management of IT projects by
enabling businesses to more easily discover and reuse relevant services.
Further defining and differentiating the registry and repository is how they
are used with regard to design time and runtime. In simple terms, during design
time, the focus tends to be on the description and identification of the relevant
code and services as they are being checked in. Runtime is more concerned with
service contracts, runtime policies, auditing and tracking services as they
are used throughout the organization. Given that design time and runtime are
terms that also refer to approaches to governance, you can further see how governance
can complement a registry and repository -- yet continues to stand on its own.
Let's assume that a company today has a half a dozen services. However, longer-term
plans call for the creation of many more services as the infrastructure evolves
through a multi-year SOA journey. At what point is a registry and repository
required? Where is the fork in the road when it comes to making the switch over
to fully using a dedicated service registry and repository to track and monitor
all of your web services, artifacts and applications?
If the goal is to put into place effective governance as your SOA evolves,
you may or may not need a registry and repository. Effective governance tools
exist for both the design time as well as runtime that do not require a registry
or repository installation. However, you'll need a way to manage and track the
services to avoid the creation of insecure services and redundant efforts. As
cited above, existing online collaboration and workflow products along with
the integration of policy management and governance tools will work in tandem
with simple auditing and log querying capabilities for many organizations.
So when do you need a registry and repository? Based on customer experiences
and feedback, a registry and repository is optimal in environments that need
Manage more than 50 services that are either created
in house or will traverse the architecture through external sources.
Dynamically discover services located throughout the organization.
Expose services to public registries for community reuse.
Adhere to extensive compliance regulations using advanced security, policy
enforcement and auditing capabilities.
Perform extensive and continuous auditing and logging of these services,
check against SLAs at runtime etc.
Regardless of whether a registry and repository is in place, one of the most
effective ways to ensure the highest quality governance is when it is enforced
early at design time. This way, you can ensure that policies and best practices
are being followed as the software is being designed and developed until the
point when it is deployed. This significantly reduces the cost of re-work due
to non-compliance with policies. As the service artifacts move along throughout
the software development life cycle (SDLC) they can be governed at each step
to ensure full compliance with enterprise policies prior to distribution throughout