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 • 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 • Service roles • 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 • Service roles • 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 • Service roles • 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 • Service roles • 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 • Service roles • 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 • 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 • Service model • 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 • Service model • 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 • Service model • 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: • 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: • 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: • 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: • 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 • Public registries accept registrations from any organizations. Once signed up, organizations acting as service provider entities and can register their services. • 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 eXtensibleMarkup 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? • 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. • 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? • 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 • 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 • All XML Elements Must Have a Closing Tag • it is illegal to omit the closing tag • All elements must have a closing tag • XML Tags are Case Sensitive • XML tags are case sensitive • The tag <Letter> is different from the tag <letter>. • 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 • XML Elements Must be Properly Nested • XML Attribute Values Must be Quoted • Comments in XML • <!-- This is a comment --> • White-space is Preserved in XML
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