SOA

1. SOA Based on (Service-Oriented Architecture: Concepts, Technology, and Design) Thomas Erl

2. 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.

3. 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

4. Common characteristics of SOA • Contemporary SOA supports, fosters, or promotes: • extensibility • enterprise-wide loose coupling • organizational agility

5. 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

6. Common tangible benefits of SOA • Improved integration (and intrinsic interoperability) • Inherent reuse • Streamlined (simplifying) architectures and solutions • Leveraging(get advantages) the legacy investment

7. Common tangible benefits of SOA • Establishing standardized XML data representation • Focused investment on communications infrastructure • "Best-of-breed" alternatives • Organizational agility

8. 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

9. 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

10. 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.

11. 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)

12. 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.

13. 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.

14. 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

15. 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.

16. 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.

17. 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

18. 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

19. 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

20. Web Service • Metadata and service contracts • WSDL definition • XSD schema • policy

21. 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

22. 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.

23. 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.

24. 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

25. 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)

26. 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

27. 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.

28. 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

29. 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

30. 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.

31. 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

32. 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)

33. 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

34. 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

35. 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

36. 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

37. 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.

38. 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.

39. 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)

40. 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>

41. 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

42. XML Another example(1/2)

43. 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>

44. 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

45. 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

46. 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) • eXtensibleStylesheet Language Transformations (XSLT) • used to transform XML into HTML, before it is displayed by a browser • JavaScript

47. 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

48. 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)>]>

49. 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)

50. 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