Part 1: Building a
Portfolio of Services
by Dan Hynes and Salil
Pradhan
In this first installment
of the Mastering
SOA Series, learn techniques and trade-offs involved in
building out a portfolio of modular services.
Published September
2006
Although Service Oriented Architecture, or SOA, is still
somewhat new, many companies are recognizing the need to adopt an SOA
approach as a method of implementing solutions that are aligned with
business needs. A key step in this approach is building out a portfolio
of re-usable services.
SOA represents a fundamental shift in the way new applications are
designed, developed, and integrated. It also greatly facilitates the
development of enterprise applications as modular business services
that can be easily integrated and reused.
A key benefit of SOA is a reduced gap between business
and IT. As part of the requirements-gathering activity, mapping
business and technical requirements to the organization’s key
business goals relevant to the project will go a long way in ensuring
that the project will be in sync with business requirements.
The impetus to embark on building a portfolio of
services is typically recognition of the need to align business needs
with IT projects. The process typically evolves from an initial
determination of required services, to discovery and classification of
services and resources they depend on, such as policies defining
specific business rules. The outcome, ideally, is a set of
service-oriented business applications that can be modified and re-used
to meet the changing business demands of the enterprise.
While there are numerous considerations to address in
implementing an SOA—such as business process orchestration,
user interface development, and infrastructure to support security and
performance—acquiring a portfolio of services is clearly a
logical first step. In this installment of the “Mastering
SOA” series, you will get an overview of a framework for
building out a service portfolio.
SOA Governance Drives
Portfolio-Building
The people driving the creation of an SOA portfolio will often be those
most concerned with issues related to SOA governance. This
“governance committee” should ideally include a
cross-section of relevant groups, including business process owners,
system architects and developers.
SOA governance is a broad topic worthy of a dedicated article. However,
we can summarize it here as “a framework that blends the
flexibility of SOA with the control and predictability of a traditional
IT architecture.”
SOA governance in this context generally addresses
concerns such as:
- Lifecycle management of
services and related resources
- Dependency management
- Application and management of
policies
- Security and runtime policy
enforcement
- Service availability
- Service provisioning
The importance of implementing a governance platform capable of
managing a growing service portfolio can go well beyond the
enhancements required to technology infrastructure and runtime
environments.
As with any management initiative, a key goal is to
minimize risk—in this case, by defining an SOA strategy that
builds governance into its core. Potential consequences of an
ungoverned SOA may include:
- A disruption in processes
resulting from publishing services that don’t fully conform
to service-level requirements
- Escalations in support costs
through an onslaught of help-desk and field service calls due to
service issues and outages
- A lack of interoperability,
creating silos of business services and perpetuating the same
challenges of a traditional, tightly coupled architecture
- Non-compliance with
regulations through the failure to associate key policies with services
- Security breaches caused by
allowing arbitrary access to data and services
The risk of these issues manifesting in an ungoverned SOA increases
exponentially as the number of service offerings grows. However,
through proper implementation and management of a service portfolio,
much of this risk can be mitigated.
Service Discovery
Your first logical step in building a service portfolio
is to determine what services are needed. Three proven techniques used
to identify and discover candidate services include top-down analysis;
bottom-up analysis; and business process tracing. Note that these
techniques should be considered complementary, rather than exclusive,
and should all play a role in your service discovery process.
As a first step, you should initiate a top-down analysis
focused on decomposing the organization’s business into
functional “domains.” Domains in this context are
logical groupings of closely related functionality and data, such as
customers, products and contracts.
A top-down analysis will typically net a substantial set of candidate
services aligned with business needs. However, this process alone will
not uncover all the candidate services within an organization. A
thorough examination of existing services as well as IT infrastructure,
application functionality, and data that have been previously used by
business applications should be performed next. This bottom-up approach
will typically yield a rich set of high-level as well as low-level
candidate services.
As a complementary effort, you should trace the
lifecycle of each business event to discover what services are needed
to process the event through its lifecycle. This process, known as
business process tracing, will not only uncover the services needed to
process the event, but may also expose service candidates overlooked by
a pure top-down or bottom-up approach.
In addition to identifying services that are needed to
deliver a project, this business process-driven approach can also
provide a sanity check for completeness and give a first indication of
the reuse potential of specific services.
The net sum of your service discovery efforts will be a
conceptual service portfolio containing candidate services that are
most likely needed as projects.
Service Classification
Once a set of candidate services has been discovered, it
is critical that they be classified to enable their design,
development, and subsequent implementation.
Classification may be based on criteria such as
functionality, usage, construction, and invocation. For example,
classifying services as infrastructure services (DNS lookup, email) or
as utility services (transformation) illustrate categorization based on
functionality.
Such classification helps in identifying services that
belong to the same functional domain, allowing the definition of
standards and best practices as well as management and monitoring
requirements for different classes of services. The process of
classifying services will also uncover business service rules that can
be translated into a set of standard, reusable polices that should be
applied to different types of services.
While there is no industrywide standard for categorizing
services, Universal Description, Discovery, and Integration (UDDI)
registries are emerging as the de-facto standard. UDDI allows metadata
to be set not only on services, but also on related artifacts such as
policies and XML schemas.
For example, you might create the following taxonomy
model in a UDDI registry to facilitate discovery, management, and
governance of services:
- Service owner and contact
information
- Functional description of the
service or artifact
- Release information/status,
such as "Version" or "Status: test | production | maintenance"
- Type of service
(“Order Entry”) or line of business
(“Accounting”)
- Usage
patterns/recommendations, such as "transactional | sub-transactional",
"synchronous | asynchronous"
- Expected error messages,
useful in re-use of an existing service
- Service dependencies, which
may include related policies, XSL transformations and XML schemas
- Available service endpoints,
as well as abstract and concrete WSDL locations in the case of Web
services
Categorizing services and artifacts within a UDDI registry will not
only enable you to better classify potential candidates, but will also
enable discovery of existing services that may be re-used, thus
preventing unnecessary duplication of functionality.
Determining Service
Granularity
Striving for an appropriate level of granularity will maximize ease of
use, reuse, and manageability. A top-level, business-driven analysis
will typically uncover high-level (coarse-grained) services that map to
existing needs. As an example, a coarse service might represent
“Process Purchase Order”, which clearly maps to a
business process.
Because it is focused on IT infrastructure and existing APIs, the
bottom-up analysis will typically yield a significant set of
coarse-grained services as well as a number of low-level (fine-grained)
services. An example might be a function enabling a lower-level task
such as “Insert Order Line Item”.
Ideally, your SOA portfolio should consist primarily of
coarse-grained service interfaces, which map directly to business
semantics. High-level services are much more agile in a dynamic
business environment, as they are not tightly coupled to underlying
infrastructure. Coarse interfaces also allow you to build applications
and processes using other services from heterogeneous environments
without concern for the details and differences.
Low-level services, in contrast, are tightly coupled to underlying
infrastructure or APIs and cannot easily be modified to suit changing
business requirements. In fact, wrapping a service around an existing
business object, such as an Enterprise JavaBean (EJB), will inevitably
yield a fine-grained interface exposing each method that can be called
on the bean.
Services that will be used to address very specific use
cases within the organization may be implemented with fine-grained
interfaces, which provide more flexibility to client applications that
use these services. Bear in mind, however, that this increased
flexibility brings with it the cost of increased complexity.
In general, you should avoid exposing low-level
interfaces as part of a service portfolio intended to meet business
needs. Consider instead combining a set of fine-grained services and
composing them as coarse-grained services.
Ultimately, it is important to remember that an
appropriate service is not necessarily either fine or coarse, but one
that maximizes business value.
Service Acquisition
Once you have defined your service portfolio, the next
step is determining how to acquire the actual services: Whether to
build them in-house, acquire them or subscribe to a service hosted by
an external provider.
As a general rule, critical business
services—those that contribute to process flows resulting in
a competitive advantage for an organization—should ideally be
provided in-house.
Chances are that you already have services in-house that
may map to candidates identified during the service discovery phase.
For example, if your organization has ERP or CRM systems, key
interfaces (customers, orders, accounts) are all services that can be
added to your portfolio. Custom applications already used within the
enterprise may also be worthy of analysis to identify available
interfaces.
Services that provide more commodity-driven
functionality—such as providing stock-price
quotes—may be candidates for external subscription, likely
from business partners that your organization already has established
relationships with. As soon as you begin searching for services that
meet your needs, the need for service classification will undoubtedly
become immediately apparent.
As you identify candidate services, it will become
evident that a number of supporting artifacts will also need to be
created and managed, such as policies used to govern services; message
types used by services; and XSL transformations used to transform input
and output messages into the appropriate formats.
Creating a catalog of these artifacts and their
relationship to the corresponding service will greatly aid in building
out your portfolio. A UDDI registry can be an invaluable tool for this
task, enabling you to build a complete online directory of services and
related artifacts.
SOA Management
Considerations
Ideally, your SOA infrastructure should provide a
platform for such management features as monitoring and diagnostics,
externalized security, centralized auditing and logging, and
service-level agreement and policy management. A number of SOA-specific
components are available to further enhance management capabilities,
such as an enterprise service bus (ESB) to enable reliable message
delivery; a business rules engine to capture and automate business
policies; and a business activity monitoring solution to optimize
services.
Use of an intermediary Web services management server
can be especially beneficial. In this configuration, services are
“virtualized” with a proxy URL exposed to
consumers, so that requests are routed through the intermediary rather
than directly to the service endpoint. Utilizing this central
management platform allows policies to be uniformly set on services and
provides a single point for runtime policy enforcement. It also
facilitates the capture of service metrics and usage
statistics—critical data in maintaining the health of your
service portfolio.
Service virtualization also provides the benefit of
location transparency: By exposing the proxy, changes can be made to
the underlying infrastructure without impacting service consumers. The
intermediary must either maintain its own virtual service-to-service
endpoint mappings, or utilize a UDDI registry to discover a valid
service endpoint.
Conclusion
The promise of SOA as a bridge between the worlds of IT and business
continues to evolve. While building out a portfolio of services is an
investment in time and resources, it will yield a tremendous return in
service-oriented business applications that can be modified and re-used
to meeting the changing business demands of the enterprise.
 Dan
Hynes is a principal
product manager in the Oracle Java Platform Group, focusing primarily
on SOA-related products. He has worked in product management and other
technical capacities in a number of Silicon Valley companies.
|
 Salil
Pradhan is an SOA
Architect at Oracle working in the Fusion Middleware product management
group. He has been working in the field of integration, middle ware and
many other software technologies for nearly 15 years.
|
Send us your comments
|
Bookmark
