前言 Introduction

目的 Objective

面向服務的體系結構(SOA)的目標是以一種更機敏的方式在組織的業務需求中實現資產的可重復使用。
 

SOA參考體系結構為建筑學提供了體系結構和決策指南。在組織內的不同群體中，為建筑體系構架創建或評估其解決方案。此外,SOA的不同圖層解釋了集成SOA的不同元素，并為其提供洞察力和模式分析。
 

SOA參考架構的目的是回答一些關鍵難題和工作中遇到的相關問題,如:開發解決方案

什么是SOA的圖層？需要考慮在設計解決方案考慮SOA原則?

建筑模塊是什么？需要包括在每一個層的解決方案中嗎?

在實行哪些關鍵架構決策時,需要設計一個基于SOA的解決方案?

哪些項目在使用這些原則和指導方針的時候將受益?
 

為了回答這些問題本文提供了以下建議:

建立一個公共的詞匯表，設置相關服務項目，精確SOA的定義。

標識SOA實現的不同功能和定義，及與魯弗斯的體系結構彼此交互的功能范圍。

SOA提供了指導原則。

服務定義設計和實現的一致性。

使用SOA技術顯示的時間和地點。

支持SOA治理。

提供了基于體系結構的設計方法。

 

The goal of a Service Oriented Architecture (SOA) is to achieve reusable assets in an agile manner that is aligned with the business needs of the organization.
 

The SOA Reference Architecture provides guidelines for making architectural and implementation decisions. To that end it serves as a blueprint for creating or evaluating a solution architecture for different groups within the organization. In addition it provides insight and patterns for integrating the different elements of an SOA as illustrated by the different layers of an SOA.
 

An SOA Reference Architecture is designed to answer some of the key questions and issues encountered while developing a solution such as:

What are the aspects of an SOA as expressed in terms o layers that need to be considered when designing solutions based on SOA principles?

What are the building blocks needed to include in each layer of a solution?

What are some of the key architectural decisions that need to be made when designing a a solution that is based on SOA?

Which roles in a project would benefit from using these principles and guidelines?
 

To answer these questions this document provides the following:

Establishes a common vocabulary and set of definitions for services and SOA.

Identifies the different functions of an SOA implementation and define their interactions with each other and with functions outside the scope of the Rufus architecture.#p#分頁標題#e#

Provides SOA guiding principles.

Defines consistent design and implementation across services.

Shows when and where to use SOA technologies.

Supports SOA governance.

Provides an architectural based design methodology.
 

Overview

This document presents the layers, building blocks, architectural and design decisions, patterns, options and the separation of concerns needed to design or evaluate an SOA architecture.

The architecture is consists of multiple components which are divided into the following categories:

Quality of Service (QoS)

Security

Consumer

Business Process

Integration

Services

Information

Infrastructure

Governance

Monitoring & Management

Center of Excellence (COE)

Design Time Elements

Component View

Design Time Elements
 

Design-Time Activities are the technical activities, guidelines, and deliverables that allow for everyday development within the SOA and Integration Architecture. Including:

Service Modeling and Design

Canonical Data Modeling

Policy Specification

Service Assembly

Service Testing

Service Identification

Service Lifecycle Management

Service Modeling and Design
 

Services must be modeled and designed to support an extensible plug-and-play model by being:

Reusable - So that other Services leverage an existing Service.

Composable - So that a Service can leverage other Services.

Interoperable - So that Services can work with each other.

Discoverable - To support location independence.
 

To enable the above qualities, each Service (except for Data and Utility Services) needs to have:

A well-defined Service Contract - To enable loose couple by hiding low-level implementation details from Service Consumers. SOAP-based Web Services achieve this by specifying a WSDL interface with XML-based document exchange. RESTful Web Services define a contract with HTTP input parameters and JSON/XML-based responses.

Coarse-grained - So that operations have enough data to carry out all tasks in a stateless manner.

Stateless operations - Statelessness (i.e., not maintaining state between invocations) enables a Service to be reused in many contexts.

A way to handle Exceptions to notify its caller if there are problems carrying out an operation.

To ensure that each type of Shared Service is designed and implemented in a uniform manner, a SOA Governance team should create SOA Best Practices documents for: Service Design, Web Service Design, and XML Message Design in Designer's Guides (i.e., working agreements). Topics would include:

Service Specification and Design

Interface (including Canonical Data model for messages - see section 3.5.2)#p#分頁標題#e#

Policies (see section 3.5.3)

SLAs (Service - Level Agreements)

A description of what the Service does

A description of the Service's operations.

Best practices for each type of Shared Service (Business, Common, Data, Integration, and Utility).

Examples showing the difference between Service-Oriented Design and Object Oriented Design.

How to develop a SOAP Web Service (and handle Exceptions).

How to develop a RESTful Web Service (and handle Exceptions).
 

Canonical Data Modeling (XML)

Many organizations have several autonomous packaged and custom developments that have evolved independently of one another. Many times, each system has become a system with its own implementation methodology, culture, processes, business rules, and vocabulary. Many companies face the problem of using the business data to enable applications to communicate in a distributed systems environment.
 

Organizations design Canonical Data Models (CDM) to help analyze the message exchange within the organization and with their trading partners. Data is embedded in the basic architecture of any organization. To develop the CDM, an organization must inventory business concepts and map the vocabulary into fundamental business concepts. The CDM provides a framework for integrating the disparate terms for each line of business. The CDM is a catalog of neutral terms defined in an XML Schema, including:

Entities in the business domain (e.g., Order, Customer, etc.)

Agreed-upon data structures - so that a domain element has a single, common definition.

Formatting rules.

A CDM defines an organization's data in motion - the XML messages exchanged between:

Services within an enterprise.

An enterprise and its external trading partners. Many industries have an industry standard (e.g., ACORD, for Insurance, or EDRM for e-Discovery) to define core concepts and define data exchanged between companies.

A Canonical Data Model provides the following benefits:

An enterprise can easily exchange data with its business partners.

An enterprise can adopt a single approach to exchanging data across all services the enterprise.

The canonical model helps define the interface for each Service (thus hiding the structure of the physical data in the database).

Changes to the canonical data model are required only when an entirely new business concept arises.
 

Policy Specification

Policies provide service-level meta-data to Web Services consumers. Specifying these policies is an important step in Web Service design, and this is accomplished by attaching policy expressions to the WSDL. Specifically, these policies include:

Security:

Transport Protocol

Algorithm (RSA, etc.).

Messages

Authentication/Authorization#p#分頁標題#e#

Level of Service (e.g., Silver, Gold, Platinum, etc.). For example, a Platinum customer's requests execute on best-provisioned server for better performance (but also at a higher price).

Performance - For example, send notifications if performance for a particular service dips below the promised SLA.

Auditing - For example, begin auditing when a particular service consumer invokes an operation on a Service.
 

Service Assembly

A Business Analyst first develops a Business Process Diagram (using BPMN - Business Process Modeling Notation) to model a business process at a business/requirements level. Then, designers and developers create a runtime model in either BPEL (Business Process Execution Language) or JBI (Java Business Integration) to:

Assemble existing Shared Services into a Business Process

Enable a BPMS product and/or ESB can run the business process.

Designers use MEPs (Message-Exchange Patterns) to model the runtime characteristics of a business process. Typical MEPs include:

Pipes and Filters

Content-based Router

Recipient List

Wire Tap

Dynamic Router

These patterns are gaining in popularity and many of the newer ESB and BPMS products support executable MEP models. Please see the following for further information:

Enterprise Integration Patterns Home Page

Enterprise Integration Patterns, Gregor Hohpe, Bobby Woolf, et al.
 

Service Testing

Most Shared Services will be implemented as Web Services, and it is important to take a Test-Driven Development (TDD) approach to Web Services development because:

Designers and developers need early feedback on the design, functionality, usability, and performance of each Web Service.

QA personnel need to be able to test Web Services.

Overall quality is very important because each Web Service could be used by multiple consumers.
 

Service Testing includes:

Inspecting Web Services:

Documentation - Generating HTML documentation from the Web Service interface.

Debugging - Show SOAP/HTTP requests that are sent & received over the wire.
 

Invoking Web Services:

Generating Web Services requests from WSDL to set the Web Service.

Simulating/Mocking Web Services

Generating Unit Tests based on the Web Service interface.

Functional/Performance Testing Web Services

Simulating load conditions.

Reporting on performance under load conditions.

Commercial products include:

Eviware soapUI Pro

iTKO LISA

Open Source products include:

Eviware soapUI Community Edition

WebInject

PushToTest TestMaker

Points to Ponder (for Evaluation)
 #p#分頁標題#e#

Does the product support both SOAP and RESTful Web Services? How?

Does the product enable you to view SOAP/HTTP messages over the wire?

Does the product have a good/usable Web UI to make it easy to test?

Can a QA/Tester use the product without developer intervention?

What level of SOAP, WSDL, and HTTP does the product support?

Does the product support an Agile/TDD approach with Unit Tests and Mocking?

Does the product generate Unit Tests to support Continuous Integration?

Can the product simulate load conditions and report on performance/scalability?

How much setup is involved?

How does the licensing work?
 

Service Identification

Service Identification is one of the key steps in designing a Service-Oriented solution because it defines and identifies high-level Business Services by using the following the following approaches:
 

Top Down:

Analyze and model business processes.

Design new Services that enable the tasks and activities in the business processes.
 

Bottom Up:

Service-enable existing and applications systems.

Create business processes from the Services.
 

Middle Out:

Analyze and model business processes.

Catalog existing applications and services.

Determine which can be Service-enabled.

Create Service Adapters.

Map tasks and activities from the business processes to existing Services.

Create new Services to fill in the gaps.

A Middle-out approach is recommend because it takes the best parts of the other approaches:

The bottom-up approach creates isolated silos that don't align with the business.

The top-down approach takes a long time, and the enterprise can't wait for every business process to be defined in order to begin designing and developing Services.
 

A compromise approach takes into account the need for timeliness, but also instills enough discipline to design Business Services that match up with the goals and objectives from the Business Architecture by:

Taking a first cut at the Business Services from Marketing materials and meetings with the CMO and other business stakeholders.

Starting with only a few Business Processes.

Driving toward a thin/vertical slice of functionality based on the business processes.

Service Lifecycle Management
 

Service implementations are software like any other software module or application. As such, they go through a similar lifecycle. The service lifecycle is depicted in the following diagram.
 

The lifecycle starts with Service Identification. Services are part of more general business processes. As such, new services are usually identified by the design of a new business process. This is not the only way that new services are identified however. Sometimes services are identified as part of portfolio management. This involves analyzing the requirements for a service across the breadth of the enterprise. The level of analysis required for this type of identification is difficult to gauge and therefore CIBER does not recommend using portfolio management for service discovery at this time.#p#分頁標題#e#
 

Once a service has been identified, it follows an iterative development process. Iterative processes use the feedback from subsequent phases to make corrections in previous phases based on lesson learned or issues that may crop up. Services are part of a greater distributed system however and any changes made can have an impact on other development efforts. Therefore it is important to be mindful of the effect change can have even during development of a service.
 

The Service Specification and Design phase produces at a minimum the specification for the service interface. This interface specification includes the semantics and data that the service supports. This represents the contract between the service and its consumers. Diligence should be applied to the design of this interface as changes to the interface have the greatest impact to subsequent phases. Changes to the service interface can impact both clients that may be developed in parallel, implementation of the service, as well as test plans that have been implemented to test the service. This does not mean that a service interface must never be changed once it is designed. Designs are not perfect and in today's IT environment it is not always possible to take the time required to produce an interface definition that is ideal. Therefore it is prudent to put processes in place that take into account that service interfaces may change. Whenever implementing a service take into account that the interface may change to the extent possible to minimize the impact of that change. This also applies to the implementers of consumers of the service. In some cases, consumers may want to wait until the service has been through some number of rounds of testing before starting their implementation. This allows for some experience to be developed with using the service thereby (hopefully) minimizing the possibility of change to the interface.
 

Once the service has been designed it proceeds to the Service Implementation phase. In this phase the service will be developed based upon architectural standards developed by the university OIT group. Any issues encountered trying to implement the design of the service should be fed back to the designer in order to refine the design if necessary.
 

Finally, service need to be tested before being deployed into production use. Testing of services involves four primary areas of focus:

Security testing is essential to assess the risk of a service with regard to vulnerability, data privacy and data integrity. Tests need to be developed to test boundary conditions which can assess the robustness of the service handling inputs outside the range of anticipated values. Tests should also be created that ensure the service performs as expected based on the roles as defined within the system.
 

Type of Testing

Description

Functional

#p#分頁標題#e#

This area of testing focuses on ensuring the service performs its function according to the requirement of the business process it support. Automated test suites should be developed to perform regression testing to quickly verify functionality during the life cycle changes that may occur.
 

Performance

This area of testing focuses on performance characteristics of the service including measurement of time to perform the service and load testing of the service. The output from this type of testing forms the basis of understanding how to configure and deploy the service in a production environment.
 

Interoperability

This area of testing ensures the service adheres to its service specification. Early identification of interoperability issues is key to integration of the service through exposure to university partners and clients. This type of testing is especially important when the service interacts with multiple data sources and/or systems.
 

Security

Security testing is essential to assess the risk of a service with regard to vulnerability, data privacy and data integrity. Tests need to be developed to test boundary conditions which can assess the robustness of the service handling inputs outside the range of anticipated values. Tests should also be created that ensure the service performs as expected based on the roles as defined within the system.
 

Regression

One of the more important types of testing related to usage of services is regression testing. The more applications that depend on a given service, the more impact a change to that service can have on the environment. As such, when changes are made to services, regression testing must be undertaken to ensure that the service not only supports new or updated functions but all other functions upon which the service relies.
 

Table 1 Service Testing Types

Once the service is ready it is deployed into production use. At this point the service enters the maintenance cycle as opposed to the development cycle. Services in production sometimes require change. The change may be due to a defect in the system or a request to add more functionality to the service. It is important to understand how this change should be handled based on its nature.
 

Defects that are a result of a fault in the underlying implementation of the service and do not change the behavior of the service may be handled by a Defect Remediation process. In this case it is desirable to apply a fix as quickly as possible to the existing service as it may be affecting multiple university processes and causing a disruption to the universities ability to perform its function.
 

Changes that modify the behavior of an existing service or its interface are best handled by identifying a new service or a separate version of the service. In this scenario versions are really new services that are separate from the original. Taking this route minimizes impact on consumers using the original service but can cause a proliferation of services within the enterprise. This may not always be desirable however and some effort should be put into defining conditions under which an existing service in production may be modified (for instance, only one business consumer is affected and the change is well understood). This should be documented so that everyone understands the conditions and ensure that changes are handled in a consistent manner.#p#分頁標題#e#
 

Service Withdrawal is the final step of the lifecycle. Eventually services will start ballooning (especially when changing production services leads to the creation of new services) and some services will stop being used. Removing service can be problematic as a service may support multiple business process owned by different colleges and departments. A procedure needs to be adopted to define and orderly withdrawal of services from the system. Such a procedure may start with deprecating the service (with a note explaining why and some suggestion as to another service to replace it). Secondly, services can be monitored for use and the consumers identified. Finally, if the service is still being used the consumers should be contacted to discuss a solution. This should result in establishing a schedule for the consumers to switch over to another service so that the service may be withdrawn.
 

Consumers of a deprecated service may not have incentive to change. Making changes requires effort and possibly some risk to the consumer. This needs to be recognized when seeking collaboration from consumers to switch over to another service. In this case it will be necessary to be creative in coming up with a common understanding of the benefit of switching to a newer service so the deprecated one may be withdrawn.
 

Center of Excellence (COE)

An online community to:

Impart the SOA Vision.

Educate IT and business staff on SOA.

Communicate SOA best practices.

Gain feedback on how to adapt the SOA Governance process and overall SOA program.

Provide support advice for new and ongoing SOA implementations.
 

Provide SOA Resources:

Books

Web Sites

Industry Standards

Quality of Service

Logging
 

Most applications and systems use some form of logging that stores messages to a persistent medium (DBMS, file, etc.). Logging provides the following benefits:

Troubleshooting - Applications log errors upon failure, and system personnel use this information to repair the problem.

Reviewing - System personnel examine log messages to check for problems.

Auditing - Security personnel can review log messages to see what actions a user performed in the system.

Debugging - Developers generate log messages to debug their programs.
 

Identity Management

Identity Management is the ability to identify a requestor's (person or system) true identity and relationships between people and organizations (groups). The current policies and level of enforcement are expected to continue into Managed Services by using Microsoft's Active Directory as the source for identity management.
 

Confidentiality

Confidentiality assures that during transport of the data it was never visible, accessible or viewed other than by authorized recipients.#p#分頁標題#e#
 

There currently is no Smart Energy or Smart Grid requirement to secure messages for Confidentiality.
 

Authentication

Authentication is also done within Microsoft's Active Directory and adds authorization policies to the verified identity.
 

Authorization

Authorization is currently done at the application level. Within Managed Services (stage MS3) authorization will be performed to determine whether the requestor (person, application, service) is authorized to access the requested service, data and even the Managed Data Repository.
 

Integrity / Non-repudiation

Integrity requires that during transport and even as read by the sender there were no unauthorized modifications of the content of the message.
 

Non-repudiation assures the sending service that the receiving service has received the intended message. Current Smart Energy and Smart Grid projected needs do not require message Integrity, but for sensitive messages (time, confidentiality, event, or priority) there is Non-repudiation.
 

Consumers

Service Consumers are the end consumer/user of the services provided by an enterprise. The consumer has the flexibility to process and display useful and relevant information provided by Services. Service Consumers access Services through a consistent interface (or contract) exposed by that Service. Service Consumers can be:

User Interfaces

B2B Applications

Business Processes

User Interaction
 

Users can access enterprise services through variety of mechanisms, including Portals, web sites, or PDAs. A web site provides a web-based interface to enable users to perform daily, job-related tasks. A web site leverage the services created provided the organization, as a part of SOA implementation, and do not contain any business logic themselves. The site seamlessly integrates with back-end services (using SOAP/WSDL, REST/JSON) and business processes. The site can be secured by global security policies, but also can include role based authentication that limits access to only relevant information making it easier to manage.
 

A Portal is a web site that enables users to access highly personalized information and services. It can increase the productivity and effectiveness of employees within an organization through a consolidated view of available services and information. Typically the site is highly interactive, allowing the user to run a wide variety of tools and functions such as, global search queries, and custom dashboard and advanced business intelligence tools. Portals provide a unified entry point to the organization and provide common look and feel all across applications. Portals form the front end for business processes and custom applications created as composite applications. The site can also be utilized to "mash-up" other applications or services from 3rd party sites. Wikis, Blogs, RSS feeds, and content can all be made available within the site.#p#分頁標題#e#
 

A PDA enables mobile users to access enterprise services. Like sites and portals, a PDA has no business logic of its own, but it allows the end user to interact with back-end services by seamlessly accessing the Web Services exposed by an enterprise. However, a PDA's interface and functionality is much more limited than that of a web site because of display and memory constraints.
 

B2B Applications

An organization normally collaborates with external business partners such as suppliers and customers to achieve its business objectives. An external partner's B2B application (e.g., a web site or portal) will invoke a Web Service exposed by an enterprise, which in turn executes business functionality on behalf of the client.
 

Business Processes

A Business Process codifies and streamlines the rules, practices, and business s activities in an enterprise. Business analysts create Business Process Diagrams using the industry-standard Business Process Modeling Notation (BPMN) to document a set of coordinated tasks and activities that lead to an organizational goal. You can think of a business process as a graphical representation of a Use Case (RUP) or User Epic (Agile / Scrum) in that it shows normal and alternate flows along with exceptions encountered during processing. In SOA, a business process coordinates the business services (see section 3.2.1) developed by an enterprise. SOA architects and developers derive business services from the tasks and decision points in a business process diagram.
 

Business logic is used to form business flows as parallel tasks or sequential tasks based on business rules, policies, and other business requirements.

Examples of Business Processes include:

Purchasing a product

Time Entry / Approval

Billing

Service Provisioning

For information on tools and products, please the Workflow / Orchestration section (3.4.5).

Collaboration Services

Presentation Services
 

Presentation Services define a common set of services to manage interaction with users or trading partners (to the extent this second interaction is needed). Presentation services are provided by: web servers, portal servers, and application servers that provide the capability to quickly create the front end of business processes and composite applications to respond to changes in user needs through channels, portals, rich clients, and other mechanisms. Presentation services integrate with other foundational services, such as security (e.g., single sign-on).
 

Users can access enterprise services through variety of mechanisms, including Portals, web sites, or PDAs. A web site provides a web-based interface to enable users to perform daily, job-related tasks. A web site leverage the services created provided the organization, as a part of SOA implementation, and do not contain any business logic themselves. The site seamlessly integrates with back-end services (using SOAP/WSDL, REST/JSON) and business processes. The site can be secured by global security policies, but also can include role based authentication that limits access to only relevant information making it easier to manage.#p#分頁標題#e#
 

A Portal is a web site that enables users to access highly personalized information and services. It can increase the productivity and effectiveness of employees within an organization through a consolidated view of available services and information. Typically the site is highly interactive, allowing the user to run a wide variety of tools and functions such as, global search queries, and custom dashboard and advanced business intelligence tools. Portals provide a unified entry point to the organization and provide common look and feel all across applications. Portals form the front end for business processes and custom applications created as composite applications. The site can also be utilized to "mash-up" other applications or services from 3rd party sites. Wikis, Blogs, RSS feeds, and content can all be made available within the site.
 

A PDA enables mobile users to access enterprise services. Like sites and portals, a PDA has no business logic of its own, but it allows the end user to interact with back-end services by seamlessly accessing the Web Services exposed by an enterprise. However, a PDA's interface and functionality is much more limited than that of a web site because of display and memory constraints.
 

BI / Reporting

BI (Business Intelligence) / Reporting provides a high-level view of KPIs (Key Performance Indicators) to business stakeholders to enable them to make decisions and manage the business. Examples of KPIs include:

Efficiency of business processes.

Job Costing.

New customers acquired.

Sales information by demographic (age, ethnicity, geographic region, etc.).

Churn / turnover of accounts by demographic.
 

A BI product uses the information stored in a Data Warehouse to present it to the user. A BI tool (such as Business Objects) uses Key Performance Indicators (KPIs - e.g., sales conversion rate, in-force polices, market penetration, for example) to report on data, identify trends, perform data analysis, etc. to enable business users to make decisions and operate the business as efficiently as possible while advancing a business strategy.
 

BI increases business agility and shortens timeframes for decision-making. It gives companies the ability to identify and anticipate opportunities represented by seemingly unrelated events. It is a key enabler of strategic and tactical decision making.
 

Commercial products include:

IBM COGNOS

MicroStrategy

Open Source products include:

Pentaho BI Suite

JasperSoft Business Intelligence

Eclipse BIRT

Business Process

Business Process Management System (BPMS)

A Business Process Management System (or Suite) usually includes the following:

A business process modeler that supports the BPMN notation.#p#分頁標題#e#

IDE support for Service Assembly that supports the BPEL or JBI standard. This should integrate with Eclipse, NetBeans, IntelliJ, and MS Visual Studio (among others).

A runtime for service orchestration that supports BPEL or JBI (please see the Service Assembly section - 3.5.4).

A tool for Business Activity Monitoring (BAM - see the BAM section 3.4.6).
 

Commercial BPMS products include (but are not limited to):

Oracle BPM

IBM Business Process Management

TIBCO iProcess

Cordys Process Factory

Open Source BPMS products include (but are not limited to):

Intalio|BPP

JBoss jBPM

wfMOpen

ObjectWeb Bonita

OSWorkflow

ProcessMaker BPM Suite

Points to Ponder (for Evaluation)

Are there any BPMS products that aren't trying to do everything (e.g., UI) and fit in as a Service in an SOA?

Where in the various workflows would we need to use a BPMS product?

Can a BPMS product do prioritization of processes? What does the Business need?

Can a BPMS product handle dynamic workflows? What does the Business need?

Since many ESBs provide workflow capabilities, do we need a separate BPMS product or do we only need an ESB?

Since BPMS products claim to provide orchestration, do we need a separate ESB or do we only need a BPMS product?

Does the BPMS product support Business Activity Monitoring (BAM)? If not, is there a separate BAM product that we could use as a front-end?

Can you invoke the BPMS product with a Web Service (SOAP/XML) call?

Can the BPMS product invoke our Shared Services with a Web Service (SOAP/XML) call?

What versions of SOAP, WSDL, UDDI, WS-I Basic Profile, and WS-Security does the BPMS product support?

What other WS-* standards does the BPMS product support?

What other transport protocols and messaging formats are available with the BPMS product?

What kinds of adapters (HTTP, FTP, etc.) are available with the BPMS product?

What kind of security does the BPMS product support?

How scalable is the BPMS product?

Does the BPMS product have Fault Tolerance, Load Balancing, and Federation capabilities?

What's the runtime environment (JavaEE, .Net, etc.) for the BPMS product?

What type of management / monitoring is available for the BPMS product?

Does the BPMS product have its own embedded Service Registry?

If so, the does the Registry support UDDI?

Could the BPMS product integrate with an external Service Registry?

Does the BPMS product supply a task inbox UI?

Does the BPMS product support testing or simulating workflows?

Business Rules Management System (BRMS)
 

A Business Rules Engine warehouse is a software system that executes one or more business rules in a runtime production environment. Such rules might come from legal regulation, company policies or other sources.#p#分頁標題#e#
 

Business rules change more frequently than other application code. Rules engines are pluggable software components that execute business rules that are externalized from application code. This allows business users to modify the rules without developer intervention.
 

Business Activity Management (BAM)

A Business Activity can either be a business process that is orchestrated by Business Process Management (BPM) software, an ESB, or a business process that is a series of activities spanning multiple systems and applications. BAM is an enterprise solution primarily intended to provide a real-time summary of business activities to operations managers and upper management.
 

One of the most visible features of BAM solutions is the presentation of information on dashboards that contain key performance indicators (KPIs) used to provide assurance and visibility of activity and performance. This information is used by Technical and Business Operations to provide visibility, measurement, and assurance of key business activities. It is also exploited by Event Correlation to detect and warn of impending problems.
 

Although BAM systems usually use a computer dashboard display to present data, BAM is distinct from the dashboards used by Business Intelligence (BI) in so far as events are processed in real-time and pushed to the dashboard in BAM systems, whereas BI dashboards refresh at predetermined intervals by polling or querying databases. Depending on the refresh interval selected, BAM and BI dashboards can be similar or vary widely.
 

Commercial products include (but are not limited to):

Oracle Business Activity Monitoring

TIBCO Business Activity Monitoring

Open Source products include (but are not limited to):

Intalio|BAM

BizSensors' Gourangi

Mule Saturn

JBoss jBpmBAM
 

Please note that the Open Source BAM products mentioned above are still in their infancy. For now, one of the Open Source BI products (see section 3.4.12) such as Pentaho or JasperSoft may be a better option until the Open Source BAM market matures. 2.6.3.1 Points to Ponder (for Evaluation)
 

When evaluating business activity monitoring product alternatives, focus on the features that distribute alerts and display business indicators, the analytic engine that generates the information and the mechanisms to collect business events - For further details, please see http://01ec032.netsolhost.com/lit/BAM-selection_requirements.pdf.
 

Does the BAM solution offer a visually intuitive dashboard that updates in real time and can be personalized
 

Does the BAM solution offer delivery of alerts in multiple formats ? e-mail, instant message, icon-tray, Short Message Service (SMS) or pager ? with support of Extensible Markup Language (XML) formatting#p#分頁標題#e#
 

Does the BAM solution offer user-controlled filtering and reporting of alerts, and setting the scope of what is monitored
 

Is it scalable?

Persistent to maintain context across application restarts?

Does the BAM solution offer a library of analytic functions, such as static and dynamic thresholds, absolute values, duration, coincidence, frequency, statistical balance and rate of change

Does the Business know that this type of functionality is available?

Does the Business really need this type of functionality?

If this causes us to use a COTs product rather than Open Source, is the Business willing to pay for it (i.e., is this a deal-breaker)?

Complex Event Processing (CEP)
 

Governance

SOA Governance is about setting and implementing policies and procedures to control the service lifecycle (see the Service Lifecycle Management section -SOA Governance includes:

Design-Time Governance - Provides standards and best practices for Service Design (see the Service Design Activities section - 3.5), Web Service Design, and Canonical Data Modeling (see the Canonical Data Modeling (XML) section - 3.5.2).
 

This also includes Design and Code Reviews to determine if architects, designers, and developers are following standards to ensure a uniform design and implementation across all Shared Services.
 

Runtime Governance - Enforces policies (see the Policy Specification section - 3.5.3), Security, QoS (Quality of Service), and SLAs (Service Level Agreements) at runtime. For a list of Service Manager and Service Registry products to support SOA Governance, please see the Service Management (3.4.2) and Service Registry / Repository (3.4.1) sections.
 

Service Registry/Repository

A Service Registry/Repository manages service descriptions and artifacts throughout the complete lifecycle of a Service, and is used to find, publish, manage and (enable consumers to) subscribe to services. The Service Registry/Repository decouples service consumers and service providers.
 

The Service Repository/Registry is a component that stores & manages metadata for a service throughout its lifecycle. Stakeholders can add and maintain service models and associated information. The meta-data enables consumers to search for services to satisfy a particular need, and obtain models and associated information concerning those services. Service Registry is a runtime catalog of services intended to be used by consumer services. The service provider publishes its capabilities to the registry. In order to use these capabilities, service consumers discover service capabilities and bind to them. Most Service Registries use UDDI (Universal Description Discovery and Integration - an XML-based standard) to specify the binding between a service name and its location.#p#分頁標題#e#
 

Functionality includes:

Registry services

Deployed endpoints are exported to UDDI registry

Support for third-party registries

IDE browsing and discovery of services

Runtime binding of services

Asset management

Storing WSDL, service definitions, schemas, etc.

General purpose object repository

Commercial products include:

Oracle AquaLogic Registry/Repository

IBM WebSphere Server

HP Systinet Registry/Repository

TIBCO ActiveMatrix Registry

Microsoft UDDI Services

Open Source products include:

jUDDI

OpenUDDI

MuleSource Galaxy

WS02 Registry

Points to Ponder (for Evaluation)

Does the Service Registry / Repository have a web-based management console? How secure is the console?

How easy is it to Register and un-Register a Service?

Does the Service Registry / Repository support UDDI? If so, which version(s)?

What other lookup protocols does the Service Registry / Repository support? What version(s)?

Regardless of the Service Registry / Repository chosen, are there any Open Source APIs (etc. UDD4J, etc.) that can make it easier to communicate with the Service Registry / Repository's communication protocols (e.g., UDDI, Atom, etc.)?

Does the Registry / Repository work with RESTful Web Services?

Can the Service Registry / Repository integrate with other Service Registry / Repository products?

How fast is the lookup? Will it become a performance bottleneck?

How scalable is the Service Registry / Repository?

Does the Service Registry / Repository have Fault Tolerance, Load Balancing, and Federation capabilities?

Does the Service Registry support workflow for change approval?
 

Service Management

This function manages and secures the services, applications and resources. IT enforces runtime governance.

Provides visibility into the architecture, monitoring business processes and slow of failing services. Often, this component is integrated into a network management system providing notifications to operators in case of outages.
 

Examples include:

Business Activity Monitoring (BAM - see section 3.4.6)

Service Network Monitoring

Service Fault Monitoring
 

A Service Manager is an integral part of runtime SOA Governance. It is responsible for service monitoring and management as well as SLA monitoring. A Service Manager is a monitoring aid that reports on all the services deployed in the enterprise. A system manager can use it to manage deployed Services and gather information:

Detect, manage, and report on exception conditions (SLA violations, service outages, etc.).

Gather performance metrics. Does it scale in production?#p#分頁標題#e#

Utilization statistics

Information about the Service's consumers

Information concerning adherence to SLAs.

Data regarding runtime policy enforcement.

Commercial products include:

Amberpoint

Software AG CentraSite (formerly Infravio)

SOA Software governance suite
 

Open Source products include (but are not limited to):

MuleSource Mule HQ

Please note that the Open Source Service Manager products mentioned above are still in their infancy, and that a commercial product will probably be the best choice until there are more mature Open Source options.

Points to Ponder (for Evaluation)

Is the Business willing to pay for a COTs product? OR, would IT be willing to live without this?

Could the Service Manager also double as a Service Registry / Repository? Do we really need both types of products? OR would having a separate Service Manager and Service Registry / Repository lead to better performance and scalability?

Does the Service Manager work with RESTful Web Services?

Does the Service Manager have a web-based management console? How secure is the console?

How easy is it to deploy and un-deploy a Service?

How good are the reports? What formats are available?

What types of notification does it provide? Email? SMS? Paging?

How scalable is the Service Manager?

Does Service Manager have Fault Tolerance, Load Balancing, and Federation capabilities?

Service Modeling

Governance management of the models used by the services, processes, rules, information and security functions.

Service Operation Guidelines

Service Lifecycle Management

Governance Organization
 

Services governance includes both business and technical oversight. This function, though not a technical function, is a critical organizational function that must integrate with business process and architecture governance, business services governance, data governance, security governance and technical services governance, general IT and enterprise level governance.
 

Monitoring and Management

Accounting
 

Configuration

Configuration management is the services function that is similar to the software configuration management that assures the interoperability of software components and resources.
 

Deployment

Tracking and monitoring of the deployment of services, metadata, new versions of MS architecture components and the supporting data sets. Typically this function is integrated with the Deployment & Installation Tools and/or the data centers application monitoring tools.
 

 

Tracking and logging of the event occurrences and resultant processing including exceptions and failure conditions. Data should enable the analysis and planning of event logic, event processing and new events.#p#分頁標題#e#
 

Exceptions

The exceptions function may include exception detection or reception of exception messages, the determination of the exception dispositions, execution of the dispositions, and logging.
 

Life-Cycle Management

Tracking and logging of the transactions and events occurring across the services life cycle.
 

Policy Management

Runtime tracking of the services' policies and contracts, and runtime compliance.
 

Service Versioning

Services version tracking, compatibility matching, and deployment data for assurance that the deployed versions are correct, and where multiple versions are required that they can co-exist, are correctly invoked and executed.
 

Integration

An Enterprise Service Bus (ESB) is a key enabler for business agility. It enables faster accommodation of existing systems and reuse of existing functionality. An Enterprise Service Bus is a broker that supports synchronous and asynchronous service invocation. It also enables message transformation and event notification between applications. It helps consumers find providers and handles the details of communication, protocol mediation and message routing between them. All the services in an organization (usually Web Services) are made available over an ESB.
 

An ESB provides enterprise services such as:

Routing - A service provider offers a service at and endpoint. Consequently the service request needs to be routed from the consumer to the provider's end point.

Transformation - A service request might need to be transformed from one format to another. It might be XML to XML transformation using XSLT.

Adaptation - Messages in an ESB most of the times follow standard SOAP format. However some applications may not support SOAP format and might need some kind of adapter to transform the message.

Messaging - Provides asynchronous reliable messaging transport.

Orchestration - An integration scenario might require state information to be managed by an orchestration engine that orchestrates the flow of control form one service to another.

Security - Authentication and authorization of entities making the service calls using ESB infrastructure

Consumer Integration - Ability for consumers to lookup the endpoint and direct the service requests to that endpoint.

Service Integration - Validating the service requests and enforcing policies to enable secure service invocation.

Metrics and Management

Invocation - Support for synchronous and asynchronous transport protocols, service mapping (locating and binding).

Many ESBs will also provide a Service Repository / Registry and a BPM / Workflow Engine.

Commercial products include (but are not limited to):#p#分頁標題#e#

Oracle Service Bus

IBM WebSphere Enterprise Service Bus

TIBCO ActiveMatrix Service Grid

Microsoft BizTalk Server

Open Source products include (but are not limited to):

Apache ServiceMix

MuleSource Mule

JBoss ESB

Points to Ponder (for Evaluation)

Where in the various workflows would we need to use an ESB?

Can a Workflow ESB do prioritization of processes? What does the Business need?

Can a ESB handle dynamic workflows? What does the Business need?

Since many ESBs provide workflow capabilities, do we need a separate workflow engine?

Since workflow engines claim to provide orchestration, do we need a separate ESB or do we only need a workflow engine?

Does the ESB support Business Activity Monitoring (BAM)? If not, is there a separate BAM product that we could use as a front-end?

Can you invoke the ESB with a Web Service (SOAP/XML) call?

Can the ESB invoke our Shared Services with a Web Service (SOAP/XML) call?

What versions of SOAP, WSDL, UDDI, WS-I Basic Profile, and WS-Security does the ESB support?

What other WS-* standards does the ESB support?

What other transport protocols and messaging formats are available with the ESB?

What kinds of adapters (HTTP, FTP, etc.) are available with the ESB?

What kind of security does the ESB support?

How scalable is the ESB?

Does the ESB have Fault Tolerance, Load Balancing, and Federation capabilities?

What's the runtime environment (JavaEE, .Net, etc.) for the ESB?

What type of management / monitoring is available for the ESB?

Does the ESB have its own embedded Service Registry?

If so, the does the Registry support UDDI?

Could the ESB integrate with an external Service Registry?

Does the ESB support the JBI standard?
 

Service Integration

Includes Repository, Registry, Mapping and Transformation functions for services and protocols
 

Messaging

Message interpretation and validation of message format. This function is the first look at incoming messages to determine what other functions will be called within the ESB.
 

Transformation

Within the ESB this function transforms data formats, data models (schema), and protocols. This function is required to convert between dissimilar services.
 

Routing

Message routing function performed by the Enterprise Service Bus typically. Includes the functions of Invocation (asynchronous or synchronous), Message Queuing, Reliable Messages, and Content Based Routing
 

Orchestration

Orchestration is a special type of workflow that is generally applied to the construction of business processes from composites of smaller (e.g., Common, Data, Utility) Services that do not require human interaction. Orchestration often includes a controller that manages the messaging between each part of the workflow.#p#分頁標題#e#

A standards-based mechanism that defines how web services work together, including business logic, sequencing, exception handling, process decomposition, including service and process reuse. Orchestrations are long-running, multi-step transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature.
 

Services

Shared Services are those Services developed by a company for use throughout an organization:

Business Services

Common Services

Data Services

Integration Services

Utility Services

Shared Services are usually deployed as Web Services to make it easier to access them and integrate with them. Please see the Web Services section (3.4.9) for available products.
 

Business Services

Business Services are at an LOB (Line Of Business) or Business Unit level. These are services at a higher level of granularity that correspond to the organizational realities of the enterprise. Examples of Business Services include:

For EDRM - Archive and eDiscovery.

For Insurance - Auto and Homeowners

Business Services provide the following benefits:

They are completely independent of the application invoking the service in order to perform its operations.

The interface is based on a canonical data model, an XML-based platform/language independent way to communicate representing business data.
 

Characteristics:

Some Business Services may be exposed to external partners, and may require extra security.

Business Services are very coarse-grained.

Business Services are stateless.

Business Services are composed of and leverage other Shared Services (Common Services, Data Services, Integration Services, and Utility Services).

Business Services are deployed as traditional Web Service (SOAP / WSDL) with XML instance documents as input and output. This is done to make it easier to integrate with external partners and with BPM and ESB products.
 

Application Services

Interface Web services used to connect to Consumer applications. These services may be wrapper services around an RPC, a CICS gateway service, or a common off the shelf software (COTS) interface services (like SAP or Oracle apps). These interface services can also be custom built.
 

Data Services

Data CRUD services for both providers and consumers. These are atomic services typically, though for complex queries these may be low level composite services.

Data Services support the management and provision of data between different systems or application components. These services are particularly important in the environment due to the many underlying systems with separate data approaches and structures. Data Services provide a consistent approach to enterprise-wide data access by exposing Create, Read, Update, and Delete (CRUD) capabilities for entities in a particular business domain (which are usually stored in a database). Examples include Customer, Policy, Order, Claim, etc.#p#分頁標題#e#

There are two options for designing and deploying Data Services:

SOAP/WSDL-based Web Service - This is a traditional way of building a Data Service, but this approach is heavy and doesn't integrate well with web-based applications. The interface typically uses an XML instance document (with query parameters) as input, and an XML instance document (with the result set) as output.

There are two Open Source products that enable designers to build Data Services in a declarative manner (i.e., without coding) by enabling developers to match database tables and columns to XML elements and attributes, including:

XAware

WS02 Data Services

Developers can also write their own code to build Data Services. Please see the Web Services section (3.4.9).

RESTful Web Service - This is a more modern way to build Data Services, and this lighter approach is well-suited to support web applications that need to use simple CRUD operations on data sources. With REST:

HTTP is the communication protocol rather than SOAP.

The entity name is in the URI to define the entity being accessed.

HTTP operations define the method name - POST (for Create), GET (Read), PUT (Update), Delete (Delete)

The output format can either be XML or JSON, but JSON is gaining popularity these days because of its compatibility with AJAX / Web2.0 applications.

Popular Open Source products include:

Jersey - Provided by java.net, this API enables developers to deploy Java classes as RESTful Web Services.

WS02 Data Services - Provides declarative mappings from back-end data sources to JSON data structures.

Points to Ponder (for Evaluating Data Services products)

Can Data Services be exposed without writing any code?

Does it support exposing Stored Procedures and functions?
 

Integration Services

An Integration Service (usually a Web Service) acts as a proxy to an external service (see section 3.3 for details). Even though many 3rd party services provide a Web Service API, an Integration Service is needed for each one to hide the API details from the rest of the enterprise, and expose a Web Service that best fits the needs of the enterprise. Examples of an Integration Service include wrappers for:

A Web Service API for a CRM (Customer Relationship Management) product such as SalesForce.com.

A Shipping Web Service API provided by a Shipping Carrier such as UPS or FedEx.

Integration Services provide the following benefits:

Handling the low-level details (e.g., communication protocol, using the interface) of invoking the 3rd party service.

Converting data between the enterprise's format and that of the 3rd party service.

Managing the security details when invoking the 3rd party service.

Handling any communication or service-level failures.

Insulating the rest of the enterprise from changes to the interface of the 3rd party service.#p#分頁標題#e#

Providing a single Point of Control / Contact with 3rd party services.

Integration Services can be reused by multiple higher-level Services.
 

Characteristics:

Can be used by multiple higher level services.

Integration Services are not exposed outside to external partners.

Integration Services are deployed as traditional Web Service (SOAP / WSDL) with XML instance documents as input and output. This is done to make it easier to integrate with BPM and ESB products.

Integration Services may leverage Utility Services.
 

Utility Services

These are the atomic services which access network, file, printing and shared resources.

Utility Services are fine-grained, and provide reusable wrappers to system-level functionality to the higher level Shared Services. Examples of Utility Services include Email, Logging, etc.
 

Characteristics:

Used by multiple higher level services.
 

Utility Services are not exposed outside to external partners.
 

Utility Services are deployed as traditional Web Service (SOAP / WSDL) with XML instance documents as input and output. This is done to make it easier to integrate with higher level services. But if the interface to these services is fine-grained, and the XML becomes unwieldy, an RPC interface may be a better choice at this level.
 

Application Services

Interface Web services used to connect to Consumer applications. These services may be wrapper services around an RPC, a CICS gateway service, or a common off the shelf software (COTS) interface services (like SAP or Oracle apps). These interface services can also be custom built.
 

External Services

Access to external resources, both public and private, requires secure services that provide access across the corporate firewall while insuring the integrity and security of those access needs, these needs are provided by External Services.
 

For example these services would be required to expose Duke services to Infinisys at the Convergis hosted site, and should be used to interface with Infinisys services that are exposed by the hosted site. Another example are the DCI interfaces to Nuance.
 

An organization does not exist in a silo. A company usually has to collaborate with its business partners or with other applications inside the enterprise in order to get specific jobs done (e.g., credit authorization, shipping packages, etc.). This involves communicating with applications or services provided by other companies. A company will usually develop an Integration Service to insulate the rest of the enterprise from the details of communicating with 3rd party services - please see section on Integration Services for further details. There are two types of Service Providers:#p#分頁標題#e#

Service-Enabled - These external services are available as Web Services and are compatible with a SOA Architecture. This could include:

Business partner Web Services like Credit Card Authorization.

Other applications within the enterprise such as ERP/Accounting systems, and3rd party developed tools that need to integrate with Shared Services.

Non- Service-Enabled - These external services are difficult to integrate with, and run the gamut of non-standard interfaces:

TCP/IP - Socket-based programs that communicate using TCP/IP.

Pure HTTP - HTTP parameters are used for both input and output.

Flat files - delimited, positional (e.g., like a COBOL Copy-Book), etc.

Microsoft files - Excel and Word.
 

Data Transport Services

Data Transport Services are exclusively used where large amounts of data or very frequent data transfers are required, and where the transport of this data through messages would overwhelm the ESB or other MCI components with very high levels of message content data volumes and/or message volumes.
 

These services use an ETL tool (Informatica or XML appliance) for the physical data movement, and services for exception detection, resolution, logging and notification.
 

The physical implementation baseline assumes use of Informatica (possibly XML appliance) for physical data movement, Cybermation for scheduling ETL and Managed Services for exception handling and disposition. However, a XML appliance may be used for some if not all of the physical data transport.
 

Information

Master Data Management (MDM)

The services within the Managed Data Management System maintain a Master Data Repository that contains instance master data from data domains such as Party (Prospect, Student, and Faculty), Course, Transcript, Program, and Facility.
 

The primary functions are Interface Services, Lifecycle Management, Hierarchy & Relationship Management, MMD Event Management, Data Quality Management, Authoring, and Base Services for master data.
 

Canonical Data Model (CDM)

The canonical data model is the definition of a standard view of a particular subject, plus the mapping back to each application view of this same subject. Canonical data model minimizes dependencies between integrated applications that use different data formats. Managed Services use a CDM, and the same model is expected to support the IMA in delivering enterprise-wide business intelligence (BI) though they may not be identical. All messages and event notifications, which are published by applications, should be translated to the canonical data model thus decoupling data providers from consumers.
 

Transactional Database

Relational databases that are data stores for the Managed Data Services Architecture components. This component does not refer to the transactional system/application databases or data stores used by the data hubs, catalog layer, or data marts.#p#分頁標題#e#
 

Data Warehouse/Hub

A Data Hub is a collection of data for a specific business subject area and is the authoritative source of data for application integration, and the authoritative source of data for reporting and analytics. However, Data Hubs cannot be the system of record, only a system of reference.
 

A Data Warehouse (DW) is a single, centralized repository that holds an enterprise's data to support reporting and analytics, and to make it easier to find data that is important to the business. A data warehouse environment consists of the following:

Data Warehouse Storage

Metadata (Metadata is information that describes and provides a consistent, agreed-upon enterprise definition of data, such as a customer.

Data Access and Transport (Extract, Transform, and Load)
 

The Data Sources

A Data Warehouse greatly simplifies reporting and analysis. It is a key enabler of BI / Reporting and facilitates KPI monitoring. A Data Warehouse is usually in a separate data store from an enterprise's Operational Data Store(s) to avoid degrading the performance of production databases.
 

Infrastructure

Message Transport

This function physically moves the messages from the sender to the recipients based on the message routing logic determined by the Routing function within the MCI.
 

Portal Server

The portal server is provides Web based portal access to Web applications, COTS portals (like MS SharePoint), analytics and reporting sites.
 

Database Server

Relational database management system server that provides the data store CRUD functionality.
 

Data Life Cycle Management

Life cycle management includes the functions of CRUD, archival and retrieval. The services data that this function manages includes all data found in the other Managed Services layers. Typically this function starts with the most mission critical, versioning and release critical data around services, then expands as the Managed Services capabilities are matured.
 

Load Balancing

Load balancing can occur at many different levels with the Managed Services architecture from the initial Web server to MCI components to the applications server to data load management and to network traffic load management. An example of the latter is isolating the meter Data Transport Services on their own LAN segment to minimize the impact of their volume and frequency on the performance of other services.
 

Data Transport

This function physically moves the data from the provider to the consumer.

The physical movement can be done by a service or some other method such as an ETL tool like Informatica or a XML appliance.#p#分頁標題#e#
 

Data Lifecycle Management

Life cycle management includes the functions of CRUD, archival and retrieval. The services data that this function manages includes all data found in the other Managed Services layers. Typically this function starts with the most mission critical, versioning and release critical data around services, then expands as the Managed Services capabilities are matured.

Process Server

The services Process Server function provides the process model and script interpretation function to execute the business logic and to invoke the business rules that are described for a business process and/or system-to-system process.
 

Web Server

Interprets and delivers Web pages in HTTP.
 

Application Server

The application server provides the functionality required to execute the software functionality logic of services, and the physical thread and server process management.

Getting Started with SOA - Driving Toward a Solution

The following diagram shows how the SOA-related architecture documents relate to each other and how they drive toward a SOA Solution.
 

The architecture documents and outcomes are as follows:

The SOA Reference Architecture provides basic SOA definitions and guidelines.
 

The Information (Data) Architecture defines:

Data at Rest - in the database and/or data warehouse

Data in motion - for the XML messages (see the Canonical Data Model section (3.6.2)).
 

The Business Architecture defines the requirements (User Epics / User Stories / Use Cases) and Business Processes.
 

The Application Architecture defines the Service Layers, architectural choices, and Service Consumers, Shared Services, and External Third-Party Services (see the SOA Reference Architecture diagram in Section 3.0).
 

The SOA Solution Architecture combines all of the above documents, and defines implementations for (see the SOA Reference Architecture diagram in Section 3.0)

Foundational Services

Operational Services

SOA Governance

Implementing the SOA Solution Architecture yields:

Defined Services - Services that enable the business architecture, with well-defined contracts.

Designed & Implemented Services

A SOA Solution

While this may look like a lot of steps, please note that:

You don't have to implement everything in the above diagram to start developing initial Services.

SOA implementation is gradual, iterative, additive process.
 

To make this process actionable and tangible, the development organization must determine how to define the SOA architecture and how to implement by using:

Discussion Points - These are working agreements that define how the architects and developers will work together to define and build out the architecture. These are the organization's best practices and design templates.#p#分頁標題#e#
 

Decision Points - These decisions determine the technology stack used when developing Services. Decisions take the form of:

Technology X vs. Technology Y

Pros and Cons

A final decision that everyone follows.

The main goals here are shared vision along with consistent design and implementation across the SOA solution.

Architectural / Design Discussion Points include:

Tying Business Processes to User Epics / User Stories / Use Cases

Tying Business Processes to Services

Requirements (User Epics / User Stories / Use Cases) and Business Processes

Candidate Services (based on Requirements and Business Processes)

Service Design

Patterns (SOA, EA, etc.)

Web Service Design

XML Message Design

Security

Web Services Technical Infrastructure (e.g., WS-I Basic Profile 1.1, WS-Security Profile 1.0, etc.)

UI - Use of RIA / AJAX

Automated QA / CI for Component Platform (Ruby, Java, .Net, PHP)

Size and Performance

Overall Quality

Usability

Maintainability

Reusability

Extensibility

Portability

Testability

Configurability

Performance

Scalability

Reliability

Availability

Security

Manageability

Serviceability

Implementation Discussion Points include:

Component Platform (Ruby, Java, .Net, PHP) best practices

Component Platform (Ruby, Java, .Net, PHP) coding standards

Decision Points include:

UI technology (e.g., Ruby, JavaEE Portal, .Net, PHP, etc.)

AJAX API (i.e., Dojo, Prototype, Scriptaculous, jQuery, etc.)

Web Services implementation technology (e.g., Ruby, Java, .Net, PHP, etc.)

Web Services platform (e.g., Axis2, WS02, CXF, etc.)

Web Services Style - SOAP and REST

SOAP-Style Web Services interface - XML vs. RPC

BPMS product

ESB product

BAM

Service Registry

Service Manager

Component Platform (e.g., Ruby, Java, .Net, PHP, etc.) APIs

XML APIs