B Ildi Soa C Ita Li Ti Building Soa Composite Applications

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2015, Oracle and/or its affiliatesฺ
B ildi SOA C
Building Composite
it AApplications
li ti
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
Copyright licOracle and/or its affiliates. All rights reserved.
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no
Objectives
After completing this lesson, you should be able to:

• Describe the basics of XML, XSD, and WSDL

• Explain in general terms the fundamental principles of
service design
• Describe the structure of SCA composite application
• Explain how to implement a SOA composite application in
JDeveloper a
h a s
m ) ฺ
o
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no
Oracle SOA Suite 12c: Essential Concepts 4 - 2

Roadmap
• Basics of XML
• Composite applications and service components according

to Service Component Architecture (SCA)
• Principles of service design
• Getting started with SOA composite application
implementation in JDeveloper
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no

What Are Services?
Services are:
• Building blocks for a SOA-enabled application

• Functionality-described standard interface and message
structure definitions
• Accessed using standard protocols (the glue) to enable
interoperability from decoupled functions
Web Services Description Request message defined in an XSD WSDL
s a
Language (WSDL)
)h ฺa
m
co uide
l e ฺ
Interactions
o rac ent G
a n @ tud
Client Service
i - x u is S Service
ฺ bu defined e tinhan XML Schema Document (XSD)

n
oa to us
Response message
( h
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
Services i
u are-business
r n functions that form the foundation for building applications by using a
aSOA
Bapproach. t
noofnrelated services, by reusing other services to complete automation of a business
SOA applications can be thought of as functionality that aggregates a
collection
process.
Service functionality must be described by using standard interface and message structures
to make them highly accessible and reusable. Although the IT industry has created many
ways to do this, each of which is a viable means to accomplish a SOA approach, the most
widely embraced are the web services standards that include:
• Extensible Markup Language (XML) for metadata
• Web Services Descriptionp Language
g g ((WSDL)) for service interface definition
• XML Schema Documents (XSD) for message structure definition
The benefit of using web services artifacts such as WSDL and XSD, which are XML-based
documents, is that they are “accepted standards.” These XML document structures are easily
exchanged using standard Internet (web services) protocols, such as Hypertext Transfer
Protocol (HTTP).
The ability to access information and service using standard document structures, message,
and protocols is that they form a consistent layer or glue between decoupled systems that
enable a high degree of interoperability regardless of the choice of operating system and
computer languages used for service implementation.

Basics of XML
eXtensible Markup Language, or XML:

• Is self-describing
• Is extensible
• Can use a Document Type Definition (DTD) or XML
schema to formally describe the data
• Is used for two purposes:
– Document-oriented applications a
a s
– Data-oriented applications
m )h ฺ
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
XML isu i
an
r a n
extensible, nonproprietary, text-based markup language that has become the de
B
facto standard t
- for data interchange on the Internet and within distributed applications and web
non
services.
• XML defines a set of tags that are used to organize and describe data.
• XML is self-describing. XML organizes data into a hierarchy, and it describes its
organization directly in the text, so you do not need to look at a separate document that
describes the organization of the data.
• XML allows the authors to define their own tags and their own document structure. So
you can extend XML almost limitlessly, defining markup and rules as needed for the
ki d off d
kinds data
t and d iinformation
f ti ththatt you use.
• XML uses DTDs to define the rules that specify the elements, element formats, and
attributes that are valid in a document instance, as well as the rules defining the
relationships between those elements. A DTD provides a basic grammar for defining an
XML document in terms of the metadata that comprise the shape of the document. An
XML schema provides this, plus a detailed way to define what the data can and cannot
contain.

• XML implementations can be divided into two general categories: document-centric and
data-centric:
- Document-centric XML refers to documents intended for human consumption, but
which can still be p
processed p
programmatically,
g y, and are based on structured or
semi-structured markup. Examples include technical documentation, product
catalogs, and legal documents.
- Data-centric XML refers to highly structured XML files intended for machine
consumption rather than human readability. Examples of this kind of XML include
programmatic structures, and data from relational databases.
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

XML Concepts
• Namespaces: To interpret the tag in the proper context

• XML schema (XSD): To validate the integrity of XML

documents
• XPath: A language used for addressing (finding
(finding, retrieving
retrieving,
or manipulating) values in XML sources
• XML Stylesheet Language for Transformations (XSLT): A
language used for transforming data from one XML
structure to another s a
h
)and a
• XQuery: A language designed for querying (finding c m
o ideฺ
ฺ
cle t Gand
extracting elements and attributes), transforming,
r a u
accessing XML and relational datan@o den
u a S tu
x
ui- e this
n ฺ b
h o a
t o us
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
s f er and technologies include:
uXML concepts
i
u -tran Namespaces are categories for ensuring that names in an XML
The primary
• BNamespaces:
non are unique in that document. When duplicate element names exist in a
document
document, the result is a namespace collision. The W3C namespace specification
defines mechanisms for qualifying the names so as to eliminate ambiguity—that is, to
provide unique names for all elements and attributes. An XML namespace provides a
qualified name for an XML element or attribute.
A namespace is an attribute=value pair just below the prolog in an XML document, and
uses the syntax: namespace:attribute=URI
Here is the example of a namespace declaration:
xmlns:java http://www.javasoft.com/2006/software
xmlns:java=http://www.javasoft.com/2006/software
• XML Schema: An XML schema is an XML document that defines the syntax of XML
documents governed by the schema. The element in an XML instance document has to
comply with the XSD definition to be considered valid by XML processors. Data types in
schemas have two general forms: simple and complex. Simple is a terminal element;
complex contains a sequence of child elements.

• XPath: XPath is a language designed to address specific parts of an XML document.
XPath models an XML document as a tree of nodes. The types of nodes include
element nodes, attribute nodes, and text nodes. Using XPath, we construct an
expression (location path) that accesses a node or set of nodes. XPath is a major
element in W3C’s XSLT standard. See http://www.w3.org/TR/xpath for the specification.
• XSLT: XML documents represent data, organized in some predefined, structured way.
Sometimes, data in XML documents needs to be transformed before it can be sent or
processed. Source and target documents are generally based on different XSD
documents. XSLT is a language that defines the XML elements and attributes to
produce and the values for these to write, usually queried from the source document.
Data is queried from the source document by using XPath expressions.
• XQuery: XQuery is the W3C standard language designed for querying, transforming,
and accessing XML and relational data. XQuery is similar to SQL in many ways. As SQL
is designed for querying structured, relational data, XQuery is designed especially for
querying unstructured, XML data from a variety of data sources.
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

Web Services Description Language (WSDL)
• A WSDL document describes:

– What the service does WSDL document

– How the service is accessed
Types
– Where the service is located
• It defines the messages and Messages
the operations of a service
abstractly in XML. Port types
s a
a
)h ฺ
Bindings m
Described by
l e ฺco uide
c tG
raServices
@ o d e n
x u an Stu
Service interface
ฺ b ui- e WSDL this document structure
o a n us
( h t o
u an ense
u i-X le
© 2014,
n B ab
a r
u sfe way of transporting messages for use by web services, whereas
i-X raa nstandard
SOAPuprovides
B provides
WSDL
o n -t a standard way to describe web services. WSDL uses the XML format for
n the service interface with a number of functional (what functionality a service
describing
offers) as well as more technical aspects (how it communicates, and where it is accessible) of
the contract. Because WSDL is in the standard XML format, the services developed can
easily be made available to thousands of users. Users must invoke the correct services with
the appropriate parameters. WSDL defines an XML grammar to specify the location of the
service and to describe the operations of a service.
A WSDL document describes a web service by using these major elements:
• <types>: Defines the data types used by the web service
• <message>: Describes the payload of a message used by a web service
• <portType>: Describes a web service, the operations that can be performed, and the
messages that are involved
• <binding>: Defines the communication protocols used by the web service
• <service>: Describes the name and location of the web service and the context with
which it can be accessed
Note that types, message, and portType are abstract types that are then used in bindings and
services in much the same way an instance of a Java class represents a Java class.

WSDL Model
XML Elements
Definition attributes
targetNamespace
Type Message PortType Binding Service

name name name name
type
Schema Part Operation SOAPBinding Port

name name style name
transport binding
s a
Input )h ฺ a
m
message
l e ฺco uAddress
ide
Element c
ra ent G location
name
Output
@ tud o
type
message
a n
u i -xu this S
What
a n ฺb se How Where
u
n (ho se to
u a en
u X
i- le
© 2014,
n B ab
- X
a f er
u asstructural
u i
The slide provides
r a n model of the WSDL specification. The different sections in the
B
WSDL model t
n- break down into the following software engineering practices:
n
• What:
oat Thiss section
sect o desc
describes
bes tthe
e se
service
ce requirements
equ e e ts a and d its
ts functionality.
u ct o a ty Itt desc
describes
bes
the relevant message types and their association with the service operation’s input and
output parameters. Within a Type, the Schema describes the Messages to be passed
through the interface (as parameters or documents). Messages are data to be
exchanged via the interface Operations (the input and output parameters of the
interface). The PortType is the element that contains the interface that declares the
available operations.
• How: This section describes the service design and the service invocation pattern
pattern. The
Binding element is used to describe the fact that the specific operations in the service
are callable via a specific protocol binding and data format. The Binding element links a
portType to a protocol and a style of message formatting.
• Where: This section describes the service implementation and the runtime environment.
The Service element assigns physical address details to each of the Binding elements in
the document.

Abstract WSDL vs. Concrete WSDL
WSDL Definition
Types
Abstract
Messages
Section
Port types
s a
a
)h ฺ
m
Bindings
Concrete
l e ฺco uide
Section orac nt G
Services
a n @ tude
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
uWSDL contains
s f er
u i
An abstract
r a n the appropriate namespace, schema imports, message types,
B - t
and port information. A concrete WSDL is a copy of the abstract WSDL and adds the machine
non details, such as the host, port, and location of the physical service. An
endpoint–specific
abstract WSDL definition cannot be used to connect to the web service due to the “missing
information” on where and how the service is exposed.
Services can be created strictly with the concrete WSDL, which leverages the abstract WSDL
for design-time definition. This allows the services to:
• Be developed before the actual implementation system is known
• Define their dependent structures before the dependent services are available in the
case off service start-up ordering
This fully decouples the service’s design and deployment. The developer designs the service
based on the abstract WSDL.

Defining Service Interfaces with WSDL
• Service interfaces should be defined before developing

services.
• When defining service interfaces by using WSDL, you
specify:
p y
– Operations that may be executed
– Message structures for communicating the required data for
each operation
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
u a fer you need to have defined the interface of that service. This is the
i-X ranasservice,
Beforeudeveloping
keyB
o n -t
of the commonly accepted “WSDL first” approach to designing web services. Defining the
serviceninterface before development is important to establishing a highly standardized SOA
and is required to realize a number of the characteristics identified as being part of SOA.
When defining a service interface by using WSDL, you need to specify:
• Operations that may be executed. The interface of a service defines a set of public
operation signatures.
• Message structures for communicating the required data for each operation. Message
structures are based on types expressed in an XML schema (XSD) document.

Defining Service Interfaces with WSDL Editor
WSDL interface
operations and messages
s a
a
)h ฺ
m
l e ฺco uide
WSDL components that
o racyouent G
can drag to the
a n @WSDLdocument
t ud
editor
to create
i u
-x this
the WSDL S
u
ฺb se
o a n u
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a
u or modify
s f er
You can
u i create
r a n the WSDL document in JDeveloper by using the WSDL editor tool.
B t
- gives you a design view of the WSDL document that enables you to
The WSDLneditor
nothe different sections of the WSDL document (such as, services, bindings, and
segregate
port types) into a hierarchical structure. You can expand the tree of a specific section and
can add, modify, and delete specific nodes in the WSDL document. You can also change the
values of different nodes by selecting any node to modify its value in the Properties pane.

Defining Message Structure with XML Schema
XML schema (XSD) is used to define the message structure of

a service interface (in WSDL). XSD:

• Is an XML language that defines and validates
the structure of XML documents
Validates
• Is stored in an XSD document XSD
Defines
• Defines elements and types, such as: types
– Simple type definitions
s a
– Complex type definitions a
)h ฺ
m
– Element declarations WSDL ฺco uide
References
l e
– Attribute declarations
o rac ent G Instance
• Supports XML namespaces and a @ simple
built-in
n tud and
complex data types i u
-x this S
u
ฺb se
o a n u
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
Message
u i structures
r a n a service interface are based on types expressed in an XML Schema
of
B
Document n - t
(XSD).
n o
The W3C XSD language is an XML language (or vocabulary) used in an XSD document for
describing and constraining the content of XML documents. The XSD is used to validate the
structure of an XML document.
An XML document whose structure is based on the definitions in an XML schema is called an
instance document of that XML schema. The slide shows an XML schema document stored
separately from the XML instance document that it describes and validates.
The introduction of the XML schema allowed XML technology to represent data types in a
standard format. The data types give a precise way of specifying the type of content that can
be held in elements and attributes of an XML document.
In a SOA environment, XSDs are very important to ensure that messages exchanged during
interactions between service consumers and providers are consistent, well-formed, and valid
structures. In fact, WSDL message types are defined in terms of XSD elements and types to
ensure a high degree of consistency and visibility between a service and the client invoking
the service.
service

Defining Message Structure with XSD Editor
Input
type a
a s
m )h ฺ
l e ฺco uOutput
ide
c
ra ent G type
@ tud o
a n
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u an XML s f er
You can
u i create
r a n schema by using JDeveloper. You can visually insert or modify the
B
XML elements t
- (such as complex types and elements) by using the JDeveloper XSD Visual
Editor. n oncan
You insert an XML node (such as an element, a complex type, and a simple type)
by right-clicking any existing node and selecting one of the following options—insert before
element, insert inside element, or insert after element—and thereby selecting the appropriate
node to insert. You can modify an existing node by double-clicking a specific node and
modifying its value.
For example, the XML schema (CreditService.xsd) is defined with XML complex types
and XML elements. The complex type CreditCardT is intended to handle the input
operation type (method parameter)
parameter), and the elements—valid
elements valid and error are intended to
error—are
handle the output operation type (method return type) of the web service logic (implemented
using a Java method).
Note: The graphic is an example and does not represent the specific implementation used in
the course example, which in fact uses the valid xsd:boolean element to indicate whether
the credit card is valid or not. The XML schema definitions provide elements that you intend to
use as entities or data structures that may be exchanged in interactions with the web service.

XPath
• Treats XML documents as trees of nodes

• Uses path expressions and conditions to select nodes or

node-sets in an XML document
• Is a fundamental component of XSLT and XQuery
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
a
u standardf er
XPathuisi-aXW3Ca n s language used for finding information in an XML document. XPath
B
models an n t r
- document as a tree of nodes, and expresses a navigation path through the
XML
no structure of an XML document. XPath can be used by itself, but is often used in
hierarchical
conjunction with XSLT and other XML topics, such as XQuery and XPointer. The result of the
XPath can be a collection of nodes. It does not need to be a unique node.

XPath Examples
Document root node /

Root element node departments

Attribute node
department Num="1" department Num="2"
department_id department_name department_id department_name
s a
HR)
h a
10 Finance 20
c m
o ideฺ
ฺ
r a cle t Gu
Text nodes
@ o den
Examples:
x u an Stu
•
ui- e this
/departments/department/department_id
ฺ b
• n
/departments/department[@Num=“1”]
o a us
( h t o
u an ense
u i-X le
© 2014,
n B ab
a r
u
i-X rananXML
XPathumodels sfedocument as a tree of nodes. The graphic in the slide depicts the
B types
different
o n -t of nodes as seen by XPath in an XML document.
n
The examples mean:
• /departments/department/department_id: Select the department_ids of all department
elements that are the children of the departments element.
• /departments/department[@Num=“1”]: Select the department that has a Num attribute
whose value is “1.”

Data Transformation with XSLT
Output
Input XML XSL document
document processor (HTML, XML,

text)
XSL
stylesheet
s a
a
)h ฺ
m
co Output
Matching
<?xml version="1.0"?>
c l e ฺ u ide
data
rule
<xsl:stylesheet ...>
o ra ent G
<xsl:template match="XPath"/>
a n @ tud
 S
u
ฺb se t
</xsl:template> h
o a n
</xsl:stylesheet> u
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a
u have s f er
u i
XML documents
r a n structure and, unlike HTML, do not provide formatting or display
B
instructions. t
n-XSL adds the capability of transforming an XML document into another
nocontaining
document XML with a different structure or an HTML document with formatting
tags.
XSL has the following parts:
• XSL Transformations (XSLT) is an XML application that processes rules contained in an
XSLT stylesheet. The rules in an XSLT stylesheet can be applied to any XML document.
• The XSL Formatting Objects (XSL-FO) is an XML application that is used for describing
the precise layout of text on a page. XSLT is used to generate XSL-FO elements that
are output to another XML document. Additional processing is needed to create the final
f
output form, such as a portable document format (PDF) document.
Usually XSLT specifies transformation rules in elements with attributes that use XPath
expressions.

Defining Transformations with XSLT Map Editor
View of
created XSLT
drop
s a
a
)h ฺ
m
co uide
XPath drag
l e ฺ
rac ent G
expressions and
Source tree:
incoming source
functions that
@ tud o
can be mapped
a n
-xu this S
XML document to XSLT
elementsui
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u and s f er
u i
To create, design,
r a n test data transformations between source schema elements and target
B t
n- JDeveloper provides a build in XSLT Mapper, which simplifies the mapping
schema elements,
noconsiderably.
definition
In the XSLT Map Editor, you can edit XSLT stylesheets using a graphical editor, and you can
directly edit the XSLT source.

XQuery
• Applications of XQuery:
– XML querying
– XML generation
– XML transformation
• By using XQuery, you can query both structured and
unstructured data.
• XQuery is built on XPath expressions.
s a
A simple XQuery: a
)h ฺ
m
doc("code_08_dept.xml")/departments/department[department_name l e ฺco uide
='Purchasing']
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
XQuery
u iis designed
r a n query XML data from both XML files and relational databases. Just as
to
B
SQL is the n t
- language for structured data expressed as relational tables, XQuery is
query
noto work with the XML data model and be a comprehensive query language for data
designed
that is expressed in XML. You can use a single XQuery on multiple and heterogeneous data
sources to transform the query result into new XML data.
XQuery consists of a set of possible expressions that are evaluated and return values (which,
for XQuery, are sequences).
XQuery is used to query, generate, and transform XML content.
• XML querying: XML can map a large number of different data models. XQuery thus
provides a mechanism for extracting information from relational databases,
databases files,
files and
web services simultaneously.
• XML generation: XQuery enables you to construct XML data by using the result of a
query.
• XML transformation: XQuery can construct XML as a result of evaluating a query
expression, in many cases more expressively and efficiently than XSL Transformations
(XSLT). XQuery enables you to scan a hierarchy of elements. You can use it to apply
transformations at each level of the hierarchy by defining a recursive function
function.
Example: The slide displays a simple XQuery that selects all the department nodes from the
code_08_dept.xml document, where department_name equals Purchasing. The doc()
function is used to specify the XML document that you want to query.
XSLT vs. XQuery
• Similarities:
– XPath
– Data model
– Functions and operators
• Differences:
– Syntax
— XQuery is similar to SQL.
XSLT stylesheets use XML syntax. s a
—
a
)h ฺ
– Performance o m
XSLT loads the entire input document in thecmemory. l eฺc Guide
rato beeused
—
XQuery loads only the objects that needs o n t by the

—
current statement. a @
n Stud
i u
-x this
u
ฺb se
o a n u
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a
u XQuerys f er
Both XSLT
u i and
r a n are languages designed to query and manipulate XML documents.
B
Their features t
- and capabilities have lots of overlap. The slide lists the similarities and
nonbetween them.
differences

Roadmap
• Basics of XML

s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no

Service Component Architecture (SCA)
• Intention: Simplify the creation and integration of business

applications that conform to the principles of Service-

Oriented Architecture
• Principle:
p Divide the application
pp into components
p that
implement (service-oriented) business interfaces
– Separation of business logic and communication
management
– Independent of programming language or underlying s a
implementation ) ฺh a
o m
– Independent of host container technology leฺc
c u ide
– Recursive composition o ra ent G
a n @ tud
– Security, transaction, and reliability
u modeledS as policies
u i -x this
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u generally
s f er
A SOAu i
application
r a n consists of a set of software components working together. All of
B t
- might be built using the same technology, or they might use different
these components
non
technologies. Moreover, these software components might reside in the same machine or
spread across an enterprise.
Service Component Architecture (SCA) defines an approach to create software components
and a mechanism for describing how these components work together.
The SCA consists of a set of specifications that define a model for building SOA applications.
These specifications are based on the following design principles:
• Loose coupling between components
• Independent of programming language or underlying implementation
• Independent of host container technology
• A composite nesting another composite
• Security, transaction, and reliability modeled as policies

Components and Composites
Service Reference
Composite 2
Composite 1 Component Component Composite 3

X Y
Wire Wire Wire
s a
Implementation a
)h ฺ
m
l e ฺco uide
BPEL Java Others o rac ent G
a n @ tud Domain
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
The SCA
u i n describe an SCA application in terms of components and composites.
specifications
r a
B
Components t
-are the atoms that enable the creation of an SCA application. The SCA
non are an instance of an implementation (the code that provides the component’s
components
function) that behaves in consistent ways, and they can be assembled into different
configurations. For example, in a simple application, the components could be Java classes
running in a single process, and their interactions might rely on Java interfaces exposed by
those classes. In a complex application, there might be a few components implemented as
Java classes, others written in C++, and still others defined using BPEL, all spread across a
group of machines.
A composite is a logical construct of a group of components
components. Its components can run in a
single process on a single computer, or be distributed across multiple processes on multiple
computers. A complete application might be constructed from just one composite, or it could
combine several different composites.
A service is the entry point to a composite. Components also depend on services provided by
other components—these dependencies are called references. Also contained in the
composite are the linkages between references and services, represented by wires.
SCA composites are deployed within an SCA domain. An SCA domain represents a set of
services providing an area of business functionality that is controlled by a single organization.
A single SCA domain defines the boundary of visibility for all SCA mechanisms.

SCA Components
A component:
• Configures an implementation instance within a composite

• Provides services and consumes services (references)
• Publishes a contract that describes its interface through a
WSDL document
• Sets references by wiring them to services:
– Provided by other components
– Provided by references of the composite s a
a
)h ฺ
Property
p y References
m
l e ฺco uide
Component
r a c tG
Service Interface Component
@ o
Component d e n
Types:
x u an BPEL S tuProcess
Appears as a
<component> element in ฺ b ui- e this Human Mediator
Task
the composite.xml file o a n u s Business Rules
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a
uhold pieces
s f er
u i
Components
r a n of a program function within a composite. Components are
B
configuredn - t
instances of some implementation, such as BPEL, Java, or other implementation
noimplementation code defines the services, references, and properties that are
logic. The
configured by a component within a composite. More than one component can use the same
implementation.
The “component interfaces” are visible (as WSDL) to internal components to enable them to
interact with each other (and build the assembly model through wires). The interfaces can
also be made visible externally by publishing the component interface in a WSDL form that is
shared with target callers of the composite application.
Each SCA component is identified by a <component> t element in the SCA descriptor
descriptor. The
<component> element identifies the component type and the location of the component
source.

SCA Composite
A composite application:
• Defines an assembly model that is stored in an SCA

descriptor file called composite.xml
• Deploys as a single application unit
Composite
• Runs in a single container property
Internal reference Component

and wire property
s a
)h ฺ a
m
l e ฺco uide
o rac ent External
G Service
a n @ tud reference
Composite application Component u i -xu this S

service entry point n ฺb se
(implementations)
a
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
u i
A composite is
r n in terms of the service components implementing and using services
defined
a
B n- t
and the connections that linked them together. A composite defines components and
noimplementation
reference code and describes services and references and the connections
(wires) linking them. Services are a binding type that advertise and provide an entry point for
messages received from the outside world into the composite. References are a binding type
that enables messages to be sent from the composite application to external service partner
links in the outside world. Wires graphically connect entities in a single composite application
for message communication. Service components that can be assembled include:
• BPEL Process, Business Rules, Mediator, Human Task
• SDO service and any web service
Binding styles include:
• SOAP bindings
• SDO bindings
• JCA adapters, among others (RFID, WSIF)
The composite is a service in that it is designed and deployed together as a single application
with its own service interface (WSDL).
(WSDL) The assembly information is stored in an SCA
descriptor called composite.xml, which is a language-independent representation of the
composition of services for a business solution.

Roadmap
• Basics of XML

s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no

Types of Service Access and Implementation
Types of Service Access and Implementation

Created Invoked Created as

Service Service
from existing through new
access access
functionality protocols and functionality
methods
s a
Can be achieved Services can be Can be developed
a
) hby ฺ
m
either by exposing
existing functionality
invoked by using
SOAP over HTTP, l e ฺco BPEL
using service
components,
bus e
u id
a c G
as web services or by JMS adapters, or
@ orservices e n t or web
processes,
using adapters WSIF.
u a n Stwith udJava or Java EE
implemented
u i -x this
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i
Beforeuembarking anon a SOA implementation, business requirements should be identified
B youncan
before - trdesign, identify, or locate services that can support the business need. After
no
the identification task is complete,
p services and their operations
p and messages g can be
specified, thereby creating a “portfolio of services” needed to meet the business requirements.
The implementation for the “portfolio of services” can be chosen from:
• Existing functionality: Is provided by in-house applications already available for use.
Existing application functionality can be exposed through new interfaces and
repurposed for a SOA environment.
• Enterprise Information Systems (EIS) and legacy applications: Have many custom
adapter
d t interfaces
i t f that
th t expose ththeir
i ffunctionality
ti lit as services
i ffor iintegration
t ti purposes
• New applications: Can be developed in languages that support web service standards,
such as Application Development Framework Business Components (ADF BC), Java,
and Java EE, among others. New services can be developed if existing services do not
meet identified requirements.
Invocation of services, whether developed as a web service or exposed through adapters
(using Java Connector Architecture standards) can be invoked using SOAP, Representational
State Transfer (REST), and Web Services Invocation Framework (WSIF) and potentially other
ways.

Service Design Principles
A service is designed based on the following service design

principles:
• Has a well-chosen level of granularity
• Is cohesive and complete
• Encapsulates service implementation details
• Accommodates multiple service invocation patterns
s a
)h ฺa
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a f er
ua logicalsgrouping
u i
A service is
r a n of different service operations published in a standard format.
B t
n- the service based on some of the following service design principles:
You can design
• Se n o
Servicesces sshould
ou d have
a e a well-chosen
e c ose levele e o of ggranularity
a u a ty (t (that
at is,
s, tthe
e number
u be oof
operations a service should have). If granularity is too coarse (grouping together a large
number of operations in a single service), it tends to increase the number of consumers
for the service. Any amendments to some aspect of a service result in rereleasing the
whole service and, therefore, potentially impacting all the service consumers. Moreover,
any extremes in service granularity (either many services with few methods, or few
services with hundreds of operations) tend to impede the maintainability and
consumability of the service.
• Service interfaces should be functionally cohesive, which means grouping a set of
operations in terms of their functionality. You can also use the principle of temporal
cohesiveness, which means grouping service operations that are used together in short
time periods. For example, the operations RetrieveCustomerDetails,
CheckCreditRating, CreateLoanFacility, and TransferFunds might well be
seen in succession in a banking business process. However, that temporary cohesion
does not imply that these operations should be offered by the same service.
service
CheckCreditRating and TransferFunds lack functional coherence.

• The services should also be complete. The issue of completeness is particularly
relevant when creating a service for a known consumer. In this case, the natural
tendency is to focus on meeting the requirements of the consumer. It is important to
remember that services should be reusable and, therefore, their designs must
accommodate the needs of future consumers. For example, suppose that a service
called MobileService offered operations such as create, update, query, delete, and
deactivate. You can well imagine the need to reactivate a deactivated mobile phone,
and so you should decide whether to offer an activate method.

• The service interface should encapsulate the service implementation details, such as
the algorithms and resources used, to increase the decoupling between service
consumer and provider and, therefore, enable flexibility.
• A service can be invoked by implementing different service invocation patterns, such as:
- A traditional, synchronous invocation using SOAP over HTTP
- A asynchronous, message-based invocation using SOAP over Java Message
Service (JMS)
s a
- A local invocation using Java procedure calls h
) ฺa
• m
You need to weigh the options of local versus remote service invocation
invocation, or whether to
o
invoke the service synchronously or asynchronously.
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

Designing Coarse-Grained Interfaces
Coarse-grained interfaces:
• Pass as much useful data as needed for each request

• Return as much useful data as needed with each response
• Define all message structures using an XML schema to
define complex data types for requests and responses
• Limit the number of operations to the fewest possible,
while observing the business requirements and service a
contract definition has ) ฺ
o m
l e ฺc uide
Object Components WebrServicesc
a nt G
@ tudeo
a n
Fine-grained u i is S
-xu thCoarse-grained
interfaces a n ฺb se interfaces
o o u
n (h se t
a
u © 2014, n and/or its affiliates. All rights reserved.
eOracle
i - X
Copyright
u ble l i c
B
u an fera
The level
u X a n s for services depends on their business purpose and interface
i- of granularity
r
B n-tA web service tends to have a coarser granularity compared to components,
requirements.
no
which in turn are coarser than objects. A coarse-grained service exposes a single business
process.
Coarse-grained interfaces are recommended for externally exposed services, enabling:
• Web services to be less “chatty”
• Network overhead and performance to be improved due to fewer invocations
• Client design and development to be simplified
Fine grained services are useful for internal services that support larger services to address
Fine-grained
business process requirements.
Note: Useful data means data that may be needed by a client, or what is needed by a service
to perform the tasks defined by business requirements and its contract (interface). Be
pragmatic to find a balance between the amount of data exchanged and the number of
operations needed. In general, the number of invocations executed has a higher overhead
than the message sizes. It is a best practice to use XML schema design data types for service
operation
ti requestst andd responses.

Roadmap
• Basics of XML

s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no

Developing SOA Composites with JDeveloper
SOA Suite
components
s a
a
)h ฺ
m
l e ฺco uide
SOA Composite o rac ent G
editor
a n @ tud
i -xu Adapters i s S
u
ฺb se t h
o a n u
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a f er
ushows sOracle
u i
This graphic
r a n JDeveloper IDE environment with many design and edit tools that
B t
enable younto- create SOA composite applications and SOA component implementations.
no provides the following tools to develop services for SOA implementations:
JDeveloper
• Composite editor
• BPEL Process Designer
• Mediator Designer
• Rules Designer
• Human Task Designer
• Java web service generator
• Java coding environment
• WSDL Editor
• XSD Editor
• XSLT Mapper
• XQuery Mapper
JDeveloper provides tools to package and deploy your SOA composite applications as
applications to a target runtime environment.

Creating Connections in JDeveloper
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u you cans f er
u i
In JDeveloper,
r a n create connections by using wizards for your development and
B - t
deploymentnenvironments. From the File menu in JDeveloper, select New. The New Gallery
no opens. From the General category, select Connections. The following are the
dialog box
different connections that can be created:
• Application Server Connection: To create a connection to a standalone OC4J,
WebLogic, and so on. This option is always enabled.
• BAM Connection: To create a connection to a BAM server
• BPA Server Connection: To create a connection to a BPA server
• Database Connection: To create a database connection
• File System Connection: To create connections to a local file system
• JMX Connection: To create a JMX MBean server connection
• LDAP Connection: To create a connection to a LDAP directory server
• OEP Connection: To create a connection to an OEP server
• SOA-MDS Connection: To create a connection to a file or database MDS server
• Subversion Repository Connection: To create a connection to a subversion
repository

• UDDI Registry Connection: To create a connection to an internal or external UDDI
registry. This connection can be used for browsing web services.
• URL Connection: To create a connection to a URL
• WebDAV Connection: To create a repository connection to a web-based Distributed
Authoring and Versioning–enabled (WebDAV) server. This connection can be used for
browsing and managing files stored on the server.
• WSIL Connection: To create a connection to a WSIL file or URL. This connection can
be used to browse for web services.
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

SOA Composite Editor
Components are building

Services are blocks that are wired together
entry points to to assemble the application
application. R f
References
the composite enable the
that advertise composite to
capabilities to communicate
the outside with the
world. outside world.
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
The Source tab shows the XML a n @ tud
source.
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
The SOA
u i Composite
r a n editor enables you to create, edit, and assemble services in a composite
B t
- service components are integrated together into one application and
application.nThese
no with the outside world through binding components, such as web services and
communicate
JCA adapters. A SOA composite application can consist of multiple projects (for example, a
SOA project, a web project, and business components project). You deploy the application a
single time into a single runtime environment, instead of deploying components separately to
multiple runtime environments.
The following key elements in the Composite editor directly map to corresponding SCA
elements:
• Exposed services
services, which are the composite service entry points enabling external
clients to interact with the composite
• Components, which form the building blocks of the composite application and provide
business functionality implemented by the component type. Components can be:
- BPEL Process
- Business Rule
- Human Task
- Mediator
- Spring

• External references, which identify services that provide functionality for the composite
to use
• Wires, not shown in the image, which connect elements together to assemble the
pp
application
Components can be exposed as services to an external client, can interact with each other,
and can reference other services. After creating services, components, and external
references, the Composite editor enables you to visually wire elements together to assemble
the application. Wiring involves connecting a service entry point to compatible component
interfaces, one component to another component interface within the composite, and
components to external references. The Source tab enables you to see the XML describing
the composite assembly.
assembly
s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

Creating SOA Suite Components
Create SOA components by dragging the desired component type

from the Component Palette into the Components column in the

Composite editor.
composite.xml is
modified accordingly.
Drag and drop

s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u visuals f er
u i
The slide shows
r a n examples of the different types of SOA Service components that can
B
be added into t
n- the Component area in the Composite editor. The example shown in the
graphicnisonot a complete composite sample, although it does show an instance of a BPEL
component as being exposed as a service—that is, representing the composite service entry
point. For each component dragged into the Components area, the composite.xml file is
modified with the addition of XML elements representing the component and points to an
additional file added to the project folder containing the component type information needed
for composite assembly information.
Note: The composite.xml, which defines the structure of the composite, is located directly
under the SOA folder
folder. In previous releases
releases, this file was just shown as composite
composite.xml.
xml This
became confusing when several composite.xml files from different projects were open at the
same time. In 12c, the project name is displayed in the navigator and in the composite tab
label.

Creating Exposed Services
Exposed services can be created by dragging:

• A service component into the Components area and

selecting the component to expose it as a SOAP service
• A service adapter, such as a file adapter or SOAP web
service adapter
adapter, into the left swimlane
s a
)h ฺa
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a f er
uservice sinterface
i
u -tran
To create a for the SOA composite, you can perform one of the following:
B
nopon e t as a co
• Expose a SOA component in the composite service WSDL by selecting to expose the
component
co composite
pos te service
se ce when e you ccreate eate it. t This s is
s poss
possible
b e for
o BPEL,,
Mediator, Business Rule, Human Task, and Spring components.
• Explicitly drag one of the Service Adapter component types into the Exposed Services
swimlane, and define the desired service entry point details in the component wizard
pages. This is the suggested technique to manually construct a service interface for the
composite application.

Creating External References
References are created in the Composite editor:

• Directly by dragging an Adapter Service item from the

Component Palette into the External References column
• Indirectly
y when creating
g links to services within components
p
Services will come from a
2 service registry.
s a
a
)h ฺ
m
l e ฺco 3uide
o rac ent G
a n @ tud
u i -xu this S
4
a n ฺb se
1
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
u some s f er
The slidei
u -tran typical steps needed to create an external reference.
shows
B
1. A Web n Service item from the Service Adapter list in the Component Palette is dragged
ntoothe
into t e External
te a References
e e e ces co column.
u
2. The Create Web Service Wizard page is used to configure the reference details. Note
that Type is set to Reference (the other option is Service).
3. In the Create Web Service Wizard page, click the SCA Reference Lookup icon to the
right of the WSDL File field. In the SCA Resource Lookup, search for and select the
target external service being referenced.
4. After completing the creation of the web service reference definition, click OK. The
External Reference icon appears in the Composite editor in the External Reference
column.

Creating Wires
Creating wires in the Composite editor:

• Defines the interactions between service entry points,

components, and references
• Represents connections between SCA elements, such as:
– An exposed service wired to a component interface
– A component wired to an external reference
– A component wired to another component interface
• Connects a reference icon with a compatible service interface a
Interface a s
m )h ฺ
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u Create a reference.
(
u an ense
u i-X le
© 2014,
n B ab
u a f er
Note:u i-X canraalso
Wires s
n created when you are creating links to services within component
be
B n- t
implementations.
n o
The slide shows an example of an exposed service wired to a BPEL component, whose
Create Reference icon is dragged to the File Adapter external reference interface to wire them
together. The BPEL process component is already wired to a Mediator component,
completing an end-to-end composite implementation example.

Creating Wires Modifies Connected Elements
The table shows a subset of changes made to components

when they are connected with a wire.
From To Result
Exposed service Component The component interface becomes
exposed as a composite WSDL
interface.
Mediator component Another component Creates a routing rule in the
An external reference Mediator component s a
h a
) BPEL
BPEL component Another component Creates a partner link inm the
ฺ c o ideฺ
An external reference process
r a cle t Gu
@ o den
x u an Stu
ฺ b ui- e this
o a n us
( h t o
u an ense
u i-X le
© 2014,
n B ab
- X
a er
uthe slidesfshows
u i
The table in
r a n some of the implications of wiring a subset of different SCA
B t
- For now—because you have not covered details about each different
elements together.
nonimplementation—the key idea expressed is that some changes made in the
component
composite do affect the source of the associated component.
A wire cannot be made between components that have incompatible interfaces. For example,
a mediator can have only one inbound service. Therefore, it rejects attempts to create a wire
to a second inbound service. Similarly, you cannot connect an inbound web service
configured with a synchronous WSDL file to an asynchronous BPEL process.

Examining the JDeveloper Workspace, Projects,
and File Structure
A SOA application contains a SOA folder that contains all SOA
content. Under this folder is the following content:

• Testsuites
• Schemas
• Transformations (containing
transformation mapper files,
such as XSL files)
s a
• WSDL (containing component a
)h ฺ
WSDL files) m
l e ฺco uide
• Other files such as the BPEL
o rac ent G
component file, .bpel file, and n@ ud
u a S t
the composite.xml file i- x is
n ฺ bu se th
( h oa to u
u an ense
u i-X le
© 2014,
n B ab
- X
a f er
u an sexample
u i
The slide shows
r a n of the content and structure within a SOA application. All content
B t
- to components, such as BPEL processes, Mediator components, and
and files related
non
services, are grouped in the SOA Content folder. As you modify the application, additional
files and folders may be created, depending on the modifications being made.
The Schemas node contains XML schemas generated for the project or XML schemas
imported into the project.
The testsuites folder supports the SOA Test features for the unit and system testing of BPEL
processes with or without the actual services in place.

Managing Shared Data with File-Based MDS
• Problem to be addressed: Share design-time artifacts such

as WSDL, XSD and XQuery files across composites

• How does it work:
– A file-based
file based, design-time
design time MDS repository connection is
automatically included when you create a SOA composite
application.
– /apps is the folder recognized by SOA
for shared data
s a
– Operations supported: ) h a
Export (JAR file) ฺ c om ideฺ
cle t Gu
—
— Import (JAR file) r

o dena
— Transfer an Stu@
x u
ฺ b ui- e this
o a n us
( h t o
u an ense
u i-X le
© 2014,
n B ab
a
u a SOA f er
i-Xcreate
Whenuyou
r a s
n composite application, the default SOA-MDS connection named
B n- t
SOA_DesignTimeRepository is automatically included. The /apps folder in the design-
norepository
time MDS is automatically created. The connection name cannot be changed, but
the default repository location can be modified to point to another folder or source control
location.
You can perform the following operations against the design-time MDS repository:
• Export selected contents of the /apps folder to a JAR file. The /apps folder itself is not
included in the JAR file.
• Import the contents of a JAR file into the /apps folder. If the JAR file includes /apps as
the root folder,
f it is created below the /apps
/ folder
f off the design-time MDS
S repository,
which gives you a top-level directory structure of /apps/apps.
• Transfer the contents of the /apps folder of one MDS repository to another MDS
Repository.

SOA Debugger
SOA debugger:
• Provides a troubleshooting environment in JDeveloper
• Allows you to set breakpoints in a composite for

troubleshooting
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X
a
uand debugs f er
You can
u i test
r a n SOA composite applications with the SOA debugger in JDeveloper.
B -
The SOA debugger t reduces the development cycle for a SOA composite application by
noantroubleshooting environment within JDeveloper. This eliminates the lengthy
providing
process of building a SOA composite application in JDeveloper, deploying it to the SOA
Infrastructure, starting Oracle Enterprise Manager Fusion Middleware Control to test or view
audit trails and flow traces, and then returning to JDeveloper to repeat the exercise. Instead,
you can set breakpoints in JDeveloper for troubleshooting the following components:
• Binding components and service components in SOA composite applications
• Synchronous and asynchronous BPEL processes
• Oracle
O l BPM processes
• Oracle Service Bus pipelines

Summary
In this lesson, you should have learned how to:

• Describe the basics of XML, XSD, and WSDL

• Explain in general terms the fundamental principles of
service design
• Describe the structure of SCA composite application
• Explain how to implement a SOA composite application in
JDeveloper a
h a s
m ) ฺ
o
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
- X u a
s f er
i n
Bu n-tra
no

Practice 4 Overview: Examining the Composite
Application in JDeveloper
This practice covers the following topics:
• Examining the composite application in JDeveloper

• Inspecting the WSDL file describing the service interface
• Populating the SOA
SOA-MDS
MDS repository with source data
s a
a
)h ฺ
m
l e ฺco uide
o rac ent G
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le
© 2014,
n B ab
u a f er
i-X ryou
In thisupractice, a s
n examine the assembly model of the ValidatePayment composite
will
B t
applicationnin- JDeveloper, get familiar with its service interface described in the WSDL file,
nohow to configure a file-based MDS repository used for sharing design-time artifacts.
and learn

s a
h
) ฺa
o m
c l eฺc Guide
o ra ent
a n @ tud
u i -xu this S
a n ฺb se
h o t o u
(
u an ense
u i-X le lic
n B ab
- X u a
s f er
i n
Bu n-tra
no

B Ildi Soa C Ita Li Ti Building Soa Composite Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

B Ildi Soa C Ita Li Ti Building Soa Composite Applications

Uploaded by

Copyright:

Available Formats

Unauthorized reproduction or distribution prohibitedฺ Copyright© 2015, Oracle and/or its affiliatesฺ

After completing this lesson, you should be able to:

• Describe the basics of XML, XSD, and WSDL

Oracle SOA Suite 12c: Essential Concepts 4 - 2

• Composite applications and service components according

Oracle SOA Suite 12c: Essential Concepts 4 - 3

• Building blocks for a SOA-enabled application

ฺ bu defined e tinhan XML Schema Document (XSD)

Oracle SOA Suite 12c: Essential Concepts 4 - 4

eXtensible Markup Language, or XML:

Oracle SOA Suite 12c: Essential Concepts 4 - 5

Oracle SOA Suite 12c: Essential Concepts 4 - 6

• Namespaces: To interpret the tag in the proper context

• XML schema (XSD): To validate the integrity of XML

Oracle SOA Suite 12c: Essential Concepts 4 - 7

Oracle SOA Suite 12c: Essential Concepts 4 - 8

• A WSDL document describes:

– What the service does WSDL document

Oracle SOA Suite 12c: Essential Concepts 4 - 9

Type Message PortType Binding Service

Schema Part Operation SOAPBinding Port

Oracle SOA Suite 12c: Essential Concepts 4 - 10

Oracle SOA Suite 12c: Essential Concepts 4 - 11

• Service interfaces should be defined before developing

Oracle SOA Suite 12c: Essential Concepts 4 - 12

Oracle SOA Suite 12c: Essential Concepts 4 - 13

XML schema (XSD) is used to define the message structure of

a service interface (in WSDL). XSD:

Oracle SOA Suite 12c: Essential Concepts 4 - 14

Oracle SOA Suite 12c: Essential Concepts 4 - 15

• Treats XML documents as trees of nodes

• Uses path expressions and conditions to select nodes or

Oracle SOA Suite 12c: Essential Concepts 4 - 16

Document root node /

Root element node departments

department Num="1" department Num="2"

department_id department_name department_id department_name

Oracle SOA Suite 12c: Essential Concepts 4 - 17

document processor (HTML, XML,

Oracle SOA Suite 12c: Essential Concepts 4 - 18

Oracle SOA Suite 12c: Essential Concepts 4 - 19

XQuery loads only the objects that needs o n t by the

Oracle SOA Suite 12c: Essential Concepts 4 - 21

• Composite applications and service components according

Oracle SOA Suite 12c: Essential Concepts 4 - 22

• Intention: Simplify the creation and integration of business

applications that conform to the principles of Service-

Oracle SOA Suite 12c: Essential Concepts 4 - 23

Composite 1 Component Component Composite 3

Wire Wire Wire

Oracle SOA Suite 12c: Essential Concepts 4 - 24

• Configures an implementation instance within a composite

Oracle SOA Suite 12c: Essential Concepts 4 - 25

• Defines an assembly model that is stored in an SCA

Internal reference Component

Composite application Component u i -xu this S

Oracle SOA Suite 12c: Essential Concepts 4 - 26

• Composite applications and service components according

Oracle SOA Suite 12c: Essential Concepts 4 - 27

Types of Service Access and Implementation

Created Invoked Created as

Oracle SOA Suite 12c: Essential Concepts 4 - 28

A service is designed based on the following service design