ORA - Oracle SOA Foundation

Service Oriented Architecture

Issues todays IT:

• Heterogeneity: no interoperable interfaces, now we have web services
• Business Focus
• Agility, reuse and cost reduction

Benefits of SOA

• Reuse of Services (at the business unit level)
• Agility: respond quickly to changing business requirements
• Simpler integration (by using standards)

Architectural Principles

• Formal contracts (Thomas: Contract Standardization)
• Loose Coupling
• Abstraction
• Reusability
• Autonomy
• Statelessness
• Discoverability
• Composability
• (Durability)
• (Interoperability)
• (Standards compliance)

(First all from Thomas Erl's books, last three added by Oracle)

Service Definition principles

• Service encapsulation - A Service must perform a complete unit of work
• Service loose coupling - Services maintain a relationship that minimizes dependencies between them
• Service contract - Services adhere to a contractual agreement, as defined collectively by one or more Service description documents
• Service abstraction - Beyond what is described in the Service contract, Services hide logic from the outside world
• Service reusability - Logic is divided into Services with the intention of promoting reuse
• Service composability - Collections of Services can be coordinated and assembled to form composite Services
• Service autonomy - Services have control over the logic they encapsulate 
• Service optimization - All else equal, high-quality Services are generally considered preferable to low-quality ones (“quality” in this context is referring to business value, reuse, and other chosen measures of value)
• Service discoverability - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

Oracle's definition of a Service

"A Service is a means of packaging reusable software building blocks to provide

functionality to users, applications, or other Services; it is an independent,

self-sufficient, functional unit of work that is discoverable, manageable, measurable,

has the ability to be versioned, and offers functionality that is required by a set of

consumers. A Service may be shared, which means that the function offered by the

Service is intended for multiple consumers, some known, and others that have not yet

been identified."

A Service is comprised of three parts: the implementation (deployed code and

configuration of infrastructure), the interface (means by which the Service is invoked),

and the contract (a description of what the Service provides and its constraints)

Architectural Models

SOA Logical Architecture

Layering to achieve separations-of-concerns.

Service Layers

• Presentation
• Business Process and Business Activity
  
  While Business Activity Services focus on static business functions, Business Process Services provide dynamic workflow orchestations of business functions. Business Services represent operations that either have a high likelihood of reuse, or a significant value to the organization.
• Data (CDM)
  
  Data Services are used to access data from various sources using many different technologies, and present data in a business-friendly form. Data Services offer a way to aggregate, transform, and synchronize data from multiple sources. They expose data in a format that best supports business Services and composite business applications.
• Connectivity
  
  They establish connectivity with legacy applications that do not inherently provide Service oriented interfaces. Services exposed at this layer are not intended to reflect business context in any way. Being context-neutral, they can be used in many different business scenarios.
• Utility (Not containing business logic)
  
  Services generally perform infrastructure-related functions, such as security (credential mapping, access control, auditing), logging, notification, policy lookup, transaction watermarking, etc. This classification of IT functions is often referred to as "cross-cutting" and are, therefore drawn perpendicular to the other services in thisdiagram;
  
  

Service Providers and Service Consumers

Service Provider

It is important to note that providing a Service is more than simply providing an interface to invoke a business function. The Service provider must ensure that qualities of Service are stated, offered, and adhered to. This is especially important for Services of an enterprise-class nature, i.e., Services advertised for use across departmental boundaries and/or Services that are leveraged by mission-critical solutions. Therefore the principles of Service enablement must be followed.

Architectural Principles

1. An interface must be provided that conforms to the reference architecture

2. A contract must be provided as specified in the reference architecture

3. Security policy must be defined and enforced

4. Versioning strategy must be adhered to

5. The Service must conform to infrastructure rules for discovery, management, monitoring, and governance

6. The Service must be classified according to layers and definitions of the reference architecture

7. The Service provider must ensure that the Service will satisfy the aggregate specifications of all related usage agreements

Service Consumer

Service consumers are, of course, consumers of Services, but more importantly they do not offer an SOA capabilities nor are they required to conform to SOA principles (assuming they are not also Service providers). Service consumers may be end-users, composite applications, or other systems in purely system-to-system interactions.

Composite Applications

Composite Applications is a term used to define applications built primarily of Services. These Services may belong to any of the Service layers previously described. Common examples of Composite Applications include portals and BPM processes.

Unlike Composite Applications, Composite Services do not provide complete, self-contained functionality to an end-user, but instead provide Services to other Services, systems, or applications. Composite Services are comprised of other Services and are hence, Service Consumers; since they provide Services they are also Service Providers.

Service Scope

• Multi enterprise (Exposed Services)
• Enterprise Wide (only used within the Enterprise)
• Intra-line of Business (LOB) (Only used within a LOB)
• Intra-Application (Only used within an Application)

Service Meta Model

Contract

A contract describes the Service in human-readable terms, enabling a solution designer to determine its capabilities and characteristics. It includes both functional and non-functional terms (such as invocation protocols, security requirements, semantics, transaction requirements, invocation style, quality of Service).

Service policies are reusable, composeable descriptions of behavior used to specify Service contracts.

There are various policy types:

Compliance

Compliance policies can take the form of industry or enterprise standards, or regulatory and other legal mandates (example WS-I).

Quality-of-Service

Mostly non-functional like availability, performance, transaction integrity. WS-ReliableMessaging, WS-Transactions, WS-Coordination, WS-AtomicTransaction and WS Business Activity Framework, WS-Security

Message Exchange Pattern (MEP)

Examples are request-response, one-way, asychronous (WS-Addressing), pub-sub, broadcast. Other considerations: transactional requirements, only once or idempotent.
Security

Following aspects play a role:

• message level security (WS-SecurityPolicy)
• transport level security
• authentication
• authorization.

Other security standards specified by OASIS:

■ WS-Security Core Specification;

■ Username Token Profile;

■ X.509 Token Profile;

■ SAML Token profile;

■ Kerberos Token Profile;

■ Rights Expression Language (REL) Token Profile;

■ SOAP with Attachments (SWA) Profile.

Interface and Messaging
Interface often soap over HTTP, because:

Platform independant, vendor support, standards support, firewall penetration. 

Disadvantages can be: verbose, reliability and security due to lack of security standards.

Implementation

An implementation will often consist of deployable code as well as infrastructure configurations, security policies, management agents, etc. - all parts working together to fulfill the contract. The Service Infrastructure side typically provides the Service enablement capabilities for the implementation. These capabilities may include, exposing the interface as a Web Service, handling SLA enforcement, security, data formatting, and others. Service infrastructure should be utilized when possible, as it reduces the burden on Service providers, from an implementation standpoint.

Separation of Concerns

There must be a clear separation of concerns in terms of what they do from how they are used. Services should be written to accomplish their function regardless of what protocol is used to invoke them, where they physically exist, or on what type of hardware or operating system they run on. This provides for maximum reuse by allowing access through multiple types of interfaces. It also provides greater versatility in how they are deployed and what underlying technologies are used.

Principle: Services must not be tied to any particular underlying technology, delivery channel, or physical location.

Service Versioning

Following the loose coupling principles of SOA, the impact to consumers should be minimized. For this reason changes should be handled as versions, ideally supporting the ability to have multiple versions running concurrently.

Principles

1. Services must support multiple concurrent versions.

2. Service providers must be able to release new versions into production without waiting for consumers to certify on them.

3. Consumers must be able to test and certify on new Service versions before switching to the new version in  production.

Technologies and Standards

SOA must be standards-based in order to achieve interoperability. Also for given Enterprise, technologies (in the form of platforms), tools, and engineering practices must adhere to selected standards.

Standards may originate from various sources:

■ IT industry standards (e.g. W3C XML, OASIS WS-*);

■ Business industry standards (e.g. HL7, …);

■ Enterprise standards (engineering standards).

The primary benefits of adopting standards are interoperability, technology, independence, and rapid integration.

Core SOA related standards recommended are:

■ Java API for XML Web Services (JAX-WS)

■ Business Process Execution Language (BPEL)

■ A collection of Web Services standards (WS-*)

■ Simple Object Access Protocol (SOAP) with attachments and Message Transmission Optimization Mechanism (MTOM) (implemented as SOAP with Attachments API for Java (SAAJ)

■ HyperText Transfer Protocol (HTTP)

■ Universal Description, Discovery and Integration (UDDI)

■ Service Component Architecture (SCA)

■ Apache's Web Service Invocation Framework (WSIF)

■ Web Service Interoperability (WS-I)

Industry specific standards are:

■ HL7 (XML messaging standard for Healthcare)

■ HRXML (for support a variety of business processes related to human resource management)

■ Telecoms IMS (IP Multimedia Subsystem, 3GPP Technical Specification TS 22.228)

architectural strategy and standards for decoupling of the technical and organizational constraints of former telecommunications strategies)

■ OASIS ebXML work, such as, CPPA (Collaboration Protocol Profile and Agreement) which describes how trading partners engage in electronic business collaborations through the exchange of electronic messages

Standards for SOA can be categorized into five areas of concern:

1. Orchestration and composition;

2. Description and discovery;

3. Messaging;

4. Implementation.

5. Management

SOA Implementation Architectural Styles

REST

HTTP provides a stateless, platform-independent protocol for the exchange of

information over a network; it is a standard for a request/response dialogue between

clients and servers.

From the definition of HTTP (or more accurately its principle author, Roy Fielding) an architectural style emerged called Representational State Transfer (REST). Core to the concept of REST is a resource which it defines as any item of information or capability addressable on a network by a global identifier (its URI in HTTP terms). The REST architectural style describes any simple interface which transmits domain-specific data over HTTP without involving higher-level messaging, such as, SOAP.

Support for REST is also starting to appear in Web Services standards: WSDL 2.0

RPC

RPC is a means of calling a method or function on another node in a distributed computing environment.

Early examples of standardized RPC's included Sun's RPC, Microsoft's DCOM, Java's RMI, OMG's SOA, CORBA, ODBC/JDBC, and SQL*Net. More recent RPC's include XML-RPC, and HTTP.

Web Services Architecture

The World Wide Web Consortium's (W3C) Web Service Architecture (WSA) provides a definition of Web Services:

"A Web Service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols."

Web Services Standards 

The second generation of Web Services specifications (commonly referred to as WS-*) has a large focus on enabling QoS within an SOA environment, which is one of the reasons Web Services has become the primary way to expose Services.

Infrastructure

Service Enablement

Service Enablement is a key differentiator of Service implementation (as opposed to application implementation).

Service enablement is

responsible for the following aspects of a Service:

■ Configuration based logic

– Routing

– Transformations

– Versioning Support

■ Composition

– The ability to compose a new Service through the composition of two or more

Services.

■ Change Control

– Audit support

– Configuration aggregation

– Configuration Rollback support

– Real-change application. Changes are applied without requiring a

redeployment or server restart.

■ Throttling

– Thread management

– Priority based resource management

– Consumption monitoring

■ Security

– Centralized Policy Management

– Distributed Enforcement

– Security Standards (WS-Security, WS-Policy, SAML, SSL, etc).

■ Interface exposure

– Using accepted interface protocols, transports, message types, and standards

– Service Discovery (published to a registry and/or repository)

– Service Definition (creation of a contract)

Service Discovery

There are two sides to consider regarding Service discovery: design time discovery and run time discovery.

Service Mediation

Among their many capabilities are:

■ Translate, or transform request and response messages

■ Accept requests via one transport or protocol and forward them on using a different transport or protocol

■ Route messages based on content within the request message (Content-based routing)

■ Route messages based on security policies

■ Translate (map) security credentials between different users/groups/roles or between different credential types

■ Add or remove security measures such as encryption and certificates

■ Invoke multiple Service providers as part of a single Service request

■ Audit and/or log requests

■ Deny requests based on access policies (SLAs, Usage Agreements)

■ Capture response time metrics and usage metrics

■ Monitor and report on error conditions

Architectural principle:

Services must be loosely coupled, e.g. they must always be accessed via an intermediary. Consumers must not directly access Service provider endpoints.

Packaging and Deployment

Service infrastructure brings its own complexities to the construction of deployable packages of Service capabilities.

Common types of deployable artifacts in a SOA environment generally include the following:

■ WSDL, XML Schema, XSLT, Xpath, various rules definitions, WS-* docs

■ Code (in the form of JAR, WAR, EAR)

■ Directory definitions

■ Access controls

Services deployment

The approach, recommended by Oracle, to Services deployment is the separation of Services from applications and the grouping of Services with similar availability needs. To accomplish this, projects must be logically divided into shared and non-shared parts. The shared parts become Services, while the non-shared parts become ordinary applications. 

The illustration shows an application cluster used to host ordinary applications, and a Services cluster hosting Services. The clusters connect through the Services bus, allowing access to Services by the applications. Redundant hardware is used in both clusters to provide high availability.

Important considerations for grouping Services:

■ Ownership of resources. This includes hardware and software ownership, and responsibility for management. 

■ Technology. Different technologies used for Service implementation will require different clustering strategies and may require different hardware platforms.

■ Service Level Agreements. Services that demand high availability and low downtime or maintenance windows should be separated from Services that do not share these requirements.

Federated

Federation also applies to the level of autonomy each domain has with respect to processes and Services. Processes in one domain may leverage processes that are offered as shared Business Process Services in another domain, as illustrated above. Services that represent automated business activities (tasks) within a process may be deployed in the local domains. In this scenario each domain retains autonomy in terms

of how its processes are written, which tasks are fulfilled by Services, and how the Services are offered (interface, security, implementation specifications). It is most useful when a "black box" approach is desired, i.e., details of sub-process flows including current status, execution logic, etc., do not need to be known or managed at the enterprise level.

Another option for process federation is shown below. This method involves defining processes and sub-processes at the enterprise level. The Services that fulfill automated tasks may be offered in different locations, and accessed in different ways. This method is preferred when entire end-to-end process management and

monitoring is needed. Each process and sub-process can be controlled at the enterprise level, while Services are managed at the domain level.