You are on page 1of 61

SOA

Based on
(Service-Oriented Architecture: Concepts,
Technology, and Design)
Thomas Erl
Common characteristics of SOA
• based on open standards
– XML,WSDL,SOAP
• architecturally composable
– services exist as independent units of logic
– business process can be broken down into a series of services
– each service responsible for executing a portion of the process
• capable of improving QoS
– tasks are e carried out in a secure manner, protecting the
contents of a message
– tasks are carried out reliably so that message delivery or
notification of failed delivery can be guaranteed.
– the overhead imposed by SOAP message and XML content
processing does not inhibit the execution of a task.
Common characteristics of SOA
• Contemporary SOA supports, fosters, or
promotes:
– diversity, interoperability and federation
• Disparate technology platforms do not prevent service-
oriented solutions from interoperating
• Services enable standardized federation of disparate legacy
systems
– Discoverability
• It use UDDI “Universal Description, Discovery and
Integration”
– inherent reusability
• The same service reused by different solutions
Common characteristics of SOA
• Contemporary SOA supports, fosters, or
promotes:
– extensibility
– enterprise-wide loose coupling
– organizational agility
Common misperceptions about SOA
• An application that uses Web services is service-
oriented
• SOA is just a marketing term used to
– re-brand Web services
– re-brand distributed computing with Web services
• If you understand Web services you won't have a
problem building SOA
– The manner in which Web services are utilized in SOA is
significantly different
• Once you go SOA, everything becomes interoperable
– Though this ultimate goal is attainable, it requires
investment, analysis, and a high degree of standardization
Common tangible benefits of SOA
• Improved integration (and intrinsic
interoperability)
• Inherent reuse
• Streamlined (simplifying) architectures and
solutions
• Leveraging(get advantages) the legacy
investment
Common tangible benefits of SOA
• Establishing standardized XML data
representation
• Focused investment on communications
infrastructure
• "Best-of-breed" alternatives
• Organizational agility
Common pitfalls of adopting SOA
• Building service-oriented architectures like
traditional distributed architectures
• Not standardizing SOA
• Not creating a transition plan
• Not starting with an XML foundation architecture
• Not understanding SOA performance
requirements
• Not understanding Web services security
• Not keeping in touch with product platforms and
standards development
Web Service
• Every Web service can be associated with:
– a temporary classification based on the roles
(service roles) it assumes during the runtime
processing of a message
– a permanent classification based on the
application logic(service model) it provides and
the roles it assumes within a solution environment
Web Service
1. Service roles
– A Web service is capable of assuming different
roles, (initiator, relayer, or the recipient )of a
message.
– It is common for a Web service to change its role
more than once within a given business task.
Web Service
1. Service roles
1. Service provider
– The service provider role is synonymous with the
server role in the classic client-server architecture.
– The following terms are sometimes used:
• service provider entity (the organization or individual
providing the Web service)
• service provider agent (the Web service itself, acting as
an agent on behalf of its owner)
Web Service
1. Service roles
2. Service requestor
– Any unit of processing logic capable of issuing a request
message that can be understood by the service provider is
classified as a service requestor. A Web service is always a
service provider but also can act as a service requestor
– service requestor entity (the organization or individual
requesting the Web service)
– service requestor agent (the Web service itself, acting as
an agent on behalf of its owner)
– Another term frequently used instead of service requestor
is service consumer.
Web Service
1. Service roles
3. Intermediaries
– Web services and service agents that route and
process a message after it is initially sent and before it
arrives at its ultimate destination
– Two types of intermediaries.
• Passive intermediary, is typically responsible for routing
messages to a subsequent location. It does not modify the
message.
• Active intermediaries also route messages to a forwarding
destination. Prior to transmitting a message, however, these
services actively process and alter the message contents.
Web Service
1. Service roles
4. Initial sender and ultimate receiver
– Initial senders are simply service requestors that
initiate the transmission of a message.
– Ultimate receiver is the last Web service along a
message's path
Web Service
1. Service roles
5. Service compositions
– It is applied to a composite relationship between a
collection of services.
– Any service can enlist one or more additional
services to complete a given task.
– Any of the enlisted services can call other services
to complete a given sub-task.
• Each service that participates in a composition assumes
an individual role of service composition member.
Web Service
2. Service model
– The classification based on the nature of the
application logic a service provide, as well as its
business-related roles within the overall solution.
– These classifications are known as service
models.
Web Service
2. Service model
1. Business service model
– Within an SOA, the business service represents
the most fundamental building block
– It encapsulates a distinct set of business logic
within a well-defined functional boundary.
– It is fully autonomous but still not limited to
executing in isolation
Web Service
2. Service model
1. Business service model
– Business services are used within SOAs as
follows:
• as fundamental building blocks for the representation
of business logic
• to represent a corporate entity or information set
• to represent business process logic
• as service composition members
Web Service
2. Service model
3. Controller service model
– Service compositions are comprised of a set of
independent services
– The assembly and coordination of these services is
often a task in itself
– The controller service fulfills this role, acting as the
parent service to service composition members.
– Any generic Web service or service agent designed for
potential reuse can be classified as a utility service
Web Service
• Metadata and service contracts
– WSDL definition
– XSD schema
– policy
Service descriptions (WSDL)
• A WSDL describes the point of contact for a
service provider “the service endpoint”
• It provides a formal definition of the endpoint
interface
– So that requestors wishing to communicate with
the service provider know exactly how to
structure request messages
– And also establishes the physical location
(address) of the service
Service descriptions (WSDL)
• A WSDL service description can be separated
into two categories:
1. Abstract description
– Establishes the interface characteristics of the
Web service without any reference to the
technology used to host.
– The integrity of the service description can be
preserved regardless of what changes might occur
to the underlying technology platform.
Service descriptions (WSDL)
• A WSDL service description can be separated into
two categories:
1. Abstract description-Compoent
– PortType: the operations performed by the web
service and the messages that are involved. It can be
compared to a function library (or or a class) in a
traditional programming language
– Operation represents a specific action performed by
the service
– Messages: parameters are represented as messages,
an operation consists of a set of input and output
messages.
Service descriptions (WSDL)
• A WSDL service description can be separated into two
categories:
2. Concrete description
– For a Web service to be able to execute any of its logic, it
needs for its abstract interface definition to be
connected to some real, implemented technology.
– Because the execution of service application logic always
involves communication, the abstract Web service
interface needs to be connected to a physical transport
protocol.
– This connection is defined in the concrete description
portion of the WSDL file, which consists of three related
parts
Service descriptions (WSDL)
• A WSDL service description can be separated into two
categories:
2. Concrete description-components
– Binding:
• represents one possible transport technology the service can
use to communicate
• SOAP is the most common form of binding, but others also are
supported A binding can apply to an entire interface or just a
specific operation
– Port:
• represents the physical address at which a service can be
accessed with a specific protocol (HTTP URL string)
Service discovery
• As the amount of services increases within and
outside of organizations, mechanisms for
advertising and discovering service descriptions
become necessary
• This help in
– locate the latest versions of known service
descriptions
– discover new Web services that meet certain criteria
• This why the UDDI has emerged
– UDDI stands for Universal Description, Discovery and
Integration
Service discovery
• UDDI
– Specifies a relatively accepted standard for structuring
registries that keep track of service descriptions
– These registries can be searched manually and
accessed programmatically via a standardized API
– Has tow type
1. Public registries accept registrations from any
organizations. Once signed up, organizations acting as
service provider entities and can register their services.
2. Private registries can be implemented within organization
boundaries to provide a central repository for descriptions
of all services the organization develops, leases, or
purchases.
SOAP
• SOAP stands for Simple Object Access Protocol
• All communication between services is
message-based
– As a result the messaging framework must be
standardized so that all services, regardless of
origin, use the same format and transport
protocol
– Thus the messaging framework must be extremely
flexible and highly extensible
SOAP
• The SOAP specification was chosen
– to meet all of these requirements
– has since been universally accepted as the
standard transport protocol for messages
processed by Web services
• the SOAP specification's main purpose is to
define a standard message format
SOAP
• Every SOAP message is packaged into a container
known as an envelope
• Each message contains
– A header
• an area dedicated to hosting meta information
• Its importance relates to the use of header blocks through
which numerous extensions can be implemented
– A body
• The actual message contents
• It is typically consists of XML formatted data
• The contents of a message body are often referred to as the
message payload.
SOAP
• Header blocks
– Is used to implement message independence
– By using header blocks, SOAP messages are capable of
containing a large variety of supplemental information
related to the delivery and processing of message contents
• Supply a message with all of the information required for
any services with which the message comes in contact to
process
• Route the message in accordance with its accompanying
rules, instructions, and properties
SOAP
• Header blocks
– Examples of the types of features a message can be equipped
with using header blocks include:
• processing instructions that may be executed by service
intermediaries or the ultimate receiver
• routing or workflow information associated with the
message
• security measures implemented in the message
• reliability rules related to the delivery of the message
• correlation information (typically an identifier used to
associate a request message with a response message)
SOAP
• NODES
– Although Web services exist as self-contained
units of processing logic, they are reliant upon a
physical communications infrastructure to process
and manage the exchange of SOAP messages.
Every major platform has its own implementation
of a SOAP communications server, and as a result
each vendor has labeled its own variation of this
piece of software differently. In abstract, the
programs that services use to transmit and receive
SOAP messages are referred to as SOAP nodes
SOAP
• NODES
– Regardless of how they are implemented, SOAP
nodes must conform to the processing standard
set forth in the versions of the SOAP specification
they support
– It is what guarantees that a SOAP message sent by
the SOAP node from service A can be received and
processed by a SOAP node (supporting the same
version of the SOAP standard) from any other
service
SOAP
• Node Types
– As with the services that use them, the underlying SOAP
nodes are given labels that identify their type, depending
on what form of processing they are involved with in a
given message processing scenario
• SOAP sender a SOAP node that transmits a message
• SOAP receiver a SOAP node that receives a message
• SOAP intermediary a SOAP node that receives and transmits a
message, and optionally processes the message prior to
transmission
• initial SOAP sender The first SOAP node to transmit a message
• ultimate SOAP receiver the last SOAP node to receive a message
XML
• XML stands for eXtensible Markup Language
• XML is a markup language much like HTML
• XML was designed to carry data, not to display
data
• XML tags are not predefined. You must define
your own tags
• XML is designed to be self-descriptive
• XML is a W3C Recommendation
XML
• The Difference Between XML and HTML
– XML is not a replacement for HTML.
– XML and HTML were designed with different
goals:
• XML was designed to transport and store data, with
focus on what data is
• HTML was designed to display data, with focus on how
data looks
– HTML is about displaying information, while XML
is about carrying information.
XML
• How Can XML be Used?
1. To separates Data from HTML
• Data can be stored in separate XML files
• You can concentrate on using HTML for layout and
display, and be sure that changes in the underlying data
will not require any changes to the HTML.
2. XML Simplifies Data Sharing
• XML data is stored in plain text format. This provides a
software- and hardware-independent way of storing
data.
XML
• How Can XML be Used?
3. XML Simplifies Platform Changes
• XML data is stored in text format
• This makes it easier to expand or upgrade to new
operating systems, new applications, or new
browsers, without losing data
4. XML Makes Your Data More Available
• Different applications can access your data
• Your data can be available to all kinds of "reading
machines" (Handheld computers, voice machines, news
feeds, etc)
XML
• An Example XML Document
<?xml version="1.0" encoding="ISO-8859-1"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
XML
• <?xml version="1.0" encoding="ISO-8859-1"?>
– Defines the XML version (1.0) and the encoding
used (ISO-8859-1 = Latin-1/West European
character set)
• <note>
– describes the root element of the document (like
saying: "this document is a note"):
• <to>,< from>, <heading>, <body>
– describe 4 child elements of the root
XML
Another example(1/2)
XML
Another example(2/2)
<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>

<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>

<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>
XML
• XML Syntax Rules
1. All XML Elements Must Have a Closing Tag
• it is illegal to omit the closing tag
• All elements must have a closing tag
2. XML Tags are Case Sensitive
• XML tags are case sensitive
• The tag <Letter> is different from the tag <letter>.
3. XML Documents Must Have a Root Element
• XML documents must contain one element that is the
parent of all other elements
• This element is called the root element
XML
• XML Syntax Rules
5. XML Elements Must be Properly Nested
6. XML Attribute Values Must be Quoted
7. Comments in XML
• <!-- This is a comment -->
7. White-space is Preserved in XML
XML
• Viewing XML Files
– XML files are displayed as HTML pages
– XML documents do not carry information about how to display
the data
– Since XML tags are "invented" by the author of the XML
document, browsers do not know if a tag like <table> describes
an HTML table or a dining table.
– Without any information about how to display the data, most
browsers will just display the XML document as it is
– Solutions to the display problem include using
• Cascading Style Sheets (CSS)
• eXtensible Stylesheet Language Transformations (XSLT)
– used to transform XML into HTML, before it is displayed by a browser
• JavaScript
XML
• XML Validation
– XML with correct syntax is "Well Formed" XML.
– XML validated against a Document Type Definition
“DTD” is called "Valid" XML.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE note SYSTEM "Note.dtd">
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

– The DOCTYPE declaration in the example above, is


a reference to an external DTD file
XML
• XML DTD
– The purpose of a DTD is to define the structure of an XML document
– It defines the structure with a list of legal elements
– With a DTD, each of your XML files can carry a description of its own
format.
– Your application can use a standard DTD to verify that the data you
receive from the outside world is valid
– With a DTD, independent groups of people can agree to use a standard
DTD for interchanging data
– Inline example of DTD
<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
XML
• XML Schema
– The World Wide Web Consortium (W3C) supports
an XML-based alternative to DTD, called XML
Schema
– XML Schema is an XML-based alternative to DTD
– The XML Schema language is also referred to as
XML Schema Definition (XSD)
XML
• Why XML Schema
– XML Schemas are extensible to future additions
• Reuse your Schema in other Schemas
• Create your own data types derived from the standard
types
– XML Schemas are written in XML
• You don't have to learn a new language
• You can use your XML editor to edit your Schema files
• You can manipulate your Schema with the XML DOM
• You can transform your Schema with XSLT
XML
• Why XML Schema
– XML Schemas are richer and more powerful than
DTDs
– XML Schemas support namespaces
– XML Schemas support data types
• It is easier to describe allowable document content
• It is easier to validate the correctness of data
• It is easier to work with data from a database
• It is easier to define data facets (restrictions on data)
• It is easier to define data patterns (data formats)
• It is easier to convert data between different data types
XML
• How to reference to an XML Schema

<?xml version="1.0"?>
<note
xmlns="http://www.w3schools.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3schools.com note.xsd">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
XML
• XDL elements
– Simple type
• An XML element that contains only text
• It cannot contain any other elements or attributes
– Complex type
• Contains other elements and/or attributes
XML
• XSD Simple Elements
– Can contain only text
– The text can be of many different types
– It can be one of the types included in the XML
Schema definition (boolean, string, date, etc.)
– Or it can be a custom type that you can define
yourself
– You can also add restrictions (facets) to a data
type in order to limit its content
XML
• XSD Simple Elements
– The syntax for defining a simple element is
<xs:element name="xxx" type="yyy"/>

• where xxx is the name of the element


• and yyy is the data type of the element

– Simple elements may have a default value OR a fixed value


specified.
<xs:element name="color" type="xs:string" default="red"/>
<xs:element name="color" type="xs:string" fixed="red"/>

– XML Schema built-in data types


xs:string xs:decimal xs:integer
xs:boolean xs:date xs:time
XML
• XSD Simple Elements
– Example
• Here are some XML elements
<lastname>Refsnes</lastname>
<age>36</age>
<dateborn>1970-03-27</dateborn
• Here are the corresponding simple element definitions
<xs:element name="lastname" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
<xs:element name="dateborn" type="xs:date"/>
XML
• XSD Complex Elements
– Is an XML element that contains other elements
and/or attributes.
– Four kinds of complex elements:
• empty elements
• elements that contain only other elements
• Elements that contain only text
• elements that contain both other elements and text
XML
• XSD Complex Elements
– Two way to define complex element
1. Declared directly by naming the element
<xs:element name="employee">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
– In this way, only the "employee" element can use the specified
complex type.
– The <sequence> indicator means that the child elements must
appear in the same order as they are declared
XML
• XSD Complex Elements
– Two way to define complex element
2. Element can have a type attribute that refers to
the name of the complex type to use:
<xs:element name="employee" type="personinfo"/>

<xs:complexType name="personinfo">
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
XML
• XSD Complex Elements
– Using the previous method, several elements can
refer to the same complex type, like this:
<xs:element name="employee" type="personinfo"/>
<xs:element name="student" type="personinfo"/>
<xs:element name="member" type="personinfo"/>

<xs:complexType name="personinfo">
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
• XSD Complex Elements
– You can also base a complex element on an existing
complex element and add some elements:
<xs:element name="employee" type="fullpersoninfo"/>

<xs:complexType name="personinfo">
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:sequence>
</xs:complexType>

<xs:complexType name="fullpersoninfo">
<xs:complexContent>
<xs:extension base="personinfo">
<xs:sequence>
<xs:element name="address" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

You might also like