http://www.xe.

com/

Software on a Service Oriented

Architecture
SOA, or Service Oriented Architecture, allows businesses to use the
information technology infrastructure that exists in order to address new
needs of the business. It treats the infrastructure that exists like a service,
and therefore it can be used for addressing different needs. There are
different architectural styles in SOA software. Architectural styles are
groups of principals that provide frameworks for families of systems.
COMPONENT-BASED STYLES IN SOA SOFTWARE

Component-based architectural styles use approaches that are software engineering to

designing and developing systems. This approach will deconstruct the systems design
into the individual components either on a logical or functional basis. The different
components all have communication interfaces that are well defined with a variety of
properties. The ability to be reused is a popular characteristic of the components. That
means that the components are able to be used in a variety of applications based on
different scenarios.

WHATS SOA?

SOA presents services for solution logic in an architectural model. By having these
services as the foremost method of sending solutions, SOAs goal is to be more
efficient, productive, and agile than other technology solutions. It provides support for
realizing the advantages of computing and principles that are service-oriented. SOA
implementations are made of various products, technologies, programming interfaces
(for applications), and other different extensions. Application of the service-orientation
principles to the software solutions will produce services. These services are the basic
logic unit in SOA. Although the services have the ability to exist automatically, theyre by
no means isolated. There are certain standard and common features that are
maintained by the services, but they have the ability to be extended and evolved
independently. Its possible to combine services, enabling other services to be created.
There are autonomous messages that are used for services to communicate and these
messages are intelligent enough so that they can self-govern the parts of their own
logic. The most important principles of SOA are service contract, autonomy, reusability,
composability, loose coupling, discoverability, and statelessness.

Services that can be regarded as middleware include enterprise application integration, data
integration, message oriented middleware (MOM), object request brokers (ORBs), and
the enterprise service bus(ESB)

With businesses using so many different software programs to fill their needs,
sometimes it's necessary that the different programs work together to get the end
results they are looking for. In those situations, middleware is required.

Middleware is considered by many to be a rather vague term in that it is specially

designed software that can link two separate applications together. Since this can be
used in such a wide variety of ways, it is better understood by discussing some specific
examples in how it can be used. One popular example is the middleware that is used to
connect a database system with a web server.

This allows a user to request data from a database using forms displayed on a Web
browser, according to Webopedia, while also allowing for the Web server to return Web
pages based on the user's request.

"In a highly distributed environment in which businesses need to connect with legacy systems,
cloud and SaaS applications, and business management software such as SAP and Salesforce,
the role of a middleware technology is critical,

It can be used, include

Security: Authenticates a particular client program to some system component to verify, for
example, that the client program and its user are really who they say they are.

Transaction management: Ensures that a system or database don't get corrupted if problems
occur.
Message queues: Enables loosely coupled systems to pass messages back and forth to each
other. Those messages can trigger actions or transactions to occur

Application server: A server that hosts an application programming interface (API), which
exposes business logic and business processes so that other applications can use the shared
logic and processes.

Web server: A computer program that's responsible for accepting requests from Web browsers,
as well as sending responses and content to those browsers

Directory: Enables a client program to find other services or servers located in a distributed
enterprise.

An enterprise service bus (ESB) is a software architecture model used for designing and
implementing communication between mutually interacting software applications in a service-
oriented architecture (SOA). As a software architectural model for distributed computing, it is a
specialty variant of the more general client-server model and promotes agility and flexibility with
regard to communication between applications. Its primary use is in enterprise application
integration (EAI) of heterogeneous and complex landscapes.

Service - denotes non-iterative and autonomously executing programs that communicate with
other services through message exchange
Bus - is used in analogy to a computer hardware bus
Enterprise - the concept has been originally invented to reduce complexity of enterprise
application integration within an enterprise; the restriction has become obsolete since modern
Internet communication is no longer limited to a corporate entity

An ESB transports the design concept of modern operating systems to networks of disparate and
independent computers. Like concurrent operating systems an ESB caters for commodity services in
addition to adoption, translation and routing of a client request to the appropriate answering service.

The primary duties of an ESB are:

Monitor and control routing of message exchange between services

Resolve contention between communicating service components
Control deployment and versioning of services
 Marshal use of redundant services
Cater for commodity services like event handling, data transformation and mapping, message
and event queuing and sequencing, security or exception handling, protocol conversion and
enforcing proper quality of communication servi

Category Functions

support for synchronous and asynchronous transport protocols, service

Invocation
mapping (locating and binding)

addressability, static/deterministic routing, content-based routing, rules-based

Routing
routing, policy-based routing

Mediation adapters, protocol transformation, service mapping

Messaging message-processing, message transformation and message enhancement

Process
implementation of complex business processes
choreography[4]

Service coordination of multiple implementation services exposed as a single,

orchestration aggregate service

Complex event
event-interpretation, correlation, pattern-matching
processing

Other quality of
security (encryption and signing), reliable delivery, transaction management
service

Management monitoring, audit, logging, metering, admin console, BAM (BAM is not a
management capability in other words the ESB doesnt react to a specific
 threshold. It is a business service capability surfaced to end users. )

general agnosticism to operating-systems and programming-languages; for

Agnosticism
example, it should enable interoperability between Java and .NET applications

Protocol
comprehensive support for topical communication protocols service standards
Conversion

Message support for various MEPs (Message Exchange Patterns) (for example:
Exchange synchronous request/response, asynchronous request/response, send-and-
Patterns forget, publish/subscribe)

adapters for supporting integration with legacy systems, possibly based on

Adapters
standards such as JCA

a standardized security-model to authorize, authenticate and audit use of the

Security
ESB

facilitation of the transformation of data formats and values, including

Transformation transformation services (often via XSLT orXQuery) between the formats of the
sending application and the receiving application

Validation validation against schemas for sending and receiving messages

Governance the ability to apply business rules uniformly

Enrichment enriching messages from other sources

Split and Merge the splitting and combining of multiple messages and the handling of exceptions
 Abstraction the provision of a unified abstraction across multiple layers

Routing and routing or transforming messages conditionally, based on a non-centralized

Transformation policy (without the need for a central rules-engine)

Commodity provisioning of commonly used functionality as shared services depending on

Services context

Existing ESB products

IBM Integration Bus.

IBM WebSphere ESB. (Message Broker)
InterSystems Ensemble.
Microsoft BizTalk Server.
Oracle Service Bus / Fusion Middleware Oracle Enterprise Service Bus
(BEA Logic)

Tibco ESB (Integration Broker)

A service-oriented architecture (SOA) is an architectural pattern in computer software design

in which application components provide services to other components via a communications
protocol, typically over a network. The principles of service-orientation are independent of any
vendor, product or technology.

45 Using Oracle SOA Composer with Domain Value Maps

Domain value maps enable you to map values from one vocabulary used in a given
domain to another vocabulary used in a different domain. In earlier releases, for editing
a domain value map at runtime, you first had to make the changes in Oracle
JDeveloper, and then redeploy the domain value map in the application server. Oracle
SOA Composer now offers support for editing domain value maps at runtime. Oracle
SOA Composer is an EAR file, which is installed as part of Oracle SOA Suite installation.
It enables you to manage domain value maps at runtime.

This chapter includes the following sections:

Section 45.1, "Introduction to Oracle SOA Composer"

Section 45.2, "Viewing Domain Value Maps at Runtime"
Section 45.3, "Editing Domain Value Maps at Runtime"
Section 45.4, "Saving Domain Value Maps at Runtime"
Section 45.5, "Committing Changes at Runtime"
Section 45.6, "Detecting Conflicts"

For more information about domain value maps, see Chapter 44, "Working with Domain
Value Maps."

45.1 Introduction to Oracle SOA Composer

Oracle SOA Composer enables you to work with deployed domain value maps. Domain
value map metadata can be associated either with a SOA composite application, or it
can be shared across different composite applications. Figure 45-1 shows how Oracle
SOA Composer enables you to access a domain value map from the Metadata Service
(MDS) repository.

Figure 45-1 Oracle SOA Composer High-Level Deployment Topology

Description of "Figure 45-1 Oracle SOA Composer High-Level Deployment Topology"

45.1.1 How to Log in to Oracle SOA Composer

To log in to Oracle SOA Composer:

1. Access Oracle SOA Composer at the following location:

2. http://hostname:port/soa/composer
 The Oracle SOA Composer Login page is displayed, as shown in Figure 45-2.

Figure 45-2 Oracle SOA Composer Login Page

Description of "Figure 45-2 Oracle SOA Composer Login Page"

You must authenticate yourself by entering the login ID and password.

3. In the Username field, enter a user name.

4. In the Password field, enter a password.
5. Click Login.
After you log in to Oracle SOA Composer, you see the Oracle SOA Composer home
page, as shown in Figure 45-3:

Figure 45-3 Oracle SOA Composer Home Page

Description of "Figure 45-3 Oracle SOA Composer Home Page"

You must have the SOADesigner application role to access Oracle SOA Composer
metadata. By default, all the users with Oracle Enterprise Manager Fusion Middleware
Control administrator privileges have this role. If you log in to Oracle SOA Composer
without this role, you see the following message:
Currently logged in user is not authorized to modify SOA metadata.

For information about adding the SOADesigner application role to users without
administrator privileges, see Oracle Fusion Middleware Administrator's Guide for Oracle
SOA Suite and Oracle BPM Suite.

45.2 Viewing Domain Value Maps at Runtime

You can view domain value maps at runtime. Perform the following steps to open and
view a domain value map.

45.2.1 How To View Domain Value Maps at Runtime

To view domain value maps at runtime:

1. From the Open menu, select Open DVM.

The Select a DVM to open dialog appears, as shown in Figure 45-4:

Figure 45-4 Select a DVM to Open Dialog

Description of "Figure 45-4 Select a DVM to Open Dialog"

You can also select a document from the My Edits option that displays recently
opened documents.

Note:

Alternatively, you can also search for a domain value map by

entering the name of the composite application containing the
domain value map file in the Search composite field and then
clicking the Search icon to the right of the field.
 2. Select a domain value map and click Open. You can also double-click a domain
value map to open it.

The selected domain value map opens in view mode.

You can click Bookmarkable Link to get a direct link to the selected domain value
map. The Info button provides more information on the selected domain value map.

45.3 Editing Domain Value Maps at Runtime

You can edit domain value maps at runtime. By default, domain value maps open in
view mode. To edit a domain value map, you must change the mode to an edit session
by clicking the Edit menu item.

45.3.1 How to Edit Domain Value Maps at Runtime

The domain value map opens in an edit session.

45.3.1.1 Adding Rows

To add rows:

You can add rows by performing the following steps:

1. Click Add Domain Values.

The Add Domain Values dialog is displayed.

2. Enter values and click OK.

The entered values are added to the domain value map.

45.3.1.2 Editing Rows

To edit rows:

You can edit rows by performing the following steps:

1. Select the row to edit.

2. Click Edit Domain Values.

The Edit Domain Values dialog is displayed.

3. Edit the values as required and click OK.

45.3.1.3 Deleting Rows

To delete rows:

You can delete rows by performing the following steps:

1. Select the rows to delete.

2. Click Delete Domain Values.

45.4 Saving Domain Value Maps at Runtime

Every time a domain value map is opened in an edit session, a sandbox is created per
domain value map, per user. If you save your changes, then the changes are saved in
your sandbox.

45.4.1 How to Save Domain Value Maps at Runtime

To save domain value maps at runtime:

1. Click the Save menu item to save your changes. If your changes are saved
successfully, you receive a notification message.

You can also revert a domain value map to the last saved state.

2. Click the Revert menu item. A confirmation dialog is displayed.

3. Click Yes to revert your changes.

45.5 Committing Changes at Runtime

You must commit the changes for saving them permanently. Once you commit the
changes, runtime picks up the changes and saves them in the MDS repository. In a
session, you can also save your changes without committing them. In such a case, the
domain value map remains in the saved state. You can reopen the domain value map
and commit the changes later.

45.5.1 How to Commit Changes at Runtime

To commit changes at runtime:

1. Click the Commit menu option. A confirmation dialog is displayed.

2. Click Yes to commit your changes.

45.6 Detecting Conflicts

Oracle SOA Composer detects conflicts that can occur among concurrent users. If you
open a domain value map that is being edited by another user, then you see a warning,
as shown in Figure 45-5.

Figure 45-5 Confirm Dialog for Concurrent Users of a Domain Value Map

Description of "Figure 45-5 Confirm Dialog for Concurrent Users of a Domain Value
Map"

However, if you still want to edit the domain value map, you can click Yes and make
the modifications.

If the other user makes changes to the domain value map and commits the changes,
you receive a notification message while trying to commit your changes.

If you click Yes and commit your changes, then the changes made by the other user
are overwritten by your changes.

Domain Value Maps(DVM) in Oracle SOA Suite 11G. They enable you to map from one vocabulary used
in a given domain to another vocabulary used in a different domain. For example, one domain may
represent a city with a long name (Mumbai), while another domain may represent a city with a short name
 (MB). In such cases, you can directly map the values by using domain value maps.

Domain value map values are static. You specify the domain value map values at design time using
Oracle JDeveloper, and then at runtime, the domain value map columns are looked up for values.

MDS and what all featured introduced in that. As we know MDS is used to store artifacts like WSDL, XSD, XSLT etc.
we have two types of MDS, File based MDS and DB based MDS. In Oracle SOA 12c, when we use default server
which is integrated with Jdeveloper then we can use only Design Time MDS (File Based MDS), Run Time MDS (DB
Based MDS) is not supported.

In Oracle SOA 12c release, Oracle provided couple of new options that we can use when we use Design Time MDS,
these options were not there in 11g. Below are options available with Design Time MDS.

Create and Delete folders

Export and Import MDS artifacts
Transfer Artifacts between MDS repositories

Oracle Service Registry

Oracle Service Registry provides a 'DNS'-like reference for SOA runtime infrastructure to dynamically discover and
bind to deployed services and end points. As part of the Oracle SOA Governance solution , Oracle Service Registry
bridges the gap between the design time and runtime environments through automated synchronization with Oracle
Enterprise Repository, Oracle Service Bus and Oracle SOA Suite. The benefits include:

UDDI V3 Compliance - Enables standards-based dynamic discovery of services and policies at runtime
SOA Agility - Keeps SOA infrastructure up-to-date with changes to service end points, ensuring your SOA doesn't
break
Hot-pluggable - Supports heterogeneous services from any vendor

Summary of Features and Benefits

SOA Features, Benefits, and Infrastructure shows the main features and benefits of SOA, together with the
infrastructure needed to support them.

SOA Features, Benefits, and Infrastructure

Feature Benefits Supporting Infrastructure

Service Improved information flow

Ability to expose internal functionality

Organizational flexibility

Service Re-use Lower software development and management Service repository

costs

Messaging Configuration flexibility Messaging program

Message Monitoring Business intelligence Activity monitor

Performance measurement

Security attack detection

Message Control Application of management policy PDPs and PEPs

Application of security policy

Message Transformation Data translation Data translator

Message Security Data confidentiality and integrity Encryption engine

Complex Event Processing Simplification of software structure Event processor

Ability to adapt quickly to different external

environments

Improved manageability and security

Service Composition Ability to develop new function combinations rapidly Composition engine

Service Discovery Ability to optimize performance, functionality, and Service registry

cost

Easier introduction of system upgrades

Asset Wrapping Ability to integrate existing assets

Virtualization Improved reliability

Ability to scale operations to meet different demand

levels

Model-driven Ability to develop new functions rapidly Model-implementation

Implementation environment

Service
Service is the essential concept of SOA.

It is not originally a technical concept. The idea of a service was developed in the world of business. Look in any
Yellow Pages directory, and you will find categories such as courier services, garage services, and roofing
services. For each of these, some person or company (the service provider) is offering to do something carry
goods and messages, look after vehicles, install and repair building roofs that will benefit other people or
companies (the service consumers). The providers offer to contract with the consumers to do these things, so that the
consumers know in advance what they will get for their money.

The idea has been adopted by technologists. They have established the concept of a software service. A software
service is performed by a software program. It produces effects that have value to the people or organizations that
are its consumers. It has a provider a person or organization that takes responsibility for running the program to
produce those effects. And there is an implicit or explicit contract between the provider and the consumers that the
program will produce the effects that the consumers expect.

Software services can be provided over the Internet and the world-wide web. In some countries, for example, the
government provides a service by which taxpayers can complete and submit their tax returns via the web. Here, the
service has a human interface. Services provided over the web can also have software interfaces. For example, there
are commercially-available web services that provide real-time stock quote information in a form where it can be
analyzed by the consumers software. Software services can similarly be provided over enterprises internal networks,
and a service performed by one program can be used by another program running on the same computer system. It
is the organization of an enterprises software as software services that are provided internally in this way, and also
externally, that is the essential characteristic of SOA.

The use of services provides major benefits:

In contrast to the use of large applications, which tend to be information silos that cannot readily exchange
information with each other, the use of finer-grained software services gives freer information flow within and
between enterprises. Integrating major applications is often expensive. SOA can save integration costs.
Organizing internal software as services makes it easier to expose its functionality externally. This leads to
increased visibility that can have business value as, for example, when a logistics company makes the tracking of
shipments visible to its customers, increasing customer satisfaction and reducing the costly overhead of status
enquiries.
Business processes are often dependent on their supporting software. It can be hard to change large, monolithic
programs. This can make it difficult to change the business processes to meet new requirements (arising, for
example, from changes in legislation) or to take advantage of new business opportunities. A service-based
software architecture is easier to change it has greater organizational flexibility, enabling it to avoid penalties
and reap commercial advantage. (This is one of the ways in which SOA can make an enterprise more agile.)

The service concept also makes possible further features of SOA. These can provide additional benefits, as
explained in the rest of this section.

Service Re-Use
Clear service descriptions are a starting point for service re-use, which can provide another major benefit of SOA:

Using existing software modules rather than writing new ones means lower development and testing costs and
in many cases an even greater saving lower maintenance costs.
Messaging
You can have an SOA in which software services invoke each other directly; for example, by programming-language
function calls. But, in many SOAs, the software services always invoke each other by exchanging messages, even
where they are executing on the same processor. This might seem to be an additional overhead but, if the services
are loosely-coupled (as they should be), then the number of message exchanges is relatively small, and the
overhead is reasonably low.
Consistent use of messaging provides a key benefit:

Services can very easily be moved between computer systems within the enterprise, and it is reasonably easy to
use externally-provided services to replace internal ones, and vice versa. Which services handle which messages
can be changed rapidly to meet changing business needs, or to tune performance. In short, messaging provides
significant configuration flexibility.

Having a central mechanism by which all messages are exchanged facilitates monitoring, control, transformation, and
security of messages.

Message Monitoring
Message monitoring can provide three key benefits:

Monitoring message streams between business activities, and analyzing them to obtain information about those
activities, is known as business activity monitoring. It can be a valuable source of business intelligence.
Monitoring message volumes and response times is a valuable source of performance measurement. Service
contracts often include performance clauses. Performance measurement enables service designers to put
realistic clauses into the contracts, and enables systems managers to verify that those clauses are being met.
Monitoring messages and message volumes can provide security attack detection, including detection of denial-
of-service attacks as well as of attacks in particular messages.
Message Control
Message control can provide:

Application of management policy; for example, by restricting a service consumer to a contracted service volume,
or giving priority to certain kinds of message
Application of security policy; for example, by controlling access to certain services, or rejecting messages that
could damage the enterprise systems or the enterprise itself (e.g., messages containing viruses that could
destroy data)
Message Transformation

Message transformation can provide:

Data translation the conversion of data from one format to another through automated field mapping.

Data conversion by specially-written software is expensive. The use of generic data translators can bring significant
cost saving.

Message Security

Message security can include:

Data confidentiality through encryption of messages

Data integrity through addition of cryptographic integrity-check fields

Security is a complex area that is of crucial importance to enterprises. The ability to encrypt and apply integrity
checking to messages in transit can be a valuable component of an overall security strategy.
Complex Event Processing
As well as being invoked by their consumers, services can respond to events from other sources. For example, a
financial information service might respond to stock-price changes, or a manufacturing production-control service
might respond to production process events, such as changes in temperature of the materials being processed.

In many cases, action is taken when a pattern of events is recognized, rather in response to individual events. A
financial information service might notify the user when a volume of trades is exceeded rather than in response to a
single trade. A production-control service might take measurements from a number of sensors and take action when
the average exceeds a limit. This aggregation of simple events to generate complex events is known as Complex
Event Processing (CEP).

In SOA, CEP is often used, not only for external events, but also to detect patterns in the flow of messages between
services. When used in this way, it becomes an extension of message monitoring.

CEP is often linked with business activity monitoring. For example, detection of a particular pattern in sales
transaction messages could provide advance warning of difficulties for the production process. In some industries,
such as banking, detection of particular patterns may indicate fraudulent activity, or assist with regulatory compliance.

CEP can also be used with performance measurement and security attack detection. For example, where a service
contract specifies an average level of performance, CEP used in conjunction with performance measurement could
generate contract exception events. CEP might also be used to generate security events for unusual message
volumes or patterns.

CEP provides the following benefits:

Simplification of software structure by removing functionality that is not business-related from the business
software services
Ability to adapt quickly to different external environments by concentrating in one place the logic that relates
environmental events to business events
Improved manageability and security when used with performance measurement and security event detection
Service Composition
Service composition is the putting together of a number of simple services to make a more complex one. For
example, a product sale web service could be composed of simpler product selection, shopping cart review,
payment method selection, credit card payment, and invoice payment services. Service composition provides a
key benefit:

Ability to develop new function combinations rapidly

For example, if it is decided that the product sale service should cater for a new method of payment Internet cash
this can be done by developing a new Internet cash payment service, and including it in the composition.

So far, this sounds to be little different from other software modularization techniques, from machine-code
subroutines through to Java objects. Indeed, in an SOA that does not include messaging, service composition will be
implemented by some such technique. But in many SOAs composition is implemented by services sending
messages to invoke other services, and this technique gives much greater flexibility.

Two styles of composition are often distinguished:

 Orchestration, in which one of the services schedules and directs the others. If the above example was designed
as an orchestration, there would be a direction service that would invoke in sequence the product selection,
shopping cart review, payment method selection, and, depending on the selection result, credit card payment or
invoice payment services.
Choreography, in which the composed services interact and cooperate without the aid of a directing service. If the
above example was designed as a choreography, there would be no directing service: the product selection
service would invoke the shopping cart review service, the shopping cart review service would invoke the
payment method selection service, and the payment method selection service would invoke the credit card
payment or invoice payment service.
Service Discovery
When a program uses a software service, the identity of that service can be explicitly given in the program code. For
example, where services are implemented as Java objects, their methods can be invoked by name by user programs.
Where messaging is used, the destinations of the messages can be explicitly named at programming time. This is
called hard-wiring of service connections.

Hard-wiring is a simple approach, but it has limitations. A different and much more flexible approach is service
discovery. In this approach, the identity of the target service is not known at programming time, but is discovered at
run time. The user program finds target services that meet its requirements, and chooses one of them.

The benefits of service discovery are:

Ability to optimize performance, functionality, and cost by selecting component services by these criteria
Easier introduction of system upgrades an upgraded service can be made available for selection in parallel with
the one that it replaces, which can then be withdrawn
Asset Wrapping
The IT assets of an enterprise can often be considered as actors that perform services. A CPU performs an
information processing service; a filestore performs an information storage service; and so on. This includes software
as well as hardware assets. A database management system performs a database management service; an
accounts package performs a financial information processing service.

An important feature of SOA is the recognition that these assets perform services, and the development of software
faades that provide access to these assets and have interfaces that are in the same form as the interfaces to other
software services of the enterprise. This is called asset wrapping. From a component-based software engineering
point of view, the assets and the faade are components that are assembled to form a software service. The software
services formed in this way can be used in service composition, have registry entries, and be dynamically discovered,
in the same way as other services.

When an enterprise adopts an SOA, asset wrapping is typically applied to existing application software packages.
This provides a significant benefit:

Ability to integrate existing assets which means that the value of an enterprises existing assets is preserved,
the cost of developing or acquiring replacements is avoided, and there is a smooth migration path from the old
architecture to the new one

With the advent of SOA, some application vendors have begun to offer versions of their products in which the product
capabilities are exposed as services. The acquisition of such a version is clearly a convenient way for an enterprise to
achieve the wrapping of an application asset.
Virtualization
A faade can present to the consumer a virtual asset that does not correspond to the real underlying assets. This
technique is called virtualization. Virtualization can be used to enable programs that were written to use one asset to
be executed with a different asset. For example, there are so-called hypervisors that can provide different operating
system environments to programs running on a single CPU. But in the context of SOA it is more commonly used to
create virtual assets that are functionally similar to the underlying assets. This can deliver two benefits:

Improved reliability through redundant operation of the underlying assets, so that one can take over when
another fails or is withdrawn for maintenance
Ability to scale operations to meet different demand levels through dynamically increasing or reducing the
number of underlying assets that support a real asset, as demand rises and falls

These benefits are particularly important when the principles of SOA are applied to enterprise infrastructure. While
SOA is most commonly thought of as a way of architecting an enterprises application software, it can also be used at
the infrastructure level, to create a Service-Oriented Infrastructure (SOI). Taken to the limit, this can provide a form of
grid computing. The use of virtual assets that are made available over the Internet has become known as cloud
computing.

Model-Driven Implementation
Model-driven implementation refers to the automatic realization of a system or application from an abstract model.
Where the model starts at a high level of architectural abstraction, it is usually referred to as Model-Driven
Architecture (MDA).

SOA lends itself particularly well to model-driven implementation, because it is based on a high-level software module
concept (the service) for which there are good definition and interface standards.

Model-driven implementation provides:

The ability to develop new functions rapidly an important form of agility

In SOA, model-driven implementation can be applied to service compositions as well as to software services.

Oracle JCA compliant adapters, which enable you to integrate your business applications, and which
provide a robust, lightweight, highly-scalable and standards-based integration framework for
disparate applications to communicate with each other

With the growing need for business process optimization, efficient integration with existing back-end
applications has become the key to success. To optimize business processes, you can integrate
applications by using JCA 1.5 compliant resource adapters. Adapters support a robust, light weight,
highly scalable, and standards-based integration framework, which enables disparate applications to
communicate with each other. For example, adapters enable you to integrate packaged applications,
legacy applications, databases, and Web services. Using Oracle JCA Adapters, you can ensure
interoperability by integrating applications that are heterogeneous, provided by different vendors,
based on different technologies, and run on different platforms.

Features of Oracle JCA Adapters

This topic discusses the features of Oracle JCA Adapters.

Oracle JCA Adapters provide the following benefits:

Provide a connectivity platform for integrating complex business processes: Adapters integrate
mainframe and legacy applications with enterprise resource planning (ERP), customer relationship
management (CRM), databases, and messaging systems. Oracle provides adapters to connect various
packaged applications, such as SAP and Siebel, and databases. In addition, adapters integrate
middleware messaging systems, such as MQSeries and Oracle Advanced Queuing, and legacy
applications, such as CICS and Tuxedo, to provide a complete solution.
Support open standards: Adapters are based on a set of standards such as J2EE Connector Architecture
(JCA) version 1.5, Extensible Markup Language (XML), and Web Service Definition Language
(WSDL). The support for standards reduces the learning curve of a user and eliminates the
dependency of users on a single vendor.
Service Component Architecture (SCA) assembly model: Provides the service details and their
interdependencies to form composite applications. SCA enables you to represent business logic as
reusable service components that can be easily integrated into any SCA-compliant application. The
resulting application is known as an SOA composite application. The specification for the SCA
standard is maintained by the Organization for the Advancement of Structured Information Standards
(OASIS).
Implement a Service-Oriented Architecture (SOA): The support for open standards enables adapters to
implement an SOA, which facilitates loose coupling, flexibility, and extensibility.
Use native APIs: Adapters support multiple ways of interfacing with the back-end system and provide
various deployment options. Using native APIs, adapters communicate with the back-end application
and also translate the native data to standard XML, which is provided to the client.
Model data: Adapters convert native APIs to standard XML and back, based on the adapter metadata
configured during design time. Adapter configurations are defined during design time, which is used
by runtime components.
Facilitate real-time and bidirectional connectivity: Adapters offer bidirectional communication with
various back-end systems. This includes sending requests to back-end systems and receiving a
response. Adapters also support the real-time event notification service. This service notifies about the
back-end events associated with successful back-end transactions for creating, deleting, and updating
back-end data. This two-way connectivity ensures faster, flexible, efficient integration, and reduces
the cost of integration.
Maximize availability: Oracle JCA Adapters are based on the J2CA 1.5 specification. Adapters can,
therefore, fully leverage the scalability and high availability of the underlying Oracle Application
Server platform.

For more information, see Developing Resource Adapters for Oracle WebLogic Server.
 Provide easy-to-use design-time tools: Adapters use design-time tools that provide a graphical user
interface (GUI) to configure and administer adapters for fast implementation and deployment. In
addition, the tools let you to browse, download, and configure back-end schemas.
Support seamless integration with Oracle Application Server components: Adapters integrate with
Oracle Fusion Middleware. Adapters integrate with the JCA Binding Component of the Oracle Fusion
Middleware platform, thereby seamlessly integrating with other service engines and binding
components.

1.2 Types of Oracle JCA Adapters

This topic provides information about types of Oracle JCA Adapters.

Oracle JCA Adapters include:

Oracle Technology Adapters

Legacy Adapters
Packaged-Application Adapters
Oracle E-Business Suite Adapter

Figure 1-1 illustrates the different types of adapters.

Figure 1-1 Types of Oracle JCA Adapters

Description of "Figure 1-1 Types of Oracle JCA Adapters"

1.2.1 Oracle Technology Adapters

Oracle technology adapters integrate Oracle Application Server and Oracle Fusion Middleware components
such as Oracle BPEL Process Manager(Oracle BPEL PM) or Oracle Mediator components to file systems,
FTP servers, database queues (advanced queues, or AQ), Java Message Services (JMS), database tables, and
message queues (MQ Series).

These adapters include:

Oracle JCA Adapter for Files/FTP

Oracle JCA Adapter for Sockets
Oracle JCA Adapter for AQ
Oracle JCA Adapter for JMS
Oracle JCA Adapter for Database
Oracle JCA Adapter for MQ Series
Oracle JCA Adapter for UMS
Oracle JCA Adapter for LDAP
Oracle JCA Adapter for Microsoft Message Queueing
 Oracle JCA Adapter for Coherence
Oracle JCA Adapter for JDE Edwards World
Oracle JCA Adapter for Siebel

Oracle technology adapters are installed as part of Oracle Fusion Middleware.

This section includes the following topics:

Architecture
Design-Time Components
Runtime Components
Deployment

For more information, see:

the remaining chapters in this book

Developing Resource Adapters for Oracle WebLogic Server.
Developing SOA Applications with Oracle SOA Suite.
Administering Oracle Fusion Middleware.
Administering Oracle SOA Suite and Oracle Business Process Management Suite.

1.2.1.1 Architecture
Oracle technology adapters are based on J2EE Connector Architecture (JCA) 1.5 standards and deployed as a
resource adapter in the same Oracle WebLogic Server as Oracle Fusion Middleware. Oracle Adapter for
Oracle Applications has a similar architecture as that of the Oracle technology adapters. Figure 1-2 illustrates
the architecture of Oracle technology adapters.

Figure 1-2 Oracle Technology Adapters Architecture

Description of "Figure 1-2 Oracle Technology Adapters Architecture"

1.2.1.2 Design-Time Components

During design time, Oracle technology adapters use Oracle JDeveloper (JDeveloper) to generate the adapter
metadata. Binding configuration files consist of J2CA-centric XML markup. The J2CA binding configuration
files are used by the JCA Binding Component to seamlessly integrate the J2CA 1.5 resource adapter with
Oracle Fusion Middleware.

For more information about integration of Oracle technology adapters with Oracle Fusion Middleware,
see Adapter Integration with Oracle Fusion Middleware.

JDeveloper provides accessibility options, such as support for screen readers, screen magnifiers, and standard
shortcut keys for keyboard navigation. You can also customize JDeveloper for better readability, including the
size and color of fonts and the color and shape of objects. For information and instructions on configuring
accessibility in JDeveloper, see Oracle JDeveloper Accessibility Information" in Developing Applications
with Oracle JDeveloper.

Example of generating WSDL and binding configuration files for Oracle JCA Adapter for Database:

By using JDeveloper, you can configure Oracle JCA Adapter for Database. This adapter helps you to perform
data manipulation operations, call stored procedures or functions, and publish database events in real time. To
configure adapter definitions, drag and drop Database Adapter from the Components window to the External
References swim lane.
XSL Transformations (XSLT) is a standard way to describe how to transform
(change) the structure of an XML (Extensible Markup Language) document
into an XML document with a different structure.

XSLT can be thought of as an extension of the Extensible Stylesheet

Language (XSL). XSL is a language for formatting an XML document (for
example, showing how the data described in the XML document should be
presented in a Web page). XSLT shows how the XML document should be
reorganized into another data structure (which could then be presented by
following an XSL style sheet).

XSLT is used to describe how to transform the source tree or data structure of
an XML document into the result tree for a new XML document, which can be
completely different in structure. The coding for the XSLT is also referred to as
a style sheet and can be combined with an XSL style sheet or be used
independently.

XSD (XML Schema Definition)

specifies how to formally describe the elements in an Extensible Markup

Language (XML) document. This description can be used to verify that each
item of content in a document adheres to the description of the element in
which the content is to be placed.

XSD can also be used for generating XML documents that can be treated as
programming objects. In addition, a variety of XML processing tools can also
generate human readable documentation, which makes it easier to
understand complex XML documents.

In general, a schema is an abstract representation of an object's characteristics

and relationship to other objects. An XML schema represents the
interrelationship between the attributes and elements of an XML object (for
example, a document or a portion of a document). The process of creating a
schema for a document involves analyzing its structure and defining each
structural element encountered. For example, a schema for a document
describing a website would define a website element, a webpage element,
and other elements that describe possible content divisions within any page
on that site. Just as in XML and HTML, elements are defined within a set of
tags.

XSD has several advantages over earlier XML schema languages, such
as Document Type Definition (DTD) or Simple Object XML (SOX). XSD is written
in XML, which means that it doesn't require intermediary processing by
a parser. Other benefits include self-documentation, automatic schema
creation and the ability to be queried through XML Transformations (XSLT).
The XML information set, also called the XML Infoset, is a specification for an
abstract model of an Extensible Markup Language (XML) document. The
specification contains a consistent set of definitions for use in other
specifications relevant to the data in XML documents

The specification describes the data model for an XML document as a set of
information items. According to the Second Edition recommendation, the XML
Infoset can contain the following information items:

documents

elements within documents

attributes of documents

document processing instructions

unexpanded entity references

characters

comments

Document Type Definitions (DTDs)

unparsed entities

notations

namespaces

SOAP (Simple Object Access Protocol) is a messaging protocol that allows

programs that run on disparate operating systems (such as Windows
and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and
its Extensible Markup Language (XML).
Since Web protocols are installed and available for use by all major operating
systemplatforms, HTTP and XML provide an at-hand solution that allows
programs running under different operating systems in a network to
communicate with each other. SOAP specifies exactly how to encode an
HTTP header and an XML file so that a program in one computer can call a
program in another computer and pass along information. SOAP also
specifies how the called program can return a response. Despite its frequent
pairing with HTTP, SOAP supports other transport protocols as well.

SOAP defines the XML-based message format that Web service-

enabled applicationsuse to communicate and inter-operate with each other over
the Web. The heterogeneous environment of the Web demands that
applications support a common data encoding protocol and message format.
SOAP is a standard for encoding messages in XML that invoke functions in
other applications

SOAP is analogous to Remote Procedure Calls (RPC), used in many

technologies such as DCOM and CORBA, but eliminates some of the
complexities of using these interfaces. SOAP enables applications to call
functions from other applications, running on any hardware platform, regardless
of different operating systems or programming languages.

SOAP calls are much more likely to get through firewall servers, since HTTP is
typicallyPort 80 compliant, where other calls may be blocked for security
reasons. Since HTTP requests are usually allowed through firewalls,
programs using SOAP to communicate can be sure that the program can
communicate with programs anywhere
Some of the advantages of leveraging SOAP include:

It is platform and language independent.

SOAP provides simplified communications through proxies and firewalls,

as mentioned above.

It has the ability to leverage different transport protocols, including HTTP

and SMTP, as well as others.

Some disadvantages of leveraging SOAP include:

SOAP is typically much slower than other types of middleware standards,

including CORBA. This due to the fact that SOAP uses a verbose XML
format. You need to fully understand the performance limitations before
building applications around SOAP.

SOAP is typically limited to pooling, and not event notifications, when

leveraging HTTP for transport. What's more, only one client can use the
services of one server in typical situations.

Again, when leveraging HTTP as the transport protocol, there tends to be

firewalllatency due to the fact that the firewall is analyzing the HTTP
transport. This is due to the fact that HTTP is also leveraged for Web
browsing, and many firewalls do not understand the difference between the
use of HTTP within a Web browser, and the use of HTTP within SOAP.

SOAP has different levels of support, depending upon the programming

language supported. For example, SOAP support within Python and PHP
is not as strong as it is within Java and .NET
 The Web Services Description Language (WSDL) is an XML-based
language used to describe the services a business offers and to provide a
way for individuals and other businesses to access those services
electronically

UDDI stands for Universal Description, Discovery, and Integration. The UDDI Project is an industry
initiative aims to enable businesses to quickly, easily, and dynamically find and carry out
transactions with one another.

A populated UDDI registry contains cataloged information about businesses; the services that they
offer; and communication standards and interfaces they use to conduct transactions.

Built on the Simple Object Access Protocol (SOAP) data communication standard, UDDI creates a
global, platform-independent, open architecture space that will benefit businesses.

The UDDI registry can be broadly divided into two categories:

UDDI and Web services

UDDI and Business Registry

UDDI and Web Services

The owners of Web services publish them to the UDDI registry. Once published, the UDDI registry maintains
pointers to the Web service description and to the service.

The UDDI allows clients to search this registry, find the intended service, and retrieve its details. These details
include the service invocation point as well as other information to help identify the service and its
functionality.

Web service capabilities are exposed through a programming interface, and usually explained through Web
Services Description Language (WSDL). In a typical publish-and-inquire scenario, the provider publishes its
business; registers a service under it; and defines a binding template with technical information on its Web
service. The binding template also holds reference to one or several tModels, which represent abstract
interfaces implemented by the Web service. The tModels might have been uniquely published by the provider,
with information on the interfaces and URL references to the WSDL document.

A typical client inquiry may have one of two objectives:

To find an implementation of a known interface. In other words, the client has a tModel ID and seeks
binding templates referencing that Model.
To find the updated value of the invocation point (that is., access point) of a known binding template
ID.
UDDI and Business Registry
As a Business Registry solution, UDDI enables companies to advertise the business products and services they
provide, as well as how they conduct business transactions on the Web. This use of UDDI complements
business-to-business (B2B) electronic commerce.

The minimum required information to publish a business is a single business name. Once completed, a full
description of a business entity may contain a wealth of information, all of which helps to advertise the
business entity and its products and services in a precise and accessible manner.

A Business Registry can contain:

Business IdentificationMultiple names and descriptions of the business, comprehensive contact

information, and standard business identifiers such as a tax identifier.
CategoriesStandard categorization information (for example a D-U-N-S business category
number).
Service DescriptionMultiple names and descriptions of a service. As a container for service
information, companies can advertise numerous services, while clearly displaying the ownership of
services. The bindingTemplate information describes how to access the service.
Standards ComplianceIn some cases it is important to specify compliance with standards. These
standards might display detailed technical requirements on how to use the service.
Custom CategoriesIt is possible to publish proprietary specifications (tModels) that identify or
categorize businesses or services
Service Architecture
Web Services Explained
First, Web Services using SOAP, REST, and JSON are discussed. This is followed by a history
of Web Services covering the Web Services Description Language (WSDL) and Universal
Description, Discovery, and Integration (UDDI).

Web Services Specifications

Three specifications for Web Services are illustrated in this section: SOAP, REST, and JSON.

SOAP
SOAP was originally part of the specification that included the Web Services Description
Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). It is used
now without WSDL and UDDI. Instead of the discovery process described in the History of the
Web Services Specification section below, SOAP messages are hard-coded or genereated
without the use of a repository. The interaction is illustrated in the figure below. More onSOAP.

Representation State Transfer (REST)

Representation State Transfer (REST) appeals to developers because it has a simpler style that
makes it easier to use than SOAP. It also less verbose so that less volume is sent when
communicating. The interaction is illustrated in the figure below. More on REST.
JavaScript Object Notation (JSON)
While both SOAP and REST use XML for interchange, JavaScript Object Notation (JSON) uses
a subset of JavaScript. This is illustrated in the figure below. More on JSON.

When to Use SOAP, REST, JSON or Other Options

There really is no "best" option for Web Services. Generally, you will use whatever your service
provider supports. If you use multiple service providers, it is easily possible that you will be
using all three Web Services specifications: SOAP, REST, and JSON.
 History of the Web Services Specification
Web Services Description Language (WSDL); Universal Description and Discovery (UDDI);
and SOAP formed the original Web Services specification. This section provides a history.

Web Services Description Language (WSDL)

The Web Services Description Language (WSDL) forms the basis for the original Web Services
specification. The following figure illustrates the use of WSDL. At the left is a service provider.
At the right is a service consumer. The steps involved in providing and consuming a service are:

1. A service provider describes its service using WSDL. This definition is published to a repository
of services. The repository could use Universal Description, Discovery, and Integration (UDDI).
Other forms of directories could also be used.
2. A service consumer issues one or more queries to the repository to locate a service and determine
how to communicate with that service.
3. Part of the WSDL provided by the service provider is passed to the service consumer. This tells
the service consumer what the requests and responses are for the service provider.
4. The service consumer uses the WSDL to send a request to the service provider.
5. The service provider provides the expected response to the service consumer.

More on Web Services Description Language.

Universal Description, Discovery, and Integration (UDDI)

The repository shown in the above figure could be a UDDI registry. The UDDI registry was
intended to eventually serve as a means of "discovering" Web Services described using WSDL.
The idea is that the UDDI registry can be searched in various ways to obtain contact information
and the Web Services available for various organizations. How much "discovery" was ever used
is open to discussion. Nevertheless, even without the discovery portion, the UDDI registry is a
way to keep up-to-date on the Web Services your organization currently uses. It can be used at
design time and with governance. An alternative to UDDI is the ebXML Registry. More
on Universal Description, Discovery, and Integration.

SOAP
All the messages shown in the above figure are sent using SOAP. (SOAP at one time stood for
Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning .)
SOAP essentially provides the envelope for sending the Web Services messages. SOAP
generally uses HTTP , but other means of connection may be used. HTTP is the familiar
connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that
will help drive the adoption of Web Services. More on SOAP and Messaging.

The next figure provides more detail on the messages sent using Web Services. At the left of the
figure is a fragment of the WSDL sent to the repository. It shows a CustomerInfoRequest that
requires the customer's account to object information. Also shown is the CustomerInfoResponse
that provides a series of items on customer including name, phone, and address items.
At the right of this figure is a fragment of the WSDL being sent to the service consumer. This is
the same fragment sent to the repository by the service provider. The service consumer uses this
WSDL to create the service request shown above the arrow connecting the service consumer to
the service provider. Upon receiving the request, the service provider returns a message using the
format described in the original WSDL. That message appears at the bottom of the figure.

XML is used to define messages. XML has a tagged message format. You can see this in the
SOAP and REST examples in the first section and in the figure above. In each of the examples,
the tag <city> has the value ofBurnsville. And </city> is the ending tag indicating the end of the
value of city. Both the service provider and service consumer use these tags. In fact, the service
provider could send the data shown at the bottom of this figure in any order. The service
consumer uses the tags and not the order of the data to get the data values. More on the use of
XML tags and a comparison of XML to using fixed record formats can be found in chapter 3
of Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's
Guide. Also see XML Processing for an overview of the XML processing in a service.

Service-Oriented Architecture (SOA)

Definition
A service-oriented architecture is essentially a collection of services. These services
communicate with each other. The communication can involve either simple data passing or it
could involve two or more services coordinating some activity. Some means of connecting
services to each other is needed.

Service-oriented architectures are not a new thing. The first service-oriented architecture for
many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on
the CORBA specification. For more on DCOM and CORBA, see Prior Service-Oriented
Architectures.

Services
If a service-oriented architecture is to be effective, we need a clear understanding of the term
service. A service is a function that is well-defined, self-contained, and does not depend on the
context or state of other services. SeeService.

Connections
The technology of Web Services is the most likely connection technology of service-oriented
architectures. The following figure illustrates a basic service-oriented architecture. It shows a
service consumer at the right sending a service request message to a service provider at the left.
The service provider returns a response message to the service consumer. The request and
subsequent response connections are defined in some way that is understandable to both the
service consumer and service provider. How those connections are defined is explained in Web
Services Explained. A service provider can also be a service consumer.

Also see Web Services Definition, Web Services Explained, and Service-Oriented Architecture
(SOA) and
Services in SOA
Services are the basic building blocks in a Service Oriented Architecture (SOA). This article
examines services in SOA more closely by describing the key characteristics of services in
SOA, discussing the different types of services in SOA, and explaining where services
reside in the different SOA layers.

What is a Service in SOA?

A service is a self-contained unit of software that performs a specific task. It has three
components: an interface, a contract, and implementation. The interface defines how a
service provider will perform requests from a service consumer, the contract defines how
the service provider and the service consumer should interact, and the implementation is
the actual service code itself. Because the interface of a service is separate from its
implementation, a service provider can execute a request without the service consumer
knowing how it does so; the service consumer only worries about consuming services.

In a service oriented architecture, services can be combined with other available services in
a network through service orchestration to create higher-level composite services and
applications. A service is reusable, non-context specific, stateless, and can be dynamically
discovered across the enterprise, in partner systems, or in the cloud. These characteristics
enable services to be loosely coupled, resulting in new applications that are designed
according to SOA principles.

Services can be derived from existing IT assets or created from the ground up by writing
new code. In the former approach, also known as service enabling, business logic, data,
and other existing assets in legacy systems are transformed into services, which can then
be invoked by other services to create composite services and applications. Enterprises
looking to implement SOA should ideally begin by leveraging their existing assets to create
services, but developing new services from scratch is sometimes required in particular
circumstances.

An important point to bear in mind when creating a service in SOA is granularity. A course-
grained service includes more functionality (i.e. more operations) than a fine-grained
service, which includes less functionality (i.e. fewer operations). The granularity of a service
will vary depending on its purpose, but a poorly grained service results in low reuse
possibilities and the misalignment of enterprise systems with business objectives.

Types of Services in SOA

There are several types of services in SOA, which are divided into two categories: Business
Services and Infrastructure Services.

Business Services are services that perform specific business functions and are required for
the successful completion of a business process. They might also be called Application
Services since they are used to develop composite services and business applications that
automate business processes. For example, a retail enterprise might have an Inventory
Service, Customer Management Service, and Shipping Service in its repository of
business services.

Business Services can be further divided into Entity Services, Capability Services, Activity
Services, and Process Services. Entity Services are the data-centric components of the
enterprise system and are responsible for exposing the information stored in backend
databases. They can be thought of as the nouns of the business process. Capability
Services and Activity Services, meanwhile, are the verbs. They are the action-centric
components that implement business capabilities. Whereas Capability Services are coarse-
grained and provide generic business capability, activity services are more fine-grained and
provide specific business capability. Rounding out the business services category are
Process Services, which contain the business logic and couple the Entity Services and
Activity and Capability Services via service orchestration to create composite business
services.

The other main category of services is Infrastructure Services, which are part of a centrally
managed infrastructure component such as an Enterprise Service Bus (ESB). Infrastructure
Services provide the technical functionality necessary for the implementation of business
processes in SOA, but do not directly add business value. Examples of Infrastructure
Services include SaaS Integration Services, Authentication Services, Event Logging
Services, and Exception Handling Services.

Infrastructure Services are further divided into Communication Services and Utility Services.
Communication Services are mainly concerned with transporting messages both within and
without the enterprise while Utility Services provide other technical capabilities not related to
message transfer.

Although there are several approaches to categorizing the different types of services in
SOA, the main distinction to remember is the one between Business Services and
Infrastructure Services. Infrastructure Services are agnostic and have greater reuse
possibilities while Business Services directly translate into business processes. The reuse
possibilities of Business Services will vary depending on how they are designed.

Services in SOA Layers

To get a better sense of the role of services in SOA, you can think of SOA in terms of
abstract layers:

Enterprise Layer

Process Layer

Service Layer

Component Layer

Object Layer

The first layer, the Object Layer sits at the bottom and consists of legacy systems, including
custom-built applications and databases that contain business functionalities. These legacy
enterprise objects can be leveraged to build composite services - proof that SOA doesnt
have to mean rip and replace. Just above the Object Layer is the Component Layer
consisting of enterprise components. These components are responsible for realizing the
functionality of services.

The middle layer is the Service Layer, which is where exposed services (both individual and
composite services) carrying out business functions reside. The Service Layer acts as a
bridge between the lower-level layers (the Object Layer and Component Layer) and the
higher-level layers (the Process Layer and Enterprise Layer). Enterprise components can
be exposed as services in this layer, making reuse a real possibility.
Next is the Process Layer. Here, the services exposed in the Service Layer are combined
through service orchestration or service choreography to create a single application that
realizes and automates a business process. The final layer is the Enterprise Layer (also
known as a Presentation Layer), which is the end-users point of access to the composite
enterprise application, typically over the Internet.

As the layered abstraction above makes clear, services play a fundamental role in SOA. For
enterprises facing integration challenges and looking to increase business agility in meeting
customer demands and to cut IT costs, SOA doesnt have to be difficult to understand. As
long as business leaders understand what services are (and their different types) and how
each layer contributes to building new applications, SOA becomes less foreign as a concept
and instead becomes a mission-critical IT goal waiting to be realized.