Web Services Concepts

The Basics

THE MOVES INSTITUTE

Web Services

Web services are a subset of a larger problem domain called distributed programming. The objective of distributed programming is to have more than one computer cooperate in solving a problem. In the case of web services, a task is to access some business process that resides in another business entity’s network.

Examples of distributed programming include RPC, CORBA, RMI, and at the extreme end custom socket programming

THE MOVES INSTITUTE

Web Services

Because the functionality can be in another business entity’s domain, this creates some problems compared to other distributed programming solutions

• The client does not control the other entity’s firewall

• This often happens across a WAN that is comparatively unreliable and with low bandwidth and high latency

THE MOVES INSTITUTE

Web Services

Web services is an indistinct term that encompasses many technologies. At its most basic it involves

• Sending commands between hosts on the internet

• Using XML to describe the command and response

• Often using transport mechanisms at a higher level of abstraction than sockets

THE MOVES INSTITUTE

Web Services

<command>… </command>

<response>…</response>

Program to process command

Client Server

Send XML message from client to server and get a responseback in XML

THE MOVES INSTITUTE

Web Services

There are many pieces of infrastructure and standards that go along with this, including:

• How to get the XML to the program intended to process it--the transport mechanism

• The dialect of the XML being sent• Advertising what the server is capable of

processing• Making it easy to bind the request and

response to programming language constructs

THE MOVES INSTITUTE

Transport

A very popular way to get XML to a program is to use HTTP, the protocol used by web servers

The XML command is placed inside HTTP request

THE MOVES INSTITUTE

HTTP Transport

HTTP was originally designed to retrieve HTML documents from a server and give them to a web browser. Http is just a series of well-defined text commands that the http server parses.

“Get this page”

“Here are the page contents”

THE MOVES INSTITUTE

HTTP Transport

HTTP has several commands, but the two most important are GET and POST. GET requests a particular document; POST can send HTML form data as part of the request. GET can also send HTML form data, but does so as part of the URL sent to the server

These two http commands constitute most of the http traffic.

To grossly simplify, most web services use the POST command to carry XML

The next pages shows some simple HTTP requests. Notice that the request and response is just some simple text.

THE MOVES INSTITUTE

HTTP GET exampleGET / HTTP/1.1 Host: www.apple.com Connection: close Accept-Encoding: gzip Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excelAccept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;

HTTP/1.1 200 OK Date: Mon, 23 May 2008 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8

THE MOVES INSTITUTE

HTTP POST examplePOST /interface/flat HTTP/1.0 Host: www.livejournal.com Content-type: application/x-www-form-urlencoded Content-length: 34 mode=login&user=test&password=test

HTTP/1.1 200 OK Date: Sat, 23 Oct 1999 21:32:35 GMT Server: Apache/1.3.4 (Unix) Connection: close Content-Type: text/plain name Mr. Test Account success OK message Hello Test Account!

THE MOVES INSTITUTE

HTTP Transport

As you can see, the protocol is pretty straightforward.Note that http is by design stateless. This means that

the server does not remember prior commands from the client; each command is treated as a stand-alone request.

Note that you can send pretty much anything you want as a payload in HTTP Post commands. The HTTP command is just a wrapper with some header information for the web server and an arbitrary payload.

It’s that payload that is the web service command

THE MOVES INSTITUTE

Yeah, So?

So why is http transport so widely used?The advent of firewalls and security meant that almost all incoming

network ports have been shut down. The major exception is web server ports (80), and those are usually routed to locked-down, secured machines in the DMZ. Since port 80/http is the only thing available, people use it.

The web server or http is often regarded as the IT “public face” of corporations, so it sort of makes sense to do all public interactions through it.

“In the future, all network traffic will go over port 80 wrapped inside of an http request” –me

Of course, security issues don’t go away simply by putting everything inside http. Web services are effectively a form of Remote Procedure Call (RPC), so it is really old wine in new bottles. At least the trend centralizes traffic to a place it can be watched.

THE MOVES INSTITUTE

Yeah, So?

The XML dialects kind of make sense as a cross-platform format. You can represent all sorts of data in XML, and there are a lot of tools to process it, and emerging standards for things like semantics

THE MOVES INSTITUTE

Web Servers

Classic: “Get this file”

“Here it is”

THE MOVES INSTITUTE

Web Services

Note that this model can easily be tweaked to handle web services. The http request simply acts as a wrapper that contains the XML.

THE MOVES INSTITUTE

Web Services (Grossly Simplified)

“Here is some XML insideof an HTTP POST”

“Here is an http response that containsan XML payload, and don’t forget any side effects that may have happened on the server”

Program that processes theXML request, does somethingwith it, and generates an XMLresponse

THE MOVES INSTITUTE

Caveats

Note that the important thing is the XML payload, not how it gets to the program that does the processing. Http is just a transport mechanism to get the XML to the program that does the processing with a minimum of drama. While most systems use http as a transport mechanism this is not a hard and fast requirement. The XML payload may be delivered via Java Messenging Service (JMS), SMTP (email), XMPP/Chat, etc. As long as the XML payload gets to the program that processes it it doesn’t matter, though there may be issues with latency depending on the transport mechanism

Http is the most common, and “web services” gets its name from that

THE MOVES INSTITUTE

Transport Mechanisms

XML Payload

Http Request

XML Payload

SMTP (Mail) transport

XML Payload

JMS transport

…

THE MOVES INSTITUTE

Transport Mechanisms

We will be concentrating on the http transport mechanism. But remember there are other ways. http is just a useful bit of overhead; so long as we can get the xml to the right program we can use whatever we want.

In fact, a command may use a processing chain that uses multiple transport mechanisms while being processed the initial intake from an off-site partner may be via http, and the XML may be processed in a chain internally via JMS, before a response is returned to the originally caller via http

THE MOVES INSTITUTE

XML Payload Format

We said that the web server is getting the XML request and doing something with it. What does the XML look like?

Many flavors of XML, with no one clear standard, just tendencies.

THE MOVES INSTITUTE

XML Payload Formats

Http

SOAP

Document StyleXMLXML-RPC

Contains

ORContains

An approximation: the http transport request contains SOAP, a dialectof XML that acts as an envelope. The SOAP envelope contains either XML-RPC, an XML dialect that represents a remote methodcall, or an XML document.

This general structure is not a given. Some implementations put XML-RPC

directly into the HTTP payload without a SOAP envelope.

XML-RPC

THE MOVES INSTITUTE

SOAP

SOAP stands for Simple Object Access Protocol and is a W3C standard

It is an XML dialect that is used to contain structured XML data, much as an envelope with an address contains a payload

SOAP Header

SOAP Body

SOAP Envelope

THE MOVES INSTITUTE

SOAP

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header>…some XML here…</env:Header> <env:Body>…The XML payload here…</env:Body></Envelope>

THE MOVES INSTITUTE

SOAP

SOAP is really just a generic container for the “real” XML payload.

The header portion can contain XML intended to provide meta information about the payload, such as processing instructions for the program that eventually handles the XML

The body contains the actual payload of XML

THE MOVES INSTITUTE

SOAP

Example: the SOAP request contains a header and an XML document in the body section. The first program to handle the message reads the body, then places some contextual information into the header and passes it on to the next program in the chain. The next program reads both the header and the body and processes accordingly; the original XML body document is not modified in this example.

You can also use SOAP headers to implement “conversational” exchanges; the header can contain information that allows the server to correlate new messages from the client with old ones, allowing stateful transactions across a stateless protocol

THE MOVES INSTITUTE

SOAP

SOAP<env><header>…header info…</header><body>..XML Payload…</body></env>

Http

HTTP used as the transport.The SOAP XML document containsa header, which has meta info about how to process the XML payload or what has been done to it. The body section of the SOAP document contains the actual XML payloadThe SOAP could also be placed insidea JMS transport or an SMTP transport or even sent directly across a socket

THE MOVES INSTITUTE

SOAP

SOAP is a payload, but it is a completely generic container for the “real” payload

Some web services dispense entirely with SOAP. For example, you can place XML-RPC directly into an HTTP request. This is done when you don’t need the header portion, which is often the case in XML-RPC

THE MOVES INSTITUTE

XML Payload

Finally, after all this infrastructure, we can look at the payload.

One payload that was initially popular but that is now losing favor is XML-RPC. It is a way to call methods on remote objects, similar conceptually to CORBA, RMI, etc. If you have an object on the server, and call a method on the server from the client

THE MOVES INSTITUTE

XML-RPC Payload in an HTTP Transport

POST /RPC2 HTTP/1.0Content-Type: text.xlContent-length:181

<?xml version=“1.0”?><methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>42</i4></value> </param> </params> </methodCall>

THE MOVES INSTITUTE

XML-RPC

In this example the method “getStateName” on the object “examples” is being called with a parameter of 42.

examples.getStateName(42);The receiver simply parses the XML and

calls the local method, then transforms the response into XML and returns it.

THE MOVES INSTITUTE

XML-RPC

The advantage to this is that it is relatively simple.

The disadvantage is that it tends to result in tight coupling across high latency, unreliable links, which is bad for distributed applications. Experience has shown that large distributed applications don’t do well using the same levels of abstraction as object programming on a single machine.

Note the handling of parameters. What if you wanted to pass an object as a parameter rather than a primitive type? This can require some more work.

THE MOVES INSTITUTE

XML-RPC

An XML-RPC implementation is available at apache.org

http://ws.apache.org/xmlrpc/

We will discuss an example XML-RPC program later

THE MOVES INSTITUTE

XML-RPC

So: the basic theory is, include the XML that describes the RPC call inside an HTTP request. On the server side, have a program unpack the http request, process the XML, do what it says, and return a response.

There are open source XML-RPC processors that can parse and handle the XML-RPC call, so from the developer standpoint this is mostly a question of getting the servlet container and everything else configured correctly. (This is non-trivial.)

THE MOVES INSTITUTE

XML Payloads: Document Style

XML-RPC is a tightly structured XML dialect. XML Document Style payloads are essentially

programmer-defined. The programmer simply passes an XML document, and is responsible for parsing it on the receiving side.

This gives the programmer much more freedom, and more unstructured data can be passed in a single transaction. The parsing and data binding tools make it not so bad to handle.

THE MOVES INSTITUTE

Which to Use?

Depends.RPC maps well to conventional object

models and can be up and running relatively quickly

XML Documents are more flexible and designs using documents can be more loosely “coupled” if designed correctly

What’s meant by “coupling?”

THE MOVES INSTITUTE

Coupling

Coupling is a subjective measure of how intertwined objects are. Two objects that interact with each other via many methods, and more importantly depend on state information they set in the other object, are tightly coupled. This makes it more difficult to replace an existing component with a new component

Loosely coupled objects do not depend heavily on state in the other object.

Other things being equal, you want loosely coupled objects; it leads to more maintainable and scalable architectures.

THE MOVES INSTITUTE

Coupling and Document Style

It’s possible to design more loosely coupled web services using document-style designs. One technique for doing this is to keep state information in the document being passed itself, rather than in the objects.

No guarantees, though—you can design tightly coupled systems in any language

And, again, you can often get up and running with XML-RPC faster

THE MOVES INSTITUTE

Advertising Web Services

So someone has a web service. How do you connect to it?

If you’re writing both sides you can make lots of assumptions. But if you’re connecting to someone else’s, you don’t’ have that luxury

Web Service Description Language (WSDL) describes the “end point” of the web service so that others can connect to it

It includes information about defined types, descriptions of messages, bindings, etc.

THE MOVES INSTITUTE

WSDL

Defined by W3C

Typically includes schema information for the XML being passed, maps messages to specific elements described in the schema, ports that define input and output messages, bindings, and services

See http://www.w3.org/TR/wsdl#_wsdl for an example

THE MOVES INSTITUTE

WSDL & HLA

The latest release of HLA, “HLA Evolved”, has a WSDL interface

HLA1516EWSDL

Stub CodeGenerator

StubCode

SimulationCode

Web ServiceRTI Calls

RTI

.java

.cpp

C#

etc

THE MOVES INSTITUTE

WSDL & HLA

This can be useful in some instances

• Existing C4I system has web services; write some glue code to make it a federate

• Bridge across a WAN

Drawbacks:

• Much lower performance (~3% of Java/C++)

• Somewhat dodgy implementations in the web services world

THE MOVES INSTITUTE

WSDL & HLA

RTI

Fed A Fed BWSFed

C4IData

Plug in a federate that can talk web services as a federate; perhapsuseful if you want an all-WS federate

WS Calls

WS Calls

THE MOVES INSTITUTE

WSDL & HLA

Keep in mind that because of performance limitations WS federates will have lower throughput and higher latency; they are not completely interchangeable with normal HLA federates

THE MOVES INSTITUTE

Advertising Web Services

Universal Description Discovery & Integration (UDDI) is an XML standard for describing web services

It essentially sits one layer higher than WSDL, and provides a way for clients to find matching WSDL implementations.

THE MOVES INSTITUTE

Summary

Encapsulate XML inside of a transport, often HTTP but also possibly JMS or SMTP or XMPP

The transport layer contains XML. Often SOAP is used to contain the “real” XML payload, but something like XML-RPC can be directly placed inside the transport

The XML is processed on the server side, in the case of HTTP often by a servlet running inside a servlet container. This processes the XML, may cause something to happen by side effect, and may return or forward more XML