SOA BLUEPRINT – REFERENCE ARCHITECTURE
Group of SOA Practitioners
Abstract Blueprint or SOA Reference Architecture from
Service Oriented Architecture (SOA) is the business their point of view.
operations strategy for leveraging information to meet • Even though SOA is in the initial phases, there are
organizational objectives such as growing revenue, not sufficient development and management tools.
increasing customer satisfaction and improving product • Enterprises are attempting to solve similar
quality. problems but without a forum for sharing best
practices across the industry. Various product
SOA is not a well traveled road and lacks many of the vendors, system integrators, analysts have all
shared experiences, assets and patterns required for attempted to share these practices – however, the
widespread and reliable adoption. Moreover, without a information may have been lost in translation
common language and industry blueprints, SOA may because of lack of common vocabulary across the
fail to deliver the promised benefits of intra and inter- industry.
enterprise services reuse and process interoperability –
instead adding more custom logic and increased These conditions add to the confusion resulting in
complexity to IT infrastructure.. delayed adoption of SOA.
A group of SOA Practitioners have agreed to come SOA Reference Architecture – Definition
together under the SOA Alliance to provide leadership
in the industry to address the challenges. The SOA The SOA Reference Architecture is an ideal “Target
Blueprint is envisioned as a multi-volume collection of State” architecture for an Enterprise or Line-Of-
publications that can act as a standard reference Business (LOB). Some also refer to this as the “Future
encyclopedia for all SOA stakeholders. This document, State” or “Future Vision” of the Enterprise. The
the SOA Reference Architecture, is an early asset objective of the SOA Blueprint is to provide
created as part of the broader SOA Blueprint initiative. enterprises the ability to build a Roadmap to start the
It is intended to provide the end user / consumer journey to the Target State from their Current State.
perspective which hopefully will influence both the
vendor community and the standards organizations.
SOA Reference Architecture Approach
Service Oriented Architecture, SOA, SOA Alliance One needs to understand two aspects of SOA to be able
to develop the reference architecture:
Introduction • The three SOA Foundation components that drive
Service Oriented Architecture
Today, there is a lot of hype around SOA and it is • Enterprise SOA Maturity Model
expected to continue until the industry matures. SOA is
not a well traveled road and has the potential for failing
to deliver the promised benefits of intra and inter-
enterprise services reuse and process interoperability.
Instead, it may add more custom logic and propagate
the IT legacy. Following are some of the reasons for
concern that SOA may not deliver on its promises.
• Every major vendor claims to have adopted SOA
and have published their own view and reference
architecture around SOA.
• Every major standards body has multiple working
or expert groups attempting to define the SOA
The SOA Foundation components are illustrated in the
Figure 2 – Enterprise SOA Maturity Model
The above diagram illustrated the enterprise SOA
maturity model which can be classified into following
• Web Application Development Stage: Provide
browser based business solutions to both internal
and external users. This could be in the form of
rolling out web based CRM, ERP or custom
Figure 1 -- SOA Foundation applications. In addition, IT organizations would
typically deploy enterprise services such as content
The three foundation components are: management, search, instant messaging, discussion
• Business Architecture: Based on the business forums, white board, etc.
strategy, objectives, priorities and processes. • Develop Composite Applications: Access and
Getting this right is essential for the successful provide aggregated information from multiple
implementation of SOA. One of the major benefits sources to the users, initially internally and later
of SOA is reuse of business processes which externally. This generally requires focus on
provides higher ROI than the potential reuse of improving data quality.
Infrastructure or Data components. This also • Automate Business Process: This is the stage
includes the business processes as well as where the applications, data and infrastructure
implementation of business applications. work with the user to provide the capability that
• Infrastructure Architecture: This is the engine that need to perform their roles effectively in the
enables SOA and should address all the aspects of organizations. It empowers them by providing the
the infrastructure from networks, servers, data right information at the right time. It is this stage
centers, firewalls, to application infrastructure, where the enterprise matures and is enabled to
security, monitoring, middleware, etc. achieve higher ROI by consolidating multiple
• Information and Data Architecture: This deals business systems to a single system. This also
with identifying the Key Performance Indicators requires business organizations to transform from
and the information needs that drive the enterprise. their current state to the target state of end-to-end
Data Architecture deals with the logical and business process management, rather than point
physical modeling of the data as well as data solutions.
manipulation and data quality.
The SOA Reference architecture covers each of these SOA Reference Architecture
areas at length by providing approaches, requirements
and design patterns wherever possible. The following diagram illustrates the SOA Reference
Architecture which is categorized into three tiers –
Enterprise SOA Maturity Model Web Application Tier, Service Tier and Application
The SOA maturity model helps enterprises develop a Tier.
roadmap to achieve their Target State.
Figure 3 -- SOA Reference Architecture
It is not necessary for IT organizations to deploy the Contract Management, etc.) or other industry-specific
entire infrastructure identified in this SOA Reference large application suites.
Architecture. One of the SOA Best Practices is to
invest in the infrastructure only whenever it is required Most of the packaged applications are now internet
to provide business solutions. Following is a brief protocol based which means that users can access
description of each of the components: many of its functions using any (supported) browser.
Some of the latest versions of the packaged application
Web Application Tier have provided the capability to expose a limited set of
The primary requirement for this tier is that all the functions as discrete callable services or externally
business systems / solutions should be accessible from controlled business processes.
any (supported) browser. To a large extent, this is the
user interface or the presentation tier and shall contain Some of the best practices for leveraging packaged
business logic for components such as enterprise applications include:
infrastructure services, applications, etc. • Identify and implement the best of the breed
packaged applications that meet the business
Packaged Applications requirement.
• Limit the amount of custom development
Typically enterprises tend to go out in the market and requirement making it easier and cheaper to
license the best of the breed packaged applications that maintain and upgrade.
meet their businesses requirements. IT organizations, • Attempt to achieve one standard implementation
either themselves or by leveraging the System worldwide.
Integrators, then tailor the packaged applications to • Leverage the UI and the business process provided
meet their needs. Examples of such packaged by the packaged applications, wherever possible.
applications are Customer Relationship Management • Leverage Published API’s rather than directly
(Call Center, Sales Force Automation, Campaign accessing the DB.
Management, Order Management, etc.), Enterprise
Resource Planning (Human Resources, Finance,
Following are recommended approaches for taking the • Making modifications to the user navigation or
Packaged Application through the SOA Maturity user interface for some of the core transactions is
Model: not easy.
• As most of the major packaged applications are
1. Develop Web Applications not based on open/standard technologies, their
• Deploy the latest version of the application that is performance may not scale to the business needs.
accessible by any browser; preferably a version • Proprietary development model makes it difficult
that supports appropriate portal standards such as to find resources or rapidly deploy new business
• Expose application services for consumption by • Integration to other technology is not straight
Custom Applications, preferably as web services. forward resulting in point-to-point integration and
This may require an adapter to enable access the possibly poor data quality.
application. Some recent versions of applications
provide Integration Gateways or Web Services Following are some options for developing custom
access directly to the application services. applications.
• Provide seamless user experience by incorporating 1. Develop and deploy custom applications on an
the enterprise look and feel (templates, skins, Application Server
skeletons, CSS) as well as integrating with the 2. Develop and deploy custom applications by
enterprise Single Sign-On Solution. leveraging a Portal
• Externalize Authentication by integrating to the 3. Develop a thick client either using tools based on
Enterprise Identity and Access Manger (typically open standards or proprietary development tools
This document shall focus on options 1 and 2. The first
2. Develop Composite Applications step for IT organizations is to determine the approach,
• Identify business objects that could be shared infrastructure and tools for developing custom
across the enterprise as composite applications. applications. In addition, IT organizations need to
• Send event notifications (triggers) to the composite define the governance and organization model to
applications to initiative specific actions. develop the custom solution. This is not in scope for
• Modify business processes and user interfaces as the SOA Reference Architecture document.
required to enable the composite applications.
• Expose additional business services to enable the A short note on the thick client custom applications;
composite applications to synchronize / update the these applications are typically developed using
packaged application. SWING, Visual Studio or similar other tools. Most of
these thick clients need to interface with some external
3. Automate Business Processes systems and the recommended approach would be to
• Understand and model business processes to leverage open standards such as SOAP, Web Services,
identify opportunities for re-engineering. XMPP, WebDAV etc. instead of directly accessing any
• Identify re-usable portions of business processes external resources such as databases, file systems or the
that can potentially be automated by a business like. This approach makes it easier for IT organizations
process engine. to support and upgrade the integration.
• Expand the number of services and business
processes already exposed in the prior stage. Custom Applications Business Requirements
Typically most enterprises have already deployed
• Reduce / consolidate the number of applications
external sites as well as multiple internal
sites/applications to support the diverse needs of each
of the business units. These are most probably built in
Custom Applications silos and the first step is to standardize (unify) the look
feel and the infrastructure across the enterprise which
Organizations may prefer to create a distinct brand and shall make it easier for a customer, partner and an
unique experience for their customers and partners that employee to get the information they are seeking.
is significantly different than the one offered by the
off-the-shelf packaged applications. This requires Following are the business requirements for this phase
providing a consistent seamless interface to the users which are based on various survey feedbacks from
(both internal and external). Packaged applications users and discussion with various business units.
have the following limitations in this regard: • Unify user experience on the external site, making
it easy for potential users, partners, customers and
analysts to find information that they are looking
for. This proposed architecture would provide the
• Standardize the look and feel across all sites following benefits:
(internal and external) as well as process and
procedures for publishing content. • Based on SOA which promotes re-use at all levels.
• Create one my<company name> site for all • Provides capabilities to deliver in weeks not
employees, contractors, partners, customers to months (once there is a stable framework in place).
personalize the services/content. • Leverage each product for what it is good at,
• Provide secure access to confidential information example: Portal for presentation based on
for all sites (internal and external). entitlements.
• Provide a highly reliable, available and scalable • Allow business to combine services to deliver new
• Facilitate branding and accessing multiple • Domain Layer abstracts the data source and the
application through a common portal. relationship, thereby minimizing the impact of
• Allow users to login once and gain access to all changes to the source systems.
their services. • Loosely coupling Presentation from the business
• Ability to personalize service based on roles and logic makes it reliable and scalable.
responsibility of the user. • Consistent with SOA principles.
• Reduce maintenance cost of maintaining multiple
systems/applications; standardize on one Following are the roles of each of the layers in the
platform/environment. proposed architecture:
• Standardize on one look and feel; eliminate
multiple user training requirements. 1. Presentation Layer: A Portal is responsible for
• Reduce operations and support cost to enable IT to handling all presentation services. Portlets drive
deploy scarce resources on developing new the user experience where a portlet is a view on an
Custom Applications Architecture Approach 2. Business Delegate Layer: Components
As Portals provide a proven set of capabilities in responsible for the communication between the
support of the presentation later, most IT organizations presentation and the business layers. Business
have started standardizing on a portal for developing Delegates abstract the communication details and
custom applications. Following is a recommended complexities involved in making a call to the
architecture approach. business layer. It includes a Model View
Controller framework that facilitates the user
navigating through the web site.
3. Services Layer: The Services Layer utilizes the
capabilities of the Application Server. It is
composed of stateless functions that expose high-
level business functionality. It includes a Session
Façade which is the entry point to the business
layer. Session Facades abstract away the details of
handling fine-grained business entities from the
presentation layers. Most of the business logic can
be implemented directly on Session Facades or on
a sub-layer commonly designated as Application
4. Domain Layer: The Domain Layer also utilizes
the capabilities of the core Application Server. It
is a collection of business entities that define
persistent business concepts. Technologies that
handle database storage need to be used in this
layer since these components represent persistent
Figure 4 – Custom Application Architecture state. Entity Beans are an example of technology
than can be used to implement some of the 5. Monitoring: There is a need for operations staff to
components of the Object Model. Alternatively monitor the platform and applications and
Plain Old Java Objects (POJO) can be used with proactively resolve issues. In addition, most
the help of Data Access Objects (DAO) for external sites have an uptime requirement of over
persistence. Entity Beans are the preferred 99%. Typically all operations departments within
mechanism to implement this layer but a IT would already have identified and deployed a
combination of technologies may be required monitoring tool. There is a need to standardize and
depending on the complexity of the Object Model. document the development requirements to
integrate with the applications or platform used by
Custom Application Framework Components the existing monitoring tool. In some case, there
Custom Application Framework Components basically would also be a need to for additional specialized
extend services which are inherent in the application monitoring tool which may need to be purchased
server platform. Following are the list of Framework or developed and deployed.
6. Search Framework: Most portal applications
1. Data Services: This is basically the persistence need to present data in a tabular format to the
layer provided for the applications. The container users. Instead of each developer attempting to
management is robust enough these days to resolve this problem it makes sense to develop a
leverage CMP for most of the simple transactions. “search framework” which could be leveraged.
It would be also be prudent to provide DAO as an The following diagram illustrates the architecture
option for handling any complex transactions. approach to the Search Framework.
2. Logging Services: Every enterprise should
standardize the logging services used by
applications and is best to leverage the features
provided by JDK 1.4. Various types of message
could be logged such as debug messages to trace
any issues, error or fault logging for diagnostic
purposes, activity logging for audit trail and usage
analysis, etc. If the logging service is generic
across the enterprise, it will enable the staff to
more effectively determine performance or
transaction bottlenecks. Logging Services involve
standardizing the mechanism, communicating it to
the entire development community within the
enterprise, and ensuring compliance with the
standard. No specific code needs to be developed
for this service.
3. Exception Handling: This is similar to logging Figure 5 – Search Framework
services in that standard application server
capabilities should be leveraged. The task is to Following are the functionality provided by the
decide what mechanism to use and communicate it search framework:
to the entire development community within the • Dynamic query generation based on user input
enterprise. No specific code needs to be developed • Sort order, joins, etc.
for this service but it would be useful if examples • Count total search results for display
of handling exception are also provided. purposes
• Consistent mechanism for handling searches
4. Deployment/Application Configuration: This
• Character escaping and wildcard
also involves standardizing the mechanism of
deploying an application in every environment,
development, QA, UAT, staging and production. • Pagination
The document should also contain details on how • Abstract all database access code from
to build and deploy the applications across the application
various environments. • Criteria used as input
• Search results required in standards such
• Queries reside on external files
• Utilities to handle common UI tasks
• Criteria Persistence
7. Notification Framework: The objective of this
component is to provide a single notification client
to all applications, support Synchronous and
Asynchronous interface to the Notification Engine
and also provide capability to send notification
through multiple channels.
Figure 7 – Service Proxy
9. Security Framework: Today, most application
project teams develop their own security layer,
especially as the current enterprise security
solutions do not meet all their business needs.
There is a need to develop a security framework,
that supports the client side to reduce, if not
eliminate the need for developing custom security
code. Following are some of those function
features required to be supported by the Security
• Single-Sign-On (SSO): capability to login
Figure 6 – Notification Framework
once and be able to traverse from application
to application without having to login again.
The interface to the various channels could be
developed as required for providing the business • Access Control” a set of security features that
capability. addresses three main areas:
• Authentication: determining the identity
8. Service Proxy Framework: Allows services to be of the user interacting with the
deployed either locally or remotely without the applications.
calling application needing to know the • Authorization: determining if a user is
implementation details or location of the service. allowed to perform a particular action.
The concept is very simple; the service locater • Auditing: tracking the actions performed
determines the location of the service and calls it by the users.
in the appropriate fashion. It would support
multiple proxies such as EJB, Web Service and Several secondary services are also required such
Service Bus Proxy; additional proxy types can be as registration, entitlement granting and
developed as required. This could also be entitlement querying. These features should be
leveraged by the Business Delegate to separate the provided as a generic framework that can be used
presentation layer from the service layer. and reused by different applications, each with
slightly different needs but all having the same
• Identity Management – Typically in a large
organization, there are multiple stores for
managing the access control information for a
set of applications / services. This may result service.
in severe management problems. Identity
Management helps by centralizing the access 4. Single Sign-On (SSO): This enables the enterprse
control management capability, as well as to provide a seamless user experience by not
provisioning the users across the enterprise. requiring multiple logins. This Framework
• Consolidated User Profile: This is a capability component should not only support custom
provided by the Portal to enable the applications, is should also support Packaged
application to extend the base profile. This is Applications and Enterprise Services.
typically done by extracting the user profile
from multiple data sources, such as the base Enterprise Infrastructure Services
profile and the application specific profile that These are services (based on applications) that could
is extracted from the application specific potentially be leveraged by the entire user community
repository. (external and internal). Most enterprise services are
• Registration, Delegated Administration, infrastructure components and some of them provide
Provisioning, Repository: These are basically the capability for users to leverage them as an
security extensions built on top of Access application. Following are some examples of
Control to meet the application specific Enterprise Services.
business needs. Alternately, these could be
packaged solutions that can be easily 1. Directory Service: This is the standard directory
integrated with Access Control. services provided enterprise wide and generally
deployed in conjunction with the eMail service.
Note that most of these capabilities are generally Most of the enterprise implement meta-directory
provided off-the-self by a Portal product. IT for managing identity across the enterprise.
organizations will either have to develop and
support this capability if they do not own a Portal 2. Personal Information Management: This is the
for developing custom applications. basically the standard eMail, Calendar, Address
book, etc. and includes access to this information
Portal Services from any channel (browser, thick client, mobile
The primary function of the portal services is to devices, etc.).
manage the presentation tier of the application. As the
presentation is generally based on entitlements, there is 3. Collaboration: This provides capabilities such as
a need to support this capability. white board, conference calling, instant messaging,
discussion forums, news groups, workspace, etc.
1. Presentation: The objective is to leverage the
Portal presentation capability by providing the 4. Enterprise Content Management System: This
skins/templates/skeletons/Style sheets etc. for each is the infrastructure service for driving custom
of the application teams. This should also include applications such as Knowledge Management,
some sample applications to jumpstart the Asset / Contract Management, Collaboration, etc.
application developing, including leveraging the The recommended architecture approach is to
portal navigation capability, both for vertical leverage the APIs provided by the portal or the
navigation bars as well as horizontal tabs. content management provider. All the content
management system market leaders provide the
2. Personalization: Personalization services, such as capability to develop templates for uploading /
portlet layout, background template selection, etc., authoring content as well as workflow for
are provided by the Portal during this phase. managing approval process.
Additional personalization, in context to the
application shall be discussed further in the profile Following are the best practices for implementing
management section of Enterprise Security. the enterprise content management system:
• Define the Taxonomy up front, ideally
3. Authentication: All Portal products provide this creating one that is enterprise wide.
capability and the best practices are to externalize • Create a single document base/repository,
this service. Generally most, if not all, enterprises enterprise wide. This may not be practical, but
have implemented a global directory services is a good goal.
(such as LDAP) within the enterprise. The Custom • Publish all content to one single location in
Application Framework should provide an production and configure all applications to
authentication interface and externalize the
retrieve content from that location (reduces of the best practices based on our experience.
TCO). • Create one taxonomy enterprise wide for the
• A key success factor is end user training for content management system.
the authors and the content approvers. • Define meta-tags for the content and leverage
• Partner closely with the content management them in the Portal to present content to the
system provider by engaging their Architects users (based on their entitlements).
for every project, especially during the design • Use search engines to crawl and create
phase of the project. multiple collections / sub-collections as
• Leverage the pre-built portlets to author, required
review and manage the content. • Leverage federated search between various
• Engage a specialized function person from business units, if required.
either your SI or Content Management System • Leverage portal tags and entitlements to
(CMS) provider to map the business processes protect secure contents.
to CMS workflow. • Recommend storing secure content at the
application server level.
5. Search Service: Any user (external or internal)
should have the ability to find the information they One of the major issues potentially encountered by
are authorized to access. There are two types of large sites is the time taken to crawl the entire
search solutions: content repository. There are few alternatives to
1. Key Word Search: standard search capability help resolve this issue such as creating multiple
that most users are accustomed to. collections and including all the collections in the
2. Natural Language Search: this is generally search criteria, performing partial crawls on a
targeted towards a non-technical / internet periodic basis, setting up multiple search engines
savvy user who has just been introduced to and leveraging federated search, etc. The right
technology and want to find information by strategy to be adopted would be based on the
asking questions using their local language. business needs. Our recommendation is to develop
the architecture and the process in collaboration
The integration of a search engines is straight with the search solution provider/vendor.
forward. It is generally an XML / HTTP request to
the search engine and the engine returns the results Enterprise (Role-Based) Portal
in the order requested. On implementing the Web Tier Components defined in
this document, enterprises would achieve the “Current
The search engine goes hand in hand with the State” as illustrated in the diagram below.
content management system. Following are some
Figure 8 -- Enterprise (Role Based) Portal
In the current state, IT organizations can rapidly deploy
business solutions in the form of customer applications,
Packaged Applications, Enterprise Services a Service Tier
combination of these components. The Custom
Application Framework enables business to provide a The Service Tier is the primary enabler of the SOA and
great user experience. However, this has the following includes the components described in this section. It
drawbacks: enables integration and business process automation
across the enterprise. This tier is based on the SOA
• Re-Branding the user experience would potentially principles of coarse-grained, loosely coupled, and
require changes to all the sites. standards-based services. It provides the ability to be
• Users still need to know the URLs for each of the responsive to changing business needs by providing
sites. By adopting some best practices, this can be global solutions, with reduced application and
reduced but not eliminated. infrastructure complexity, increased reuse of business
• This model results in redundant hardware and services and service orchestration capabilities.
software for each of the point-solutions. This is
because each of the business units would like to Service Bus
schedule their own maintenance windows and the The Service Bus is the key component for delivering
only way to facilitate this is to have dedicated the service-oriented infrastructure for IT agility and
infrastructure for each of the point solutions. alignment with business needs. It should have seamless
integration with service registry and service
The Target State is to leverage the concept of management components which in turn accelerates
Federated Portals to create an enterprise wide Role configuration and deployment management and
Based Portal. The advantages of this approach are as simplifies management of shared services across the
• Single point of entry for all employees, customers, The Service Bus should be able to receive any
partners, etc. synchronous or asynchronous message in any protocol
• Provide Application (Portlets) access based on the and route it to the destination based on configuration
role of the user. rules. In addition, it should provide the capability to
• Enable consolidation of infrastructure (both transform the message to the format required by the
hardware and software). destination. As this controls the message flow between
the consumer and the producer, the Service Bus is in
• Always-ON capability provided by the Enterprise
the unique situation to manage, monitor and enforce
(Role based) Portal.
the service levels.
• Simpler re-branding of sites.
• Multi-Channel delivery provided by the Federated
Portal by leveraging Services.
Figure 9 – Enterprise Service Bus Architecture
The above diagram represents the Enterprise Service • Support multiple authentication model.
Bus. The Service Bus basically acts as a dynamic • Policy-Driven SLA enforcement:
configurable Message and Service broker. Following • Establish SLAs on a variety of attributes
are the capabilities that define the Service Bus. including throughput times, processing
• Message Brokering between heterogeneous volumes, success/failure ratios of messages
environments. processes, number of errors, security
• Support Asynchronous, Synchronous, Publish violations, schema validation issues, etc.
and Subscribe messaging • Initiate automated alerts or operator-initiated
• Support synchronous and asynchronous responses to rule violations via flexible
bridging mechanisms including e-mail notifications,
• Support multiple message formats including triggered JMS messages, triggered integration
SOAP, SOAP with attachments, XML, processes with a JMS message, Web Services
structured non-XML data, raw data, text, invocations with a JMS message or admin
email with attachment. etc. console alerts.
• Support heterogeneous transports between service
end points. Following are some best practices for the Service Bus.
• Support multiple protocols such as File, FTP, • It is good practice to start adopting the Service Bus
HTTP(s), multiple JMS providers, RMI, Web whenever the number of services is more than 50.
Services, CORBA, DCOM, eMail (POP, One definitely needs a service bus when the
SMTP, IMAP), SIP, etc. number of services exceeds 150.
• Support message transformation capability which • Start small by targeting a single composite
is required to enable the consumer to talk to the applications or divisional business process that
producer and is not expected to be leveraged as a spans multiple systems.
full fledged transformation engine. • Multiple LOB could potentially manage their own
• Support configuration-driven routing: service bus based on their policies and a Service
• Message routing based policies or call-outs to Bus at an Enterprise level could act as a broker for
external services to support complex routing. sharing services across the various business units.
• Support both point-to-point and one-to-many • The functionality described above must be
routing scenarios to support both request- abstracted from the service itself. Organizations
response and publish-subscribe models. must make the decision between deploying a
• Provide Monitoring capability: vendor provided Service Bus and internally
• Service monitoring, logging and auditing with developed abstraction layer.
• Capture key statistics for message and Service Registry
transport attributes include message SOA requires services to be coarse-grained, loosely
invocations, errors, performance, volume and coupled, and standards-based. As services are
SLA violations. developed and deployed there must be a catalog of
• Provide High-Availability: services available for architects, developers,
operations, business, etc.
• Support clusters and gather statistics across
the cluster to review SLA violations.
• Simplified service provisioning:
• Deploy new versions of services dynamically
• Migration of configured services and
resources between design, staging and
• Support multiple versions of message
resources that are incrementally deployed with
selective service access via flexible routing.
• Support configurable policy-driven security:
• Support the latest security standards for
authentication, encryption-decryption, and
• Support SSL for HTTP and JMS transports. Figure 10 – Service Registry
The above diagram illustrates the architecture of the • Provide non-intrusive service discovery across
service registry. The Service Producer publishes the multiple systems.
service to the service registry which is leveraged by the • Ability to manage and integrate with multiple
service consumer for runtime binding. The registry also Service Bus and Service Registry infrastructures.
acts as the system-of-record for the predefined business • Integrate with existing Monitoring infrastructure.
policies which could be used at runtime for
enforcement of these policies. Shared Data Service
For this version of the reference architecture we shall
Following are the capabilities that should be provided focus only on the Enterprise Information Integration
by the Service Registry: EII capability. EII refers to software systems that can
• Core services, including replication, UDDI data take data from a variety of internal and external sources
store and security. and in different formats and treat them as a single data
• Information services, including data validation, source.
SOA mappings, advanced classification, and
business data access service.
• Lifecycle services, including approval / change
management, change notification, business service
discovery and QoS management.
• Configuration web-based business service console.
• Platform-independent open architecture,
interfacing with leading enablement, management
and security products.
Following are some of the best practices for the Service
• Similar to the Service Bus - start small and grow
• Every LOB may have its own implementation of
the Service Registry and should be replicated to Figure 11 – Enterprise Information Integration (EII)
the enterprise service registry.
• Provide service browsing capabilities for Following are the capabilities that should be provided
architects, developers and operations so as to by EII:
facilitate re-use and identify service dependencies.
• As this is the system-of-record for all systems, • Provide data modeling capability across multiple
maintain service contract information along with sources.
the service definition. • Develop query (read and write) to extract
• Version all services. information from multiple data sources.
• Support multiple data sources – Database, File,
Service Manager Application Adapter, LDAP, Web Services, etc.
As the SOA implementation matures in an Enterprise,
• Provide data transformation Capability.
there is a need for an overall service manager. The
• Provide data validation capability.
primary function of this service manager is to manage,
monitor and report on all the services enterprise wide. • Expose data services to client applications – RMI
Following are some of the capabilities that Service or Web Services.
manager needs to provide: • Standards based – SQL, XQuery, XML, Web
• Manage and ensure that the Service Level is Services, JDBC, J2EE, etc.
maintained enterprise wide
Note: Even thought the Service Data Object (SDO)
• Map and maintain service hierarchy across the
standards have been defined to simplify and unify the
enterprise and provide dependency matrix to
way in which applications handle data, the industry has
not yet clearly defined the standards for EII. Each
• Detect and manage exception conditions.
vendor has their own extensions that deal with reading,
• Review and monitor business transactions, provide updating and inserting data to each of the data stores.
capability to review in-flight transactions. We would collectively prefer to see the vendors,
• Manage service lifecycle and validate before through the standards bodies, agree on one consistent
scalable and supportable web services, web
Business Process Management applications and portlets. As companies start adopting
The BPM is used to manage long-running business SOA principles to transform their IT architecture, it
processes, both synchronous and Asynchronous. Light will be very important for the underlying services to be
weight service orchestration is usually performed by created in a consistent, repeatable manner with
the Service Bus. Following are the function / features enterprise qualities in mind
that should be provided by the BPM.
A framework can be defined as a reusable, “semi-
• Visual Process Modeling – modify views, business complete” (skeleton) application designed to be
process models, etc. extended to build specific services or applications.
• Built on open standards – BPEL a plus. Frameworks improve and enable consistency in the
• Business process orchestration and automation delivered software. Frameworks invert the control
between private processes, public processes, between themselves and the application or services that
human tasks, error handling as well as supporting are created on top of them.
nested and concurrent processes for advanced
modeling and custom logic as required to enable Frameworks typically provide a set of higher level
rapid customization. programming abstractions and a vastly superior starting
• Optimized process performance: Allows flexibility point for creating enterprise class services. Frameworks
of configuration for state-full (long-running) and also very often specify a layered architecture for
stateless (short-running) process design patterns as services that incorporates several design patterns and
well as synchronous and asynchronous process software engineering best practices. The architecture
execution. specifies the responsibilities of the components in each
• Status monitoring: Allow the user to monitor of the layers and the collaboration between them.
status of end-to-end processes graphically and
measure performance vs. service level agreements. Services based on the frameworks inherit the good
• Process instance monitoring: View statistics on architecture and best practices that have been
running processes; drill into individual details; incorporated into the frameworks themselves. This
terminate, delete, or suspend problematic process makes it possible to ensure that a team of average
instances. developers is able to develop well architected services
that take advantage of design patterns and best
• Enable end users—task creators, task workers, and
task administrators—to interact with running practices.
business processes for handling process
The typical layers that a services creation framework
exceptions, approvals, status tracking, etc.
would offer include:
• User and Group Management: Centralize the
assigning of roles, users, and groups working on
integration projects. • Transformation Layer: Supports protocol and data-
type conversions to support multiple access
• B2B Protocol Support: Enable rapid, secure online
protocols, while at the same time keeping most, if
connection with suppliers and customers via
not all, of the service implementation protocol and
leading standard protocols such as RosettaNet,
access mechanism agnostic.
ebXML, and EDI, with secure messaging, digital
signatures and encryption, recoverable and
trackable messages, and dynamic configuration • Business Logic Layer: Holds all the business logic
in the system. This includes such abstractions as
Request, Result, UseCaseController,
BusinessPolicy objects etc.
SOA Frameworks are re-usable web services that can
scale and be consumed by a wide variety of • Business Data Layer: The layer for domain
applications form the backbone of the SOA. These re- objects, i.e. the objects that have a consistent
usable services must be enterprise-class and designed definition across many applications in the
well enough to scale under load, and meet demands of enterprise. The Business Data Layer should
a diverse audience of stakeholders. provide location transparency - that is, the users of
the domain objects should not be concerned about
SOA frameworks catalyze and support the move to an the exact physical location of the underlying
SOA by helping development teams to rapidly design, persistent data on which the domain object itself is
develop and deploy well-designed, modular, flexible, based. This layer should be able to manage
persistence to, and retrieval from a multitude of Application Tier
persistence repositories in the enterprise.
This is the Tier where IT organizations have made the
• Integration Layer: A placeholder for a myriad of largest investment. Even though enterprises will invest
connection technology implementations ranging in SOA moving forward, this tier is not going to go
from JDBC, to JNI to Java Connectors. All the away anytime soon.
infrastructure code that is needed to access
extended enterprise systems such as ERP systems, Legacy Applications
content repositories etc. will fit into this layer. These are the thick client applications still in existence
within an enterprise. They may the old versions of
SOA Frameworks offer a number of benefits for both packaged applications that have not yet been upgraded
developers and the corporation. For developers, the due to budget / business constraints. Alternately, these
frameworks offer the following benefits: applications are best suited to run in the client / server
• A solid foundation to create services, web
applications and portlets. These applications will typically have some published
• Improved productivity as a result of using a APIs or Logical Models for integration purposes.
framework that incorporates design patterns and
best practices. Mainframe Applications
• Utilize off-the-shelf features of the frameworks Business solution provided by proprietary mainframe
and write less code. systems and integrations to these applications are either
• Don't need to understand the nuts and bolts of through a messaging or database gateways. There is an
J2EE standards and specifications. effort underway by the mainframe software vendors to
• Don't need to be an expert at Object-Oriented expose all their APIs as Web Services, which in most
design and design patterns to benefit from using cases is not the right approach. In most cases, the best
them. approach is to leverage a middleware to develop an
abstraction layer and expose the services at the right
For IT organizations and the company as a whole, the level as required to support the business requirements.
SOA Frameworks offer the following benefits:
Enterprise Application Integration
• A catalyst for getting to a Services Oriented This is the traditional approach to enterprise
application integrations. EAI middleware software
Architecture quickly and at a lower cost.
typically provides the following capabilities:
• Consistency of design and development across
• Messaging: Message Oriented Middleware
• Repeatability and the ability to guarantee a
(MOM) with ability for resources to publish and
minimal level of architecture and design rigor.
subscribe to messages.
• Improved business agility as a result of having
• Business Process Manager: proprietary BPM
modular solutions that can be changed easily
capability to automate business processes.
(often via configuration changes).
• Application Adaptors: Pre-built Connectors to
• Use of software engineering best practices
various packaged applications that allow access to
amongst developers with varying skill levels.
the application views or technology adaptors to
• More consistent, predictable and better tested
other technologies like databases, messaging (MQ,
JMS), Web Services, etc.
• Improved mobility of developers to move from
one project to another. The best practice for EAI is to leverage an integration
Hub. However this by itself, without the appropriate
IT organizations are using SOA principles to supporting methodology, may result in a point-to-point
aggressively create re-usable services that encapsulate solution on the hub. Even though the Services Tier
and expose key business processes. By combining a provides the Service Bus and BPM, which enables
layered architecture, ease of use and a deep emphasis enterprises to move adopt SOA and migrate away from
on good architecture and re-use, SOA frameworks EAI, this migration is expected to take a long time.
enable the creation of enterprise-class mission-critical Especially as large IT organizations have invested very
services in a vendor neutral, portable manner. heavily in EAI and replacing this capability will take a