Why should I care about Web Services and SOA?

IBM Tivoli, along with other software companies, is moving headlong into Service Oriented Architecture (SOA), which is based on Web Services. This article gives a high-level introduction to these concepts, along with reasons why you care.

You will find links to lots of resources at the end of this article.

What's a Web Service??

Believe it or not, if you're reading this, you're essentially using a Web Service. Basically, an HTTP server is a web service (they can quickly get more complex than this, but this is an introduction). A web service has several characteristics:1. It is accessible via some URI. (URI=Universal Resource Identifier; this acronym is newer and normally preferred for use over "URL", which stands for Universal Resource Locator) You get to a web page using its URI; something like http://www.gulfsoft.com/blog. This URI specifies the protocol used ("http" in this case, though browsers do support other protocols, such as "ftp" and "ldap"). It also specifies the server location ("www.gulfsoft.com"), normally by hostname or IP address. The URI also specifies the port (also called an "endpoint" in different documentation) on which the resource is available. Port 80 is the default non-SSL port for the HTTP protocol, and 443 is the default SSL port (if you care, 389 is the default non-SSL port for LDAP, and 636 is the default SSL port). Finally the URI specifies the name of the resource as it is known by the host ("/blog").2. It supports some number of methods. As a browser user, you never see these methods invoked, but they are. The most commonly-executed HTTP method is GET. Other common ones are POST and PUT.3. It returns data in a structured format. Any valid web page you visit has to conform to some pre-defined structure. Normally, the document returned has a structure defined by the HTML specification. However, the requested resource may also be a .ZIP file, a GIF or JPEG image, etc. Web Services have other characteristics, too, but these are the basics.OK, that sounds like old news to me. What's so special?Glad you asked :) A "true" Web Service would actually be a specific web-based application that returns specific data. For example, you can think of a Phone Book web service. You provide a city, state, and name, and what you get returned is the phone number and address of each person matching your criteria. As an application developer, you can use this feature in the same way that you would access a local database to provide employees with information on the printers available near their desk. Currently, it's still a little painful for a non-developer to invoke one of these web services (see the GLUE resource at the end of this article for more information if you're interested). So we'll ignore the gory details and talk about Web Services in terms of how they *could* be used. The goal of Web Services is that you could use them in the same way that you currently use databases via ODBC or JDBC. For example, you could create an Excel spreadsheet that pulls data from your incident database via an ODBC connection. In this same spreadsheet, you could use a Web Service to access weather related data for each zip code in which each problem occurred. (I don't know why you would need this, but it's a bypothetical example). Allright, now what about SOA?SOA is based on the existence of Web Services. The general premise is that you will have one or more development teams that create applications (Web Services) that provide data. Then if another team needs to access the same information, that team can simply access the existing Web Service rather than going through all of the work to acquire the data. Whereas currently you might tell a development team "Oh, that's in the SYSVR2 database on host MAINFRM1", with web services, you can tell them "That's available at http://mainfrm1.acme.com:5643/thedataIwant". At this point you might be asking "If I can already do it with existing technology, why do I care??". And that's a very good question. The answer is that Web Services are defined in a consistent, published manner, as opposed to having a number of different technologies e.g. ODBC, LDAP, a file available via NFS, an Excel spreadsheet available from a UNC path, etc. - that application developers need to deal with in their applications.Basically, migrating to an SOA, by steadily creating more Web Services that provide the data that is currently available via these other technologies, will allow you to create applications more quickly in the future. And this will, among other things, reduce development costs and effort, reduce time to market, and allow you to provide more capabilities to your customers. Hopefully this brief description has provided you with a description of Web Services that allows you to appreciate how powerful they *can* be.

Resources

GLUE - allows you to invoke Web Services from the command line, along with many other functions. http://www.themindelectric.com/Web Services Introduction - from O'Reilly Web Services Essentials. http://www.oreilly.com/catalog/webservess/chapter/ch06.htmlThere are TONS of additional resources out there. You can use Google, or if you're interested in something in particular, add a comment here or send me email at Frank_Tate@gulfsoft.com and I'll help you find something.