SOA BLUEPRINT – REFERENCE ARCHITECTURE

  • 777 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
777
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
44
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SOA BLUEPRINT – REFERENCE ARCHITECTURE VERSION 1.1 SOA Alliance 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 Keywords 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
  • 2. SOA Foundation The SOA Foundation components are illustrated in the figure below. Figure 2 – Enterprise SOA Maturity Model The above diagram illustrated the enterprise SOA maturity model which can be classified into following stages. • 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.
  • 3. 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,
  • 4. 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 WSRP. capability. • 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 LDAP). 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 deployed. 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
  • 5. 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 environment. capabilities. • 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 functionality. application. 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 Objects. 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
  • 6. 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. Components. 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 interpretation 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
  • 7. • Search results required in standards such as java.util.List • Queries reside on external files • Utilities to handle common UI tasks • Pagination • 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 Framework: • 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 basic requirements. • Identity Management – Typically in a large organization, there are multiple stores for managing the access control information for a
  • 8. 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
  • 9. 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
  • 10. 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 follows: enterprise. • 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
  • 11. 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. search capabilities. • 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 through configuration. • Migration of configured services and resources between design, staging and production. • 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 digital signatures. • Support SSL for HTTP and JMS transports. Figure 10 – Service Registry
  • 12. 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 Registry: • Similar to the Service Bus - start small and grow over time. • 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 operations. 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 deployment. approach.
  • 13. 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 updating. Request, Result, UseCaseController, BusinessPolicy objects etc. SOA Frameworks 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
  • 14. 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 mode. • 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 projects. • 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, solutions. 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 while.
  • 15. Enterprise Security proper controls and policies to ensure that once Currently most of the applications, whether they are authenticated a user doesn’t gain access to packaged or custom applications, implement their own resources that he/she should not have access to. security solution. Most of the applications provide the • Authorization involves controlling access of users ability to externalize their authentication but rely on an to diverse resources across the enterprise. external implementation which results in redundant • Auditing involves tracking user activities. code. In addition, the administrative cost of duplicate • Profile Management involves managing the user accounts on multiple applications can be huge. profiles of the users. • Provisioning automates the tedious and time- This could be simplified by breaking the enterprise consuming process of managing accounts and their security into three major components: life cycle. It allows centralized activation, modification or deactivation of accounts across multiple applications in an enterprise. In an enterprise, user provisioning could include explicit granting or revoking of user access to resources and establishing of entitlement policies for the user. Clint Applications: The client applications externalize and leverage the enterprise security services. Additional Information Figure 12 – Enterprise Security Components Acknowledgements The authors would like to acknowledge the many Delegated Admin: User and Resource Administration organizations and individuals that contributed portions application that enables administrators (based on their of this document, performed substantial editing of the role) create/modify/delete user privileges. This content, or who provided reviews and feedback. application updates the same repository leveraged by Specifically, we would like to acknowledge: the Enterprise Security Server. Erik Dahl, SVP Lead Integration Architect, Bank of Enterprise Security Server: Provide security services America such as User Authentication, User Identity Robert Eisenberg, Principal, REA Associates Management, Authorization, Auditing, User Profile Ashok Kumar, Manager, SOA Architecture, Car Management and User provisioning. Rental Group Jeffery Lamb, Enterprise Architect, Wells Fargo • Identity Management involves managing user Tom Mitchell, Lead Technical Architect, Wells Fargo identities within and across multiple applications – Private Client Services of an enterprise. Mapping of multiple identities to Burc Oral, Principal, Dev Atma Technologies, Inc. a single user or linking a user identity in one Yogish Pai, Chief Architect, AuqaLogic Composer & application with a different identity of the same Chair – SOA Blueprint working groups user in another application allows multiple legacy John Schmidt, SVP Architecture/Engineering, Bank user identities to co-exist. of America • Authentication involves validating the identity of a Sankar Ram Sundaresan, Chief Architect, e-Business user. Several authentication mechanisms may be IT, Hewelett-Packard Company used in an enterprise with the most common one being validating against a password. Other Copyright mechanisms may involve digital certificates, smart cards etc. Enterprise-wide policies can be Copyright © 2006. instituted to ensure that users present conclusive The authors grant a non-exclusive licence to the Integration proof of identity before being provided access to Consortium to publish this document in full on the World Wide resources. From a convenience and usability Web (prime sites and mirrors) and in printed form. Any other perspective, users may need to be able to sign on usage is prohibited without the express permission of the once and gain access to multiple resources. authors. However, this also increases the need to add