Web Services

• Service Oriented Architecture
• What are Web Services?
• What are Web Services Protocols?
• The Big picture
• SOAP: Simple Object Access Protocol
• WSDL: Web Services Description Language
• Summary

Goal – to understand principles behind web services and their use

• Service is usually managed by a service provider; think of it as an application. If you need to access the service, you need an interface to invoke the interface.
• We gonna look at how to implement service-oriented architecture.

Distributed Computing Paradigms & Web services

• Paradigms that have made distributed computing over the years
• First - Goes back many years ago when internet was invented- the idea was to link all the machines together. I need sth that make them talk to each other
  • Internet, TCP IP protocol stack
  • 2 - 15 - 100 - now more than a billion machines connected to the internet
• Second- With the advent of the web, if you have all sorts of document, we need some form of infrastructure which allows us to access all sorts. And therefore, to make it happen, we need a protocol
  • hence HTTP, XMP, Json
• Third - If we move to the next step and we talk about application that u’d like to share it with others. If we link all the apps together, we end up with Service Oriented Architectures
  • Web services are there to implement the concept of SOA
    • SOAP, WSDL, UDDI
    • REST

Why use XML for structuring and exchanging data?

• Easily extended, Data is self-described
• Text based -easy to parse, portable and human friendly
• And it doesn’t belong to anybody! – non-proprietary
• Easy to represent the data, esp when exchanging data btwn client and server

Why use JSON for structuring and exchanging data?

• Lightweight, text data interchange format
• Language independent and human friendly
• Self-describing and easy to understand
• Diff btwn json notation and xml – but easy to use existing parser to parse XML or JSON
• When you invoke a web service, you usually have the choice to tell the service provider to send back the reply in json or xml

Service Oriented Architecture

• Web services are there to support the development of SOA
• Self-contained, self-describing modular unit participating in a larger ecosystem
  • Insist on the word ecosystem – all the services being loosely coupled live in harmony!
• SOA recap
  • Service provider - owns the service it needs to describe and publish it via broker
  • Client or requester – uses broker to find, then bind to a service
  • Broker- acting as a “yellow book” directory for services - Broker is here to play the role of the middleman
    • new word in this ecosystem called the broker, some form of directory for services, search and use it
• IMPORTANCE of the internal middleware in btwn client and service side.

Example: Book a flight and car

• When you book a flight you do it via a website. → broker
• Broker tells us all the available flights that are advertised.
• If we book a flight w/ Ryanair, runs a website in online booking system, it will ask me if I wanna book a car to Hertz – this partner basically runs a booking system. It provides an interface to a web service. And ryan air becomes a client of the web service.
• They have diff hw and sw but they can be loosely coupled with a WS – both business can benefit from it.
• SOA would allow you to dynamically discover services via brokerage. But its likely that they have partnership, therefore it’s important to provide interface to the company on the RHS

What are Web Services?

• Web service is a piece of business logic, located on the internet and can be accessed using standard XML or standard protocols such as HTTP or STMP
• Doesn’t necessarily replace existing DS, but is a coarse grain to exposing and advertising enterprise services
• Fundamental idea of SOA is that as a service provider, you publish and expose your service.
  • Can be published on platforms – google, amazon etc
• If you are able to access the web services, then you have opportunity to build large scale, loosely coupled DS without any constraining technology. If google amazon can expose these technologies, interoperability isn’t a problem anymore
  • Loosely coupled - There’s no real dependency between the programs
  • You will simply invoke the services to develop system components

1. Described using a service description language,
   • Service should be described to interface and you still need to describe so that they know the request that can be made algorithms that are used
     • E.g. if I’m a service provider and I have a method ‘do it’ = this method has a name, and it needs two arguments! arguments are item name and quantity → your describing the service. The end user looks at this description and stick to it – its part of the contract/ policy.
     • Important for The SERVER to tell me what transport its expecting
2. Published to a registry of services
   • WS needs to tell registry service where the service is located - Its published to a yellow page, and can be discovered by clients, and standard mechanism to access the service you need.
3. Discovered through a standard mechanism (at runtime or design time)
   • Client can find the service through search and access. It with standard mechanism
4. Invoked through a declared API, usually over a network,
   • If the service said that there is a method called do it, and 2 arguments. And as a client if I want to invoke it, ill need to stick to that.
   • In the end of the day ill always expect some sort of reply from the service itself.
5. Composed with other services.
   • To compose your service with other services and have a chain of web services.
   • Here I invoke service 1, get some output – this can become an input to web service no 2. and this output can be fed to 3 and get a final result.
   • What does this mean? Need to build an app that can integrate the WS – every time you invoke a service you feed input and extract some useful output
   • E.g. When your going to a football match – weather, city, how to get → all these are composition of WS

What are Web Services Protocols?

• They’ve implemented this through number of protocols to make this service description, discovery and invocation
• The way it works is you have 3 main components of web services
  • WSDL – used to describe a service
  • UDDI – as a broker to discover service
  • SOAP – achieve platform and implementation independent, and can compose a chain of WS
• You need protocols to make this vision happen
• SOAP – simple object access protocol – over time it became service oriented architecture protocol

The Big picture

1. You are here, you are a soap client and you are building an app that invokes an amazon service.

2. Send a request to amazon server, it understands that your talking SOAP, and invokes SOAP processor, and soap processor understands the business logic, it gets the logic and execute it

3. Sends back a response

   • Before doing this, client needs the description of the service – gets it from UDDI registry or directly from service provider - is described through WSDL
   • EMPHAIZE the importance of having WSDL – which describes the interface of services

SOAP: Simple Object Access Protocol

• It ain’t simple.
• Sometimes name gets given to protocols without understanding what they do – it’s a mechanism to ensure that the client and server can communicate through some sort of messaging
• What it does
  • Takes the packaging of information sent btwn the client and server, in a standard way. To do that, over HTTP, SMTP etc
    • First look at the standard, build a msg, send the msg, get the reply
  • Supports synchronous (RPC) and asynchronous (document tranfer) modes of communication
    • AGAIN, RPC style – still using remote procedure call, where client sends the rq, client invokes a method which is part of the service. request reply, invokes a method. very imp
      • You can decide if you want it sync or async.
  • It provides interoperability abstraction of conventional RPC/ RMI
    • RPC – invoke remote procedure call
    • RMI – where you invoke a remote object in the server, that is the same principle

How XML becomes SOAP

• Client builds a soap msg → Sent through network through a soap server
• The soap is very much how you wrap your msg – with a lot of XML → SOAP body
• Once you have a body (I want to invoke this, these are the params, this is the transport), ull have to put it in a SOAP envelope.
• However, you may want to look at extra information that will help how soap server process your message – SOAP header is added to help SOAP processor do sth with your request
• However, it has to go through a network, and server and client have diff OS, diff platform and data encoding –have to look at naming and namespace declaration and you need to agree in encoding style and directives
  • This is where NAMING becomes important

Overall Structure

• Body – it looks like im invoking a web service in that link, and its invoking through a host name which is just a ‘string’. Already some basic info of what im invoking
• Envelope – XML namespace
  • xsd – naming service in XML schema
  • Xsi - refers to an instance of the xsi.
  • Difference
    • Xsd describes the ns – looking at the elements, attributes and types – anything server and client needs to agree when they exchange data
    • Xsi refers to an instance. Could think about specific types as an int, float, but more importantly, here for instance you have directives for XML schema processing.
  • Standards that’s been around since w3c – how they communicate via data exchange

Use of SOAP header and body in RPC

• If I look at the actual body, what else do I expect - Number of things in the body
• First is all to do with business logic – what are you invoking, what’s the name of the methods, what are the parameters, what does it return?
• In this case, the body contains a single element called method, and there’s sub elements that comes with it – could be parameters that are required by the receiving method
• Types – must match what server expects. They need to agree on what to expect.
• Response –business logic is supported by the server, server executes the actual call, and sends a reply back. Similarly, will have to contain values – these values could specify as part of the body.
  • Could be one element, sometimes it’s a whole XML or json document
• End of the day your invoking a method, name, parameters, and ur receiving back a response with some form of convention with the server

WSDL: Web Services Description Language

• Information required by the client to build SOAP msg will need to be extracted from the service interface – therefore the client doesn’t have to scratch their head lol
• WSDL - Describes the interface of a WS in a standard way that allows the client to understand how to interact with web services
• Function of interface of WSDL is comparable to IDL (Interface Description Language)
• Adds considerably to the complexity of web service
• E.g. amazon
  • Without broker, you ask amazon for a document to build a SOAP msg.
  • Very long but its enough to have any service described in a way that you can take it and do sth with it – can take WSDL and write some code.
  • If I can get this WSDL, I may be able to use a tool, to extract what you need from it - which is usually the interface. This interface will look like a proxy or a stub. Which will allow you to invoke any of the method.
  • Q: which comes first – WSDL or the service itself?
    • A: service comes first – amazon writes the service, then they have a tool to generate a wsdl document
    • Then you use a diff tool to generate a stub or proxy to attach to your code – then you can invoke any of the method that is available

Anatomy of a WSDL document

• May find definitions of element that describes a WS:
• Import / #include - to import extra elements that are needed by the service
• Types - There is a type that defines the datatype of msg elements
• Message – your invoking methods, what are the names of the methods
• Port type– where you pair the rq to the reply – when there’s an element called doit – portType may look like doit rq and doit reply – processer will need to know that when invoking doit, expect a request
  • We invoke through endpoints - have URI
• Binding – specifying operation style and transport protocol - amazon expecting me to stick to it.
• Service – locate the endpoint – means the invocation of service through URI

Summary

• By using XML and HTTP – WS meets industry needs that other DS tech cannot
• WS support loose coupling – facilitating SOA for the internet
• Reviewed how SOAP is used to structure XML messages
• Seen how WSDL describes a WS in a way that IDL describes the interface of a remote component