ISM/ISC Middleware Module

Transcription

1 ISM/ISC Middleware Module Lecture 14: Web Services and Service Oriented Architecture Dr Geoff Sharman Visiting Professor in Computer Science Birkbeck College Geoff Sharman Sept 07

2 Lecture 14 Aims to: Introduce XML as a technology for interoperation between unlike systems and between companies Introduce Web Services as a set of standard protocols which make this possible Show how Web Services forms part of a Service Oriented Architecture and explore its implications 2

3 Outstanding Problems Traditional, one company applications of middleware leave some important unsolved problems: Business-to-business transactions: High level of repeat transactions Need automation, not just paper or a browser 3 Interoperability and re-use: Popular RPC standards do not interoperate Messaging systems need a message architecture Most business systems are legacy systems; limited to using connectors/adapters

4 Business-to-Business Automated B2B transactions have a long history e.g.: BACS/CHAPS for bank payments SWIFT messages for interbank transfers EFTPOS for retail transactions Online credit reference transactions EDI for manufacturing parts orders 4 But no universal standards: Standards are industry specific Both real time and batch transactions Proprietary networks; different technologies

5 Interoperability Widely used RPC mechanisms do not interoperate at message or program call level: CICS LINK DCE/RPC and.net variant CORBA RPC and Java RMI variant Reliable messaging systems need standard message architecture but don't have one 5 Connector/adaptor mechanisms also have limited interoperability

6 Is XML the Solution? Around 1998/99, a number of different groups identified extensible Markup Language (XML) as a key technology which might resolve some of these problems: Several companies were using XML for application integration ebxml published as a open standard for EDI Microsoft published Simple Object Access Protocol (SOAP) as an architecture using XML to enable different systems to interoperate 6 So yes, it's part of the solution

7 XML Basics XML is a hierarchical text based markup language, similar to HTML (derived from SGML for document processing) Unlike HTML, documents describe data format rather than presentation layout Each XML document is defined by a Document Type Descriptor (DTD) 7 XML documents are in self defining variable format, so must be parsed

8 8 AN XML Example <?xml version= 1.0?> <!DOCTYPE balanceinquiry SYSTEM banking.dtd > <balance> <accname>jones D</accname> <accname>smith J</accname> <account> <accno> </accno> <amount>1200</amount> </account> <account> <accno> </accno> <amount>500</amount> </account> </balance> BALANCE ACCNAME ACCNO AMOUNT An XML document represents data in a hierarchical structure Well-formed document: conforms to XML syntax rules

9 XML Document Type Descriptor DTD for the balanceinquiry document: <!ELEMENT balanceinquiry (balance)> <!ELEMENT balance (accname, account) <!ELEMENT accname (#PCDATA)> <!ELEMENT account (accno, amount)> <!ELEMENT accno (#PCDATA)> <!ELEMENT amount (#PCDATA)> all elements must appear parsed data all elements must appear parsed data parsed data Valid document: conforms to specified DTD 9 An alternative descriptor technology is provided by XML Schema language

10 HTML Document (for comparison) <h1>balance</h1> heading level 1 <h2>account Name</h2> heading level 2 <p>jones D</p> <h2>account Name</h2> heading level 2 <p>smith J</p> <h3>account Number</h3> heading level 3 <p>1234</p> <h3>amount</h3> heading level 3 <p>1200</p> <h3>account Number</h3> heading level 3 <p>5678</p> <h3>amount</h3> heading level 3 <p>500</p> 10

11 XML Technologies Much XML technology is derived from the document processing world Document Object Model (DOM) can: parse an XML document, validate it against its DTD, and build a corresponding tree structure in storage walk through a tree structure and build the corresponding XML document 11 Used in web browsers Why might it not be a good idea for server-toserver transactional messages?

12 XML Technologies (II) Simple API for XML (SAX) is a parsing technology which scans an XML document looking for elements defined in the DTD When an element is found, SAX triggers an event handler (a program supplied by the user) More efficient than DOM, allows partial parsing Template based generator can build an XML document from a pre-built document template, by inserting values from input record 12 Why can't we use templates for parsing?

13 SAX Example: XML Support in COBOL SAX-like XML parsing Works on IBM zseries systems OS/390, NT or UNIX XMLParse Document1 XMLDoc-Handler Evaluate xml-action when 'START-OF-DOC'... when 'END-OF-DOC'... when 'START-OF-ELEMENT... when 'ATTRIBUTE-NAME'... when 'ATTRIBUTE-CHAR'... when 'END-ELEMENT when 'START-OF-CDATA-Section' when 'CONTENT-CHARACTER when 'PROCESSING-INSTRUCTION-TARGET' when 'PROCESSING-INSTRUCTION-DATA' ' 13

14 Using XML for B2B Messages To make XML useful for transactional messages between application systems, we also need: 14 Envelope data which describes where the message should be sent Efficient parsing for relatively short documents (i.e. up to a few thousand bytes) Message adapters which can extract parameter data and invoke the appropriate program XML compression for efficient transmission?

15 Using XML for Messages (II) XML document message envelope (header) message payload message envelope (trailer) XML Msg Header routing information message type date/time stamp authentication context/state XML Msg Body data understood by target application XML Msg Trailer message digest 15

16 Calling Appls via XML Messages XML Source HTTP message parser message generator input adapter output adapter RPC target program "message parsing, input mapping, output mapping and message generation could built as Java objects Gateway XML parser Web Application Server Any Server 16 1.Map HTTP URL to program name 2.Define a DTD for the XML envelope 3.Build a gateway with these functions

17 SOAP as a Messaging Standard Specifies standards for the header part of the message including name of program to be invoked POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml Content-Length: nnnn SOAPMethodName: Some-Namespace-URI#GetLastTradePrice <SOAP:Envelope xmlns:soap="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Body> <m:getlasttradeprice xmlns:m="some-namespace-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP:Body> </SOAP:Envelope> 17

18 SOAP as a Messaging Standard SOAP does not specify what kind of programto-program exchange is required: message in one direction only ( fire and forget ) message and asynchronous reply synchronous RPC But these mechanisms can be built on SOAP 18

19 Schematic Architecture for SOAP Envelope Processor HTTP request receiver 19 Dataflow SOAP envelope parser application adapter Target Application Program SOAP envelope builder HTTP response sender Implements message plus response model Pipeline of handlers, based on Apache Axis (open source) architecture Separate handlers for processing transport, envelope, header, message body, etc. Can work with any type of target application Many application servers now have this functionality

20 Service Oriented Architecture What does this all add up to? HTTP provides open connectivity across organisational boundaries SOAP provides architecture for XML messages Implementation defines processing model This leads to the concept of a service: A program which is publicly accessible and performs some useful business function for other programs Therefore, services can be traded and used as elements of larger applications 20 Basis for Service Oriented Architecture

21 Service Oriented Architecture (II) For this to be useful, we need some a way to: find available services describe the interface to a service invoke the service combine services into larger services And, for each particular service, ways to: determine its authenticity and safety reach a business agreement to use it evaluate its worth pay for using it 21

22 Service Oriented Architecture (III) Technical things already in place: SOAP = protocol for using services Web Services Description Language (WSDL) = language for describing interfaces to services Universal Discovery and Definition Integration (UDDI) = directory technology enabling service providers to publish services 22 But other things will probably be needed, e.g. facilities for searching for services

23 Service Oriented Architecture (IV) service broker UDDI = "yellow pages" WSDL = stnd request format get interface publish find service provider SOAP bind / use service requester "supplier" "customer" 23 SOA should enable open real time trading - e.g. just in time integration of supply chain - most debates are about governance, i.e. agreements for use

24 24 Orchestrating Services In business terms, a service is supposed to represent a business process, e.g. purchasing This may involve several steps e.g.: order goods receive order confirmation receive goods & check correct receive invoice requesting payment make payment Each step might be a service in its own right Need a way to compose or orchestrate them

25 Example of Orchestrating Services Travel Agent process book holiday failed book flight succeeded O find alternative flight book hotel room book car already reserved confirm details parallel actions: both needed business process includes stateful interactions in a longlived service each step may use a different service may include sequential and parallel steps in a process handles failure of any step; defines compensating actions 25

26 Service Oriented Architecture (V) Observations on Web Services and SOA: A service is like a software component; but the supplier runs it for you A service usually includes business actions; using a service is a form of outsourcing Services should be loosely coupled, and may be at any level of granularity 26

27 Service Oriented Architecture (VI) Many companies are now piloting these technologies for internal application integration They've found some challenges: Identifying useful re-usable services Putting management structures in place to support and use services Getting performance right Getting security right 27 Few companies using for B2B trading, but many expect to in future

28 Summary You should now be able to: Describe XML as a technology for interoperation between unlike systems and between companies Describe Web Services as a set of standard protocols which make this possible Show how Web Services forms part of a Service Oriented Architecture and discuss its implications 28