SOA Architecture

7/29/2019 SOA Architecture

1/15

SOA BLUEPRINT REFERENCE ARCHITECTUREVERSION 1.1

SOA AllianceGroup of SOA Practitioners

AbstractService Oriented Architecture (SOA) is the businessoperations strategy for leveraging information to meetorganizational objectives such as growing revenue,increasing customer satisfaction and improving productquality.

SOA is not a well traveled road and lacks many of theshared experiences, assets and patterns required forwidespread and reliable adoption. Moreover, without acommon language and industry blueprints, SOA may

fail to deliver the promised benefits of intra and inter-enterprise services reuse and process interoperability instead adding more custom logic and increasedcomplexity to IT infrastructure..

A group of SOA Practitioners have agreed to cometogether under the SOA Alliance to provide leadershipin the industry to address the challenges. The SOABlueprint is envisioned as a multi-volume collection ofpublications that can act as a standard referenceencyclopedia for all SOA stakeholders. This document,the SOA Reference Architecture, is an early assetcreated as part of the broader SOA Blueprint initiative.It is intended to provide the end user / consumerperspective which hopefully will influence both thevendor community and the standards organizations.

KeywordsService Oriented Architecture, SOA, SOA Alliance

Introduction

Today, there is a lot of hype around SOA and it isexpected to continue until the industry matures. SOA isnot a well traveled road and has the potential for failingto deliver the promised benefits of intra and inter-

enterprise services reuse and process interoperability.Instead, it may add more custom logic and propagatethe IT legacy. Following are some of the reasons forconcern that SOA may not deliver on its promises.

Every major vendor claims to have adopted SOAand have published their own view and referencearchitecture around SOA.

Every major standards body has multiple workingor expert groups attempting to define the SOA

Blueprint or SOA Reference Architecture fromtheir point of view.

Even though SOA is in the initial phases, there arenot sufficient development and management tools.

Enterprises are attempting to solve similarproblems but without a forum for sharing bestpractices across the industry. Various productvendors, system integrators, analysts have allattempted to share these practices however, theinformation may have been lost in translationbecause of lack of common vocabulary across the

industry.

These conditions add to the confusion resulting indelayed adoption of SOA.

SOA Reference Architecture Definition

The SOA Reference Architecture is an ideal TargetState architecture for an Enterprise or Line-Of-Business (LOB). Some also refer to this as the FutureState or Future Vision of the Enterprise. Theobjective of the SOA Blueprint is to provideenterprises the ability to build a Roadmap to start the

journey to the Target State from their Current State.

SOA Reference Architecture Approach

One needs to understand two aspects of SOA to be ableto develop the reference architecture:

The three SOA Foundation components that driveService Oriented Architecture

Enterprise SOA Maturity Model


2/15

SOA FoundationThe SOA Foundation components are illustrated in thefigure below.

Figure 1 -- SOA Foundation

The three foundation components are:

Business Architecture: Based on the businessstrategy, objectives, priorities and processes.Getting this right is essential for the successfulimplementation of SOA. One of the major benefitsof SOA is reuse of business processes whichprovides higher ROI than the potential reuse ofInfrastructure or Data components. This also

includes the business processes as well asimplementation of business applications.

Infrastructure Architecture:This is the engine thatenables SOA and should address all the aspects ofthe infrastructure from networks, servers, datacenters, firewalls, to application infrastructure,security, monitoring, middleware, etc.

Information and Data Architecture: This dealswith identifying the Key Performance Indicatorsand the information needs that drive the enterprise.Data Architecture deals with the logical andphysical modeling of the data as well as datamanipulation and data quality.

The SOA Reference architecture covers each of theseareas at length by providing approaches, requirementsand design patterns wherever possible.

Enterprise SOA Maturity ModelThe SOA maturity model helps enterprises develop aroadmap to achieve their Target State.

Figure 2 Enterprise SOA Maturity Model

The above diagram illustrated the enterprise SOAmaturity model which can be classified into followingstages.

Web Application Development Stage: Provide

browser based business solutions to both internaland external users. This could be in the form ofrolling out web based CRM, ERP or customapplications. In addition, IT organizations wouldtypically deploy enterprise services such as contentmanagement, search, instant messaging, discussionforums, white board, etc.

Develop Composite Applications: Access andprovide aggregated information from multiplesources to the users, initially internally and laterexternally. This generally requires focus onimproving data quality.

Automate Business Process: This is the stage

where the applications, data and infrastructurework with the user to provide the capability thatneed to perform their roles effectively in theorganizations. It empowers them by providing theright information at the right time. It is this stagewhere the enterprise matures and is enabled toachieve higher ROI by consolidating multiplebusiness systems to a single system. This alsorequires business organizations to transform fromtheir current state to the target state of end-to-endbusiness process management, rather than pointsolutions.

SOA Reference Architecture

The following diagram illustrates the SOA ReferenceArchitecture which is categorized into three tiers Web Application Tier, Service Tier and Application

Tier.


3/15

Figure 3 -- SOA Reference Architecture

It is not necessary for IT organizations to deploy theentire infrastructure identified in this SOA ReferenceArchitecture. One of the SOA Best Practices is toinvest in the infrastructure only whenever it is required

to provide business solutions. Following is a briefdescription of each of the components:

Web Application TierThe primary requirement for this tier is that all thebusiness systems / solutions should be accessible fromany (supported) browser. To a large extent, this is theuser interface or the presentation tier and shall containbusiness logic for components such as enterpriseinfrastructure services, applications, etc.

Packaged Applications

Typically enterprises tend to go out in the market andlicense the best of the breed packaged applications thatmeet their businesses requirements. IT organizations,either themselves or by leveraging the SystemIntegrators, then tailor the packaged applications tomeet their needs. Examples of such packagedapplications are Customer Relationship Management(Call Center, Sales Force Automation, CampaignManagement, Order Management, etc.), EnterpriseResource Planning (Human Resources, Finance,

Contract Management, etc.) or other industry-specificlarge application suites.

Most of the packaged applications are now internet

protocol based which means that users can accessmany of its functions using any (supported) browser.Some of the latest versions of the packaged applicationhave provided the capability to expose a limited set offunctions as discrete callable services or externallycontrolled business processes.

Some of the best practices for leveraging packagedapplications include:

Identify and implement the best of the breedpackaged applications that meet the businessrequirement.

Limit the amount of custom development

requirement making it easier and cheaper tomaintain and upgrade.

Attempt to achieve one standard implementationworldwide.

Leverage the UI and the business process providedby the packaged applications, wherever possible.

Leverage Published APIs rather than directlyaccessing the DB.


4/15

Following are recommended approaches for taking thePackaged Application through the SOA MaturityModel:

1. Develop Web Applications

Deploy the latest version of the application that is

accessible by any browser; preferably a versionthat supports appropriate portal standards such asWSRP.

Expose application services for consumption byCustom Applications, preferably as web services.

This may require an adapter to enable access theapplication. Some recent versions of applicationsprovide Integration Gateways or Web Servicesaccess directly to the application services.

Provide seamless user experience by incorporatingthe enterprise look and feel (templates, skins,skeletons, CSS) as well as integrating with theenterprise Single Sign-On Solution.

Externalize Authentication by integrating to theEnterprise Identity and Access Manger (typicallyLDAP).

2. Develop Composite Applications

Identify business objects that could be sharedacross the enterprise as composite applications.

Send event notifications (triggers) to the compositeapplications to initiative specific actions.

Modify business processes and user interfaces asrequired to enable the composite applications.

Expose additional business services to enable thecomposite applications to synchronize / update thepackaged application.

3. Automate Business Processes

Understand and model business processes toidentify opportunities for re-engineering.

Identify re-usable portions of business processesthat can potentially be automated by a businessprocess engine.

Expand the number of services and businessprocesses already exposed in the prior stage.

Reduce / consolidate the number of applicationsdeployed.

Custom ApplicationsOrganizations may prefer to create a distinct brand andunique experience for their customers and partners thatis significantly different than the one offered by theoff-the-shelf packaged applications. This requiresproviding a consistent seamless interface to the users(both internal and external). Packaged applicationshave the following limitations in this regard:

Making modifications to the user navigation oruser interface for some of the core transactions isnot easy.

As most of the major packaged applications arenot based on open/standard technologies, theirperformance may not scale to the business needs.

Proprietary development model makes it difficultto find resources or rapidly deploy new business

capability.

Integration to other technology is not straightforward resulting in point-to-point integration andpossibly poor data quality.

Following are some options for developing customapplications.1. Develop and deploy custom applications on an

Application Server2. Develop and deploy custom applications by

leveraging a Portal3. Develop a thick client either using tools based on

open standards or proprietary development tools

This document shall focus on options 1 and 2. The firststep for IT organizations is to determine the approach,infrastructure and tools for developing customapplications. In addition, IT organizations need todefine the governance and organization model todevelop the custom solution. This is not in scope forthe SOA Reference Architecture document.

A short note on the thick client custom applications;these applications are typically developed usingSWING, Visual Studio or similar other tools. Most of

these thick clients need to interface with some externalsystems and the recommended approach would be toleverage open standards such as SOAP, Web Services,XMPP, WebDAV etc. instead of directly accessing anyexternal resources such as databases, file systems or thelike. This approach makes it easier for IT organizationsto support and upgrade the integration.

Custom Applications Business RequirementsTypically most enterprises have already deployedexternal sites as well as multiple internalsites/applications to support the diverse needs of eachof the business units. These are most probably built in

silos and the first step is to standardize (unify) the lookfeel and the infrastructure across the enterprise whichshall make it easier for a customer, partner and anemployee to get the information they are seeking.

Following are the business requirements for this phasewhich are based on various survey feedbacks fromusers and discussion with various business units.

Unify user experience on the external site, makingit easy for potential users, partners, customers and


5/15

analysts to find information that they are lookingfor.

Standardize the look and feel across all sites(internal and external) as well as process andprocedures for publishing content.

Create one my site for all

employees, contractors, partners, customers topersonalize the services/content.

Provide secure access to confidential informationfor all sites (internal and external).

Provide a highly reliable, available and scalableenvironment.

Facilitate branding and accessing multipleapplication through a common portal.

Allow users to login once and gain access to alltheir services.

Ability to personalize service based on roles andresponsibility of the user.

Reduce maintenance cost of maintaining multiple

systems/applications; standardize on oneplatform/environment.

Standardize on one look and feel; eliminatemultiple user training requirements.

Reduce operations and support cost to enable IT todeploy scarce resources on developing newfunctionality.

Custom Applications Architecture ApproachAs Portals provide a proven set of capabilities insupport of the presentation later, most IT organizationshave started standardizing on a portal for developingcustom applications. Following is a recommendedarchitecture approach.

Figure 4 Custom Application Architecture

This proposed architecture would provide thefollowing benefits:

Based on SOA which promotes re-use at all levels.

Provides capabilities to deliver in weeks not

months (once there is a stable framework in place). Leverage each product for what it is good at,

example: Portal for presentation based onentitlements.

Allow business to combine services to deliver newcapabilities.

Domain Layer abstracts the data source and therelationship, thereby minimizing the impact ofchanges to the source systems.

Loosely coupling Presentation from the businesslogic makes it reliable and scalable.

Consistent with SOA principles.

Following are the roles of each of the layers in theproposed architecture:

1. Presentation Layer: A Portal is responsible forhandling all presentation services. Portlets drivethe user experience where a portlet is a view on anapplication.

2. Business Delegate Layer: Componentsresponsible for the communication between thepresentation and the business layers. BusinessDelegates abstract the communication details andcomplexities involved in making a call to thebusiness layer. It includes a Model ViewController framework that facilitates the usernavigating through the web site.

3. Services Layer: The Services Layer utilizes thecapabilities of the Application Server. It iscomposed of stateless functions that expose high-level business functionality. It includes a SessionFaade which is the entry point to the businesslayer. Session Facades abstract away the details ofhandling fine-grained business entities from thepresentation layers. Most of the business logic canbe implemented directly on Session Facades or ona sub-layer commonly designated as Application

Objects.

4. Domain Layer:The Domain Layer also utilizesthe capabilities of the core Application Server. Itis a collection of business entities that definepersistent business concepts. Technologies thathandle database storage need to be used in thislayer since these components represent persistentstate. Entity Beans are an example of technology


6/15

than can be used to implement some of thecomponents of the Object Model. AlternativelyPlain Old Java Objects (POJO) can be used withthe help of Data Access Objects (DAO) forpersistence. Entity Beans are the preferredmechanism to implement this layer but acombination of technologies may be requireddepending on the complexity of the Object Model.

Custom Application Framework ComponentsCustom Application Framework Components basicallyextend services which are inherent in the applicationserver platform. Following are the list of FrameworkComponents.

1. Data Services: This is basically the persistencelayer provided for the applications. The containermanagement is robust enough these days toleverage CMP for most of the simple transactions.It would be also be prudent to provide DAO as an

option for handling any complex transactions.

2. Logging Services: Every enterprise shouldstandardize the logging services used byapplications and is best to leverage the featuresprovided by JDK 1.4. Various types of messagecould be logged such as debug messages to traceany issues, error or fault logging for diagnosticpurposes, activity logging for audit trail and usageanalysis, etc. If the logging service is genericacross the enterprise, it will enable the staff tomore effectively determine performance ortransaction bottlenecks. Logging Services involve

standardizing the mechanism, communicating it tothe entire development community within theenterprise, and ensuring compliance with thestandard. No specific code needs to be developedfor this service.

3. Exception Handling: This is similar to loggingservices in that standard application servercapabilities should be leveraged. The task is todecide what mechanism to use and communicate itto the entire development community within theenterprise. No specific code needs to be developedfor this service but it would be useful if examples

of handling exception are also provided.

4. Deployment/Application Configuration: Thisalso involves standardizing the mechanism ofdeploying an application in every environment,development, QA, UAT, staging and production.

The document should also contain details on howto build and deploy the applications across thevarious environments.

5. Monitoring:There is a need for operations staff tomonitor the platform and applications andproactively resolve issues. In addition, mostexternal sites have an uptime requirement of over99%. Typically all operations departments withinIT would already have identified and deployed amonitoring tool. There is a need to standardize anddocument the development requirements tointegrate with the applications or platform used bythe existing monitoring tool. In some case, therewould also be a need to for additional specializedmonitoring tool which may need to be purchasedor developed and deployed.

6. Search Framework: Most portal applicationsneed to present data in a tabular format to theusers. Instead of each developer attempting toresolve this problem it makes sense to develop asearch framework which could be leveraged.

The following diagram illustrates the architecture

approach to the Search Framework.

Figure 5 Search Framework

Following are the functionality provided by thesearch framework:

Dynamic query generation based on user input

Sort order, joins, etc.

Count total search results for display

purposes Consistent mechanism for handling searches

Character escaping and wildcardinterpretation

Pagination

Abstract all database access code fromapplication

Criteria used as input


7/15

Search results required in standards suchas java.util.List

Queries reside on external files

Utilities to handle common UI tasks

Pagination

Criteria Persistence

7. Notification Framework: The objective of thiscomponent is to provide a single notification clientto all applications, support Synchronous andAsynchronous interface to the Notification Engineand also provide capability to send notificationthrough multiple channels.

Figure 6 Notification Framework

The interface to the various channels could bedeveloped as required for providing the businesscapability.

8. Service Proxy Framework: Allows services to bedeployed either locally or remotely without thecalling application needing to know theimplementation details or location of the service.

The concept is very simple; the service locaterdetermines the location of the service and calls itin the appropriate fashion. It would supportmultiple proxies such as EJB, Web Service andService Bus Proxy; additional proxy types can be

developed as required. This could also beleveraged by the Business Delegate to separate thepresentation layer from the service layer.

Figure 7 Service Proxy

9. Security Framework: Today, most applicationproject teams develop their own security layer,especially as the current enterprise securitysolutions do not meet all their business needs.

There is a need to develop a security framework,that supports the client side to reduce, if noteliminate the need for developing custom securitycode. Following are some of those functionfeatures required to be supported by the SecurityFramework:

Single-Sign-On (SSO): capability to loginonce and be able to traverse from application

to application without having to login again. Access Control a set of security features that

addresses three main areas:

Authentication: determining the identityof the user interacting with theapplications.

Authorization: determining if a user isallowed to perform a particular action.

Auditing: tracking the actions performedby the users.

Several secondary services are also required suchas registration, entitlement granting and

entitlement querying. These features should beprovided as a generic framework that can be usedand reused by different applications, each withslightly different needs but all having the samebasic requirements.

Identity Management Typically in a largeorganization, there are multiple stores formanaging the access control information for a


8/15

set of applications / services. This may resultin severe management problems. IdentityManagement helps by centralizing the accesscontrol management capability, as well asprovisioning the users across the enterprise.

Consolidated User Profile: This is a capability

provided by the Portal to enable theapplication to extend the base profile. This istypically done by extracting the user profilefrom multiple data sources, such as the baseprofile and the application specific profile thatis extracted from the application specificrepository.

Registration, Delegated Administration,Provisioning, Repository: These are basicallysecurity extensions built on top of AccessControl to meet the application specificbusiness needs. Alternately, these could bepackaged solutions that can be easilyintegrated with Access Control.

Note that most of these capabilities are generallyprovided off-the-self by a Portal product. ITorganizations will either have to develop andsupport this capability if they do not own a Portalfor developing custom applications.

Portal ServicesThe primary function of the portal services is tomanage the presentation tier of the application. As thepresentation is generally based on entitlements, there isa need to support this capability.

1. Presentation: The objective is to leverage thePortal presentation capability by providing theskins/templates/skeletons/Style sheets etc. for eachof the application teams. This should also includesome sample applications to jumpstart theapplication developing, including leveraging theportal navigation capability, both for verticalnavigation bars as well as horizontal tabs.

2. Personalization: Personalization services, such asportlet layout, background template selection, etc.,are provided by the Portal during this phase.Additional personalization, in context to the

application shall be discussed further in the profilemanagement section of Enterprise Security.

3. Authentication: All Portal products provide thiscapability and the best practices are to externalizethis service. Generally most, if not all, enterpriseshave implemented a global directory services(such as LDAP) within the enterprise. The CustomApplication Framework should provide anauthentication interface and externalize the

service.

4. Single Sign-On (SSO):This enables the enterprseto provide a seamless user experience by notrequiring multiple logins. This Frameworkcomponent should not only support customapplications, is should also support PackagedApplications and Enterprise Services.

Enterprise Infrastructure ServicesThese are services (based on applications) that couldpotentially be leveraged by the entire user community(external and internal). Most enterprise services areinfrastructure components and some of them providethe capability for users to leverage them as anapplication. Following are some examples ofEnterprise Services.

1. Directory Service:This is the standard directoryservices provided enterprise wide and generally

deployed in conjunction with the eMail service.Most of the enterprise implement meta-directoryfor managing identity across the enterprise.

2. Personal Information Management:This is thebasically the standard eMail, Calendar, Addressbook, etc. and includes access to this informationfrom any channel (browser, thick client, mobiledevices, etc.).

3. Collaboration:This provides capabilities such aswhite board, conference calling, instant messaging,discussion forums, news groups, workspace, etc.

4. Enterprise Content Management System:Thisis the infrastructure service for driving customapplications such as Knowledge Management,Asset / Contract Management, Collaboration, etc.

The recommended architecture approach is toleverage the APIs provided by the portal or thecontent management provider. All the contentmanagement system market leaders provide thecapability to develop templates for uploading /authoring content as well as workflow formanaging approval process.

Following are the best practices for implementingthe enterprise content management system:

Define the Taxonomy up front, ideallycreating one that is enterprise wide.

Create a single document base/repository,enterprise wide. This may not be practical, butis a good goal.

Publish all content to one single location inproduction and configure all applications to


9/15

retrieve content from that location (reducesTCO).

A key success factor is end user training forthe authors and the content approvers.

Partner closely with the content managementsystem provider by engaging their Architects

for every project, especially during the designphase of the project.

Leverage the pre-built portlets to author,review and manage the content.

Engage a specialized function person fromeither your SI or Content Management System(CMS) provider to map the business processesto CMS workflow.

5. Search Service: Any user (external or internal)should have the ability to find the information theyare authorized to access. There are two types ofsearch solutions:1. Key Word Search: standard search capability

that most users are accustomed to.2. Natural Language Search: this is generally

targeted towards a non-technical / internetsavvy user who has just been introduced totechnology and want to find information byasking questions using their local language.

The integration of a search engines is straightforward. It is generally an XML / HTTP request tothe search engine and the engine returns the resultsin the order requested.

The search engine goes hand in hand with the

content management system. Following are some

of the best practices based on our experience.

Create one taxonomy enterprise wide for thecontent management system.

Define meta-tags for the content and leveragethem in the Portal to present content to theusers (based on their entitlements).

Use search engines to crawl and createmultiple collections / sub-collections as

required

Leverage federated search between variousbusiness units, if required.

Leverage portal tags and entitlements toprotect secure contents.

Recommend storing secure content at theapplication server level.

One of the major issues potentially encountered bylarge sites is the time taken to crawl the entirecontent repository. There are few alternatives to

help resolve this issue such as creating multiplecollections and including all the collections in thesearch criteria, performing partial crawls on aperiodic basis, setting up multiple search enginesand leveraging federated search, etc. The rightstrategy to be adopted would be based on thebusiness needs. Our recommendation is to developthe architecture and the process in collaborationwith the search solution provider/vendor.

Enterprise (Role-Based) PortalOn implementing the Web Tier Components defined inthis document, enterprises would achieve the CurrentState as illustrated in the diagram below.

Figure 8 -- Enterprise (Role Based) Portal


10/15

In the current state, IT organizations can rapidly deploybusiness solutions in the form of customer applications,Packaged Applications, Enterprise Services acombination of these components. The CustomApplication Framework enables business to provide agreat user experience. However, this has the followingdrawbacks:

Re-Branding the user experience would potentiallyrequire changes to all the sites.

Users still need to know the URLs for each of thesites. By adopting some best practices, this can bereduced but not eliminated.

This model results in redundant hardware andsoftware for each of the point-solutions. This isbecause each of the business units would like toschedule their own maintenance windows and theonly way to facilitate this is to have dedicatedinfrastructure for each of the point solutions.

The Target State is to leverage the concept ofFederated Portals to create an enterprise wide RoleBased Portal. The advantages of this approach are asfollows:

Single point of entry for all employees, customers,partners, etc.

Provide Application (Portlets) access based on therole of the user.

Enable consolidation of infrastructure (bothhardware and software).

Always-ON capability provided by the Enterprise(Role based) Portal.

Simpler re-branding of sites.

Multi-Channel delivery provided by the FederatedPortal by leveraging Services.

Service Tier

The Service Tier is the primary enabler of the SOA andincludes the components described in this section. Itenables integration and business process automationacross the enterprise. This tier is based on the SOAprinciples of coarse-grained, loosely coupled, andstandards-based services. It provides the ability to beresponsive to changing business needs by providingglobal solutions, with reduced application andinfrastructure complexity, increased reuse of businessservices and service orchestration capabilities.

Service BusThe Service Bus is the key component for deliveringthe service-oriented infrastructure for IT agility andalignment with business needs. It should have seamlessintegration with service registry and service

management components which in turn acceleratesconfiguration and deployment management andsimplifies management of shared services across theenterprise.

The Service Bus should be able to receive anysynchronous or asynchronous message in any protocoland route it to the destination based on configurationrules. In addition, it should provide the capability totransform the message to the format required by thedestination. As this controls the message flow betweenthe consumer and the producer, the Service Bus is inthe unique situation to manage, monitor and enforce

the service levels.

Figure 9 Enterprise Service Bus Architecture


11/15

The above diagram represents the Enterprise ServiceBus. The Service Bus basically acts as a dynamicconfigurable Message and Service broker. Followingare the capabilities that define the Service Bus.

Message Brokering between heterogeneousenvironments.

Support Asynchronous, Synchronous, Publishand Subscribe messaging

Support synchronous and asynchronousbridging

Support multiple message formats includingSOAP, SOAP with attachments, XML,structured non-XML data, raw data, text,email with attachment. etc.

Support heterogeneous transports between serviceend points.

Support multiple protocols such as File, FTP,HTTP(s), multiple JMS providers, RMI, WebServices, CORBA, DCOM, eMail (POP,

SMTP, IMAP), SIP, etc. Support message transformation capability whichis required to enable the consumer to talk to theproducer and is not expected to be leveraged as afull fledged transformation engine.

Support configuration-driven routing:

Message routing based policies or call-outs toexternal services to support complex routing.

Support both point-to-point and one-to-manyrouting scenarios to support both request-response and publish-subscribe models.

Provide Monitoring capability:

Service monitoring, logging and auditing with

search capabilities. Capture key statistics for message and

transport attributes include messageinvocations, errors, performance, volume andSLA violations.

Provide High-Availability:

Support clusters and gather statistics acrossthe cluster to review SLA violations.

Simplified service provisioning:

Deploy new versions of services dynamicallythrough configuration.

Migration of configured services andresources between design, staging and

production. Support multiple versions of message

resources that are incrementally deployed withselective service access via flexible routing.

Support configurable policy-driven security:

Support the latest security standards forauthentication, encryption-decryption, anddigital signatures.

Support SSL for HTTP and JMS transports.

Support multiple authentication model.

Policy-Driven SLA enforcement:

Establish SLAs on a variety of attributesincluding throughput times, processingvolumes, success/failure ratios of messagesprocesses, number of errors, security

violations, schema validation issues, etc. Initiate automated alerts or operator-initiated

responses to rule violations via flexiblemechanisms including e-mail notifications,triggered JMS messages, triggered integrationprocesses with a JMS message, Web Servicesinvocations with a JMS message or adminconsole alerts.

Following are some best practices for the Service Bus.

It is good practice to start adopting the Service Buswhenever the number of services is more than 50.One definitely needs a service bus when thenumber of services exceeds 150.

Start small by targeting a single compositeapplications or divisional business process thatspans multiple systems.

Multiple LOB could potentially manage their ownservice bus based on their policies and a ServiceBus at an Enterprise level could act as a broker forsharing services across the various business units.

The functionality described above must beabstracted from the service itself. Organizationsmust make the decision between deploying avendor provided Service Bus and internallydeveloped abstraction layer.

Service RegistrySOA requires services to be coarse-grained, looselycoupled, and standards-based. As services aredeveloped and deployed there must be a catalog ofservices available for architects, developers,operations, business, etc.

Figure 10 Service Registry


12/15

The above diagram illustrates the architecture of theservice registry. The Service Producer publishes theservice to the service registry which is leveraged by theservice consumer for runtime binding. The registry alsoacts as the system-of-record for the predefined businesspolicies which could be used at runtime forenforcement of these policies.

Following are the capabilities that should be providedby the Service Registry:

Core services, including replication, UDDI datastore and security.

Information services, including data validation,SOA mappings, advanced classification, andbusiness data access service.

Lifecycle services, including approval / changemanagement, change notification, business servicediscovery and QoS management.

Configuration web-based business service console.

Platform-independent open architecture,interfacing with leading enablement, managementand security products.

Following are some of the best practices for the ServiceRegistry:

Similar to the Service Bus - start small and growover time.

Every LOB may have its own implementation ofthe Service Registry and should be replicated tothe enterprise service registry.

Provide service browsing capabilities forarchitects, developers and operations so as tofacilitate re-use and identify service dependencies.

As this is the system-of-record for all systems,maintain service contract information along withthe service definition.

Version all services.

Service ManagerAs the SOA implementation matures in an Enterprise,there is a need for an overall service manager. Theprimary function of this service manager is to manage,monitor and report on all the services enterprise wide.Following are some of the capabilities that Servicemanager needs to provide:

Manage and ensure that the Service Level is

maintained enterprise wide Map and maintain service hierarchy across the

enterprise and provide dependency matrix tooperations.

Detect and manage exception conditions.

Review and monitor business transactions, providecapability to review in-flight transactions.

Manage service lifecycle and validate beforedeployment.

Provide non-intrusive service discovery acrossmultiple systems.

Ability to manage and integrate with multipleService Bus and Service Registry infrastructures.

Integrate with existing Monitoring infrastructure.

Shared Data ServiceFor this version of the reference architecture we shallfocus only on the Enterprise Information IntegrationEII capability. EII refers to software systems that cantake data from a variety of internal and external sourcesand in different formats and treat them as a single datasource.

Figure 11 Enterprise Information Integration (EII)

Following are the capabilities that should be providedby EII:

Provide data modeling capability across multiplesources.

Develop query (read and write) to extractinformation from multiple data sources.

Support multiple data sources Database, File,Application Adapter, LDAP, Web Services, etc.

Provide data transformation Capability.

Provide data validation capability.

Expose data services to client applications RMIor Web Services.

Standards based SQL, XQuery, XML, WebServices, JDBC, J 2EE, etc.

Note: Even thought the Service Data Object (SDO)standards have been defined to simplify and unify theway in which applications handle data, the industry hasnot yet clearly defined the standards for EII. Eachvendor has their own extensions that deal with reading,updating and inserting data to each of the data stores.We would collectively prefer to see the vendors,through the standards bodies, agree on one consistentapproach.


13/15

Business Process Management

The BPM is used to manage long-running businessprocesses, both synchronous and Asynchronous. Lightweight service orchestration is usually performed bythe Service Bus. Following are the function / featuresthat should be provided by the BPM.

Visual Process Modeling modify views, businessprocess models, etc.

Built on open standards BPEL a plus.

Business process orchestration and automationbetween private processes, public processes,human tasks, error handling as well as supportingnested and concurrent processes for advancedmodeling and custom logic as required to enablerapid customization.

Optimized process performance: Allows flexibilityof configuration for state-full (long-running) andstateless (short-running) process design patterns aswell as synchronous and asynchronous processexecution.

Status monitoring: Allow the user to monitorstatus of end-to-end processes graphically andmeasure performance vs. service level agreements.

Process instance monitoring: View statistics onrunning processes; drill into individual details;terminate, delete, or suspend problematic processinstances.

Enable end userstask creators, task workers, andtask administratorsto interact with runningbusiness processes for handling processexceptions, approvals, status tracking, etc.

User and Group Management: Centralize theassigning of roles, users, and groups working onintegration projects.

B2B Protocol Support: Enable rapid, secure onlineconnection with suppliers and customers vialeading standard protocols such as RosettaNet,ebXML, and EDI, with secure messaging, digitalsignatures and encryption, recoverable andtrackable messages, and dynamic configurationupdating.

SOA FrameworksSOA Frameworks are re-usable web services that can

scale and be consumed by a wide variety ofapplications form the backbone of the SOA. These re-usable services must be enterprise-class and designedwell enough to scale under load, and meet demands ofa diverse audience of stakeholders.

SOA frameworks catalyze and support the move to anSOA by helping development teams to rapidly design,develop and deploy well-designed, modular, flexible,

scalable and supportable web services, webapplications and portlets. As companies start adoptingSOA principles to transform their IT architecture, itwill be very important for the underlying services to becreated in a consistent, repeatable manner withenterprise qualities in mind

A framework can be defined as a reusable, semi-complete (skeleton) application designed to beextended to build specific services or applications.Frameworks improve and enable consistency in thedelivered software. Frameworks invert the controlbetween themselves and the application or services thatare created on top of them.

Frameworks typically provide a set of higher levelprogramming abstractions and a vastly superior startingpoint for creating enterprise class services. Frameworksalso very often specify a layered architecture forservices that incorporates several design patterns and

software engineering best practices. The architecturespecifies the responsibilities of the components in eachof the layers and the collaboration between them.

Services based on the frameworks inherit the goodarchitecture and best practices that have beenincorporated into the frameworks themselves. Thismakes it possible to ensure that a team of averagedevelopers is able to develop well architected servicesthat take advantage of design patterns and bestpractices.

The typical layers that a services creation framework

would offer include:

Transformation Layer: Supports protocol and data-type conversions to support multiple accessprotocols, while at the same time keeping most, ifnot all, of the service implementation protocol andaccess mechanism agnostic.

Business Logic Layer: Holds all the business logicin the system. This includes such abstractions asRequest, Result, UseCaseController,BusinessPolicy objects etc.

Business Data Layer: The layer for domainobjects, i.e. the objects that have a consistentdefinition across many applications in theenterprise. The Business Data Layer shouldprovide location transparency - that is, the users ofthe domain objects should not be concerned aboutthe exact physical location of the underlyingpersistent data on which the domain object itself isbased. This layer should be able to manage


14/15

persistence to, and retrieval from a multitude ofpersistence repositories in the enterprise.

Integration Layer: A placeholder for a myriad ofconnection technology implementations rangingfrom JDBC, to JNI to Java Connectors. All the

infrastructure code that is needed to accessextended enterprise systems such as ERP systems,content repositories etc. will fit into this layer.

SOA Frameworks offer a number of benefits for bothdevelopers and the corporation. For developers, theframeworks offer the following benefits:

A solid foundation to create services, webapplications and portlets.

Improved productivity as a result of using aframework that incorporates design patterns andbest practices.

Utilize off-the-shelf features of the frameworksand write less code.

Don't need to understand the nuts and bolts ofJ2EE standards and specifications.

Don't need to be an expert at Object-Orienteddesign and design patterns to benefit from usingthem.

For IT organizations and the company as a whole, theSOA Frameworks offer the following benefits:

A catalyst for getting to a Services OrientedArchitecture quickly and at a lower cost.

Consistency of design and development acrossprojects.

Repeatability and the ability to guarantee aminimal level of architecture and design rigor.

Improved business agility as a result of havingmodular solutions that can be changed easily(often via configuration changes).

Use of software engineering best practicesamongst developers with varying skill levels.

More consistent, predictable and better testedsolutions.

Improved mobility of developers to move fromone project to another.

IT organizations are using SOA principles toaggressively create re-usable services that encapsulateand expose key business processes. By combining alayered architecture, ease of use and a deep emphasison good architecture and re-use, SOA frameworksenable the creation of enterprise-class mission-criticalservices in a vendor neutral, portable manner.

Appl ication Tier

This is the Tier where IT organizations have made thelargest investment. Even though enterprises will investin SOA moving forward, this tier is not going to goaway anytime soon.

Legacy ApplicationsThese are the thick client applications still in existencewithin an enterprise. They may the old versions ofpackaged applications that have not yet been upgradeddue to budget / business constraints. Alternately, theseapplications are best suited to run in the client / servermode.

These applications will typically have some publishedAPIs or Logical Models for integration purposes.

Mainframe ApplicationsBusiness solution provided by proprietary mainframe

systems and integrations to these applications are eitherthrough a messaging or database gateways. There is aneffort underway by the mainframe software vendors toexpose all their APIs as Web Services, which in mostcases is not the right approach. In most cases, the bestapproach is to leverage a middleware to develop anabstraction layer and expose the services at the rightlevel as required to support the business requirements.

Enterprise Application IntegrationThis is the traditional approach to enterpriseapplication integrations. EAI middleware softwaretypically provides the following capabilities:

Messaging: Message Oriented Middleware(MOM) with ability for resources to publish andsubscribe to messages.

Business Process Manager: proprietary BPMcapability to automate business processes.

Application Adaptors: Pre-built Connectors tovarious packaged applications that allow access tothe application views or technology adaptors toother technologies like databases, messaging (MQ,

JMS), Web Services, etc.

The best practice for EAI is to leverage an integration

Hub. However this by itself, without the appropriatesupporting methodology, may result in a point-to-pointsolution on the hub. Even though the Services Tierprovides the Service Bus and BPM, which enablesenterprises to move adopt SOA and migrate away fromEAI, this migration is expected to take a long time.Especially as large IT organizations have invested veryheavily in EAI and replacing this capability will take awhile.


15/15

Enterprise SecurityCurrently most of the applications, whether they arepackaged or custom applications, implement their ownsecurity solution. Most of the applications provide theability to externalize their authentication but rely on anexternal implementation which results in redundantcode. In addition, the administrative cost of duplicateuser accounts on multiple applications can be huge.

This could be simplified by breaking the enterprisesecurity into three major components:

Figure 12 Enterprise Security Components

Delegated Admin: User and Resource Administrationapplication that enables administrators (based on theirrole) create/modify/delete user privileges. Thisapplication updates the same repository leveraged bythe Enterprise Security Server.

Enterprise Security Server: Provide security services

such as User Authentication, User IdentityManagement, Authorization, Auditing, User ProfileManagement and User provisioning.

Identity Management involves managing useridentities within and across multiple applicationsof an enterprise. Mapping of multiple identities toa single user or linking a user identity in oneapplication with a different identity of the sameuser in another application allows multiple legacyuser identities to co-exist.

Authentication involves validating the identity of auser. Several authentication mechanisms may be

used in an enterprise with the most common onebeing validating against a password. Othermechanisms may involve digital certificates, smartcards etc. Enterprise-wide policies can beinstituted to ensure that users present conclusiveproof of identity before being provided access toresources. From a convenience and usabilityperspective, users may need to be able to sign ononce and gain access to multiple resources.However, this also increases the need to add

proper controls and policies to ensure that onceauthenticated a user doesnt gain access toresources that he/she should not have access to.

Authorization involves controlling access of usersto diverse resources across the enterprise.

Auditing involves tracking user activities.

Profile Management involves managing theprofiles of the users.

Provisioning automates the tedious and time-consuming process of managing accounts and theirlife cycle. It allows centralized activation,modification or deactivation of accounts acrossmultiple applications in an enterprise. In anenterprise, user provisioning could include explicitgranting or revoking of user access to resourcesand establishing of entitlement policies for theuser.

Clint Applications: The client applications externalizeand leverage the enterprise security services.

Addi tional Informat ion

AcknowledgementsThe authors would like to acknowledge the manyorganizations and individuals that contributed portionsof this document, performed substantial editing of thecontent, or who provided reviews and feedback.Specifically, we would like to acknowledge:

Erik Dahl, SVP Lead Integration Architect, Bank ofAmericaRobert Eisenberg, Principal, REA AssociatesAshok Kumar, Manager, SOA Architecture, CarRental Group

J effery Lamb, Enterprise Architect, Wells FargoTom Mitchell,Lead Technical Architect, Wells Fargo Private Client ServicesBurc Oral, Principal, Dev Atma Technologies, Inc.

Yogish Pai, Chief Architect, AuqaLogic Composer &Chair SOA Blueprint working groups

J ohn Schmidt, SVP Architecture/Engineering, Bankof AmericaSankar Ram Sundaresan, Chief Architect, e-BusinessIT, Hewelett-Packard Company

Copyright

Copyright 2006.

The authors grant a non-exclusive licence to the IntegrationConsortium to publish this document in full on the World WideWeb (prime sites and mirrors) and in printed form. Any otherusage is prohibited without the express permission of theauthors.

SOA Architecture

Documents

Transcript of SOA Architecture