First, in just two short paragraphs, give me a quick introduction to web services.
A web service is a software routine that can be invoked by a remote application implemented with a different programming language, hardware platform, and operating system. Invoking software on remote machines (either synchronously or asynchronously) has been around for a long time, but what the web services technology brings that is new to industry is its emphasis on 1) hardware and software neutrality and 2) working well across network security boundaries. The calling machine might be a PC while the machine hosting the service could be a mainframe. The call might be implemented in Java while the service might be implemented in Cobol. Web Services provide an interface layer that shields the caller from having to know any of the technical details of the implementation. Moreover, the web service consumer and the service provider can agree to talk to each other using protocols and standards (like HTTP, SOAP, and XML) that are particularly firewall-friendly, making it much easier to communicate with machines inside of other divisions, within the same corporations, or even outside of the company over the internet.
Using a piece of someone else’s software that is potentially running on another machine is hard to do because there are a number of fundamental assumptions about communication that differ from computer to computer. For example, the number of bits used to represent an integer may be 32 on one machine and 64 on another. Or consider C++, which has a hidden first parameter for many of its function calls while C never does. Even the techniques for simple data exchange can vary, since one system may expect to conform to the HTTP standard for error checking, data compression, and receipt acknowledgement, while another system may prefer the RPC standard instead. Web services is about using a set of standards to resolve such differences and thereby dramatically increase reuse and software integration across applications, platforms, and even across companies. Web Services enjoy wide support and have been embraced by all major software vendors including Microsoft, IBM, Sun, HP, and many others.
What's the difference between a service oriented architecture and web services?
The terms “SOA” and “Web Services” are frequently confused because web services are by far the most well known implementation of service oriented architectures. The term “service oriented architecture” is a more general reference to any loosely coupled architecture, where a web service is a particular kind of loosely couple architecture. A Web Service architecture is a kind of SOA that uses a number of emerging standards like WSDL, UDDI, and SOAP that collectively run on all kinds of hardware and operating systems.
What are the three main pieces of web service architectures?
The three core structural technologies that Web Service Architectures rely on - WSDL, UDDI, and SOAP - are all XML-based. This is because XML allows all information, even information about integers and floating point numbers, to be exchanged as strings. XML allows web services to effectively say “I’m passing you the floating point number 357.00” (rather than passing the possibly misunderstood bit stream 0101100101 ). By using strings rather than bit streams, XML achieves platform neutrality albeit at the frequently considerable cost of parsing overhead. XML also has mechanisms called “schemas” for defining the structure of entire objects so that an order object, for example, is structured the same on a HP running UNIX as it is on a PC running windows. The schemas themselves, as well as the data that goes into the data structures, are all exchanged in a platform neutral way with XML.
What do I need to know about UDDI?
UDDI, one of the three building blocks of web services, is a phonebook-like “directory service” that allows programs to establish visibility to local or remote software services. Service providers first register themselves with the UDDI service directory, and then other applications can find and invoke their published services. Web service consumers perform “late binding” to their service providers at runtime. A worldwide UDDI registry exists, but in practice, companies either use their own private registries or forgo the UDDI portion entirely because it’s very difficult to debug problems when the underlying implementation of an application can change unexpectedly.
What do I need to know about WSDL?
Web Services Description Language (WSDL) is the language used to fully describe a service’s interface and it is the language that UDDI registries expect to converse in. The WSDL file contains the list of services, what parameters they expect, and what the objects sent to and by them should look like. Actually, a single WSDL document can describe multiple services. Conversely, a single interface definition can be divided into multiple WSDL documents. Segmenting WSDL documents into multiple files is a common practice, but all the WSDL files that describe an interface on a remote machine can conceptually be thought of as a single WSDL document.
WSDL documents are really just XML documents that have been augmented with a particular schema that enforces the completeness and structure of the service interface definition (see our XML Schema page). The expected parameters and returned content for a service’s various messages are described in the WSDL, and the presence of this information is forced by the schema. Each document describes what machine each service is located on and what “port” that service is listening to for incoming messages.
What do I need to know about SOAP?
Once an application has established visibility to a web service, it uses the SOAP standard to talk to that service. SOAP defines the general structure of messages (each has a body and a header, for example) and mandates the message will be in XML. The very specific structure of the SOAP body is defined in the WSDL file (a company's order object might have 3 integers, 2 text fields, and 2 date fields, for example). So a web service message is usually composed by filling in the detail required by the WSDL file and then that XML is bundled up inside a SOAP message and processed a final time into HTTP packets for transmission across the network.
Web Services are supposed to make it easy and fast to assemble applications since they leverage existing software regardless of the host platform that software runs on. But web services are also a natural choice to support business process choreography, where business flows can be graphically constructed and altered by arranging icons that represent web services into what looks like an old fashion flow chart. Web services are well suited for business process execution language (BPEL). BPEL and business process modeling are all about controlling the flow of information through a corporation and talking to disparate systems and their services. So web services support BPEL well. Web services are also well suited to support Enterprise Services Buses (see our ESB page).
What are the common, serious mistakes that companies continually make with web services?
So how well do web services really work? There’s plenty of hype out there on the net, but also plenty of criticism. So where do those two extremes balance out? A number of technologies have emerged to solve the shortcomings of the basic web service technologies. How about them? Do they work? What are the most common budget-burning mistakes with projects that use web services? Are web services appropriate for every problem domain? If not, what are the alternatives? Keep your web service project and your career away from danger and order the entire book today. Don't just settle for the excerpt on this web page. The book is an easy, humorous read, it’s a business expense, and you can leverage off our experiences of getting these technologies working in the field. Click the “Buy Now” button below!