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

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 policies can take the form of industry or enterprise standards, or regulatory and other legal mandates (example WS-I).
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.
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.

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.
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

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 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.


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
■ 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.

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.


Social Media a necessity for Consultants ?


I work as a Enterprise Application Integration / Service Oriented / Business Process Management consultant at a company. I started using Blogger, LinkedIn, Facebook and Twitter almost 2 years ago. I started with LinkedIn and almost a year later with my blog, recently i started using Twitter and Facebook. I also tried Plaxo and Hyves but I dropped them.
My first reaction to Twitter and Blogger was the same as the one I get today:
  • I have no time to Blog
  • I do not know what to Blog
  • Why should I Blog?
And with Twitter:
  • I do not know what to Tweet
  • I am not interested in what a person does in the bathroom
  • Too may Tweets to read
  • Stupid stuff

Within this blog item i will try to explain why I think it is a necessity (or can be) for every consultant.


I started blogging with knowledge storage in mind. When I found a solution for a particular problem or when I did not want to forget how I did some things, i started to make a Blog item for it. This way I could always look up how to do this. After a couple of Blogs i got some remarks/comments/questions on my Blog, so i started to realize that my blog was also good for personal branding.

I also noted that it was also good company branding, because at seminars and conferences, people started to "recognize" me, so it was very good for networking as well.


With Twitter the same story. I just wanted to know what it could mean for me, so i started using it out of curiosity. I use it almost only for business related tweets. I started to follow a lot of interesting people about interesting topics within my work field. And they follow me back as well. I use the Tweets to promote my Blogging site. I noticed that a lot of people started to read my blog and i started to read a lot of other interesting blogs.
So for me Twitter:
  • Brings me in contact with interesting people
  • It extends my knowledge within the field
  • It gives me personal exposure within the field
  • It gives me company exposure within the field
  • It gives me interesting insights in people's mind and thoughts within the field
  • It keeps me up-to-date with the latest insights within the field of EAI/SOA/BPM/Cloud
  • It extends my virtual network of people within the field

What to Tweet?

  • Well Tweet about what keeps you busy as a consultant
  • Tweet about topics that you would read yourself
  • Interesting articles, blogs and websites
  • Tweet about a new Blog item you made
  • Tweet about an interesting project your company finished
  • Tweet about an interesting solution you advised for a customer

When you follow a lot of people you can use the Twitter's List option. This way you can add people to a particular list, for example BPM, EAI, SOA, Oracle etc.

Who to Follow?
I follow interesting people within my field but also people with other interesting topics, like social media.
I also people follow people that have some interesting insights of what's going on at a customer. This can help me as a consultant what problems or thoughts customers have.

I use LinkedIn as my personal CV and keep it up-to-date. This is a site that customers always will check and it also contains a link to my blog- and twitter site. It will give me leads to interesting projects.


I think that social media is a common good within the Consultancy profession. It will keep you up-to-date of the latest insights within the fields and you can track customers need.

Oracle BPM Suite 11g in Pictures



Modeling tools and Users

Business/Enterprise Architect
  • Business Strategy
  • Implement Business Architecture
  • Process Analysis/documentation
Business User
  • Understands the business
  • High level business processes
Process Analyst
  • BPMN 2.0 expert (business view)
  • Understands the details of the business
  • Make implementation decisions
Process Developer
  • BPMN 2.0 expert (technical view)
  • WebServices, XML
  • Enterprise Apps
  • Implement processes and UIs

Collaborative Design

BPM Studio

Process Analytics

Social BPM

SOA Platform

End-to-End instance and Flow checking due to integrated platform.

BPMN 2.0 support

Change with BPMN 1.1 :
  • Model execution
  • Models are interchangeable
  • XPDL and BPEL were used to interchange and execute

Interactive task and workflow

BPM Studio supports Simulation.

BPM Studio Business Indicators

Snapshots of business indicators must be added to the workflow and this is a little awkward because it blurs the process model.

Good integration with BAM

Process Composer

Within BPM Studio you design templates and there you set the constraints which changes can be made within Process Composer.

Unstructured Processes

End Users can
  • Reassign, reroute, delegate tasks
  • Add users for a task

Business Rules

  • Decision tables
  • If-then rules
Can be changed in Process Composer.
Participants lists can be dynamically assigned using a Rule.

Enterprise Manager

Unified Security