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 roles1. 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 roles2. 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 roles3. 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 roles4. 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 roles5. 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 model1. 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 model1. 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 model3. 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)

XMLAnother 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 Rules1. 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 Rules5. XML Elements Must be Properly Nested6. XML Attribute Values Must be Quoted7. 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"?><notexmlns="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 typesxs: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>