 Sample chapter from:
Web Services Implementation Guide
Authors:
Brian Travis and Mae Ozkan
About the book:
Getting value from stuff you don't own is a compelling idea. Just think, someone else has created something that has value, and has made it available to you. You can now leverage its value in ways that makes all parties richer. That's the promise of web services. You need to know about web services. The advent of standards-based web services marks a new era of system development. First mainframe, then client-server, the Web, now web services makes it possible to leverage every legacy system of the past and do so much more with your information assets.
This book will show you what a web service is, and how you can align your systems to take advantage of this new concept in system integration. This book covers the concepts and technologies of web services.
Web Services Implementation Guide is a multiple-volume set. Volume 1 shows you how to align your thinking and systems to get the most of web services. Volume 2 is a technical treatise for developers. Volume 3 discusses real-life implementations of web services solutions.
ISBN:
0964960230
|
In this chapter:
|
Sample chapter published here with kind permission of Architag International Corporation. Copyright © 2002 Architag Press
Chapter 4 Building a House of StandardsThe main goals of web services are three-fold:
- Get programs talking to each other, because we want to leverage the existing technology.
- Be cheap, compact and scalable for all parties, because we want to have web services everywhere, providing services to everyone, using any device.
- Build on the infrastructure, because it's already paid for.
The best way to get there is to build an environment based on standards that everyone agrees on.
In this chapter, we will build a house of standards showing where each one fits, and how they relate to each other. It is only by using internationally recognized standards that you can create systems that can communicate with your trading partners around the world.
Why Standards?Standards are designed to be suitable for a broad segment of users. The standards business is one that we would classify with the creation of laws and sausage. That is, if you want to respect any of them, do not watch them being made.
Standards are created by a form of government called "standards committees". By government, we do not necessarily mean some national bureaucracy that deals with everything from the definition of "free range chicken" to the defense of national borders. By government, we are talking about an organization that is chartered with deciding or determining influence.
One way of describing the people who populate standards committees is to think about your high school graduating class. Remember the guy who was really smart? This is the guy who did not really excel at anything in particular, but you knew that he would make a difference some day. This is the guy who could have gone into medicine or law or technology. He was really smart, but you knew he could probably never run his own organization because he did not have the entrepreneurial spirit. The word "nerd" comes to mind, but we mean that in the most endearing way.
That guy is now on a standards committee somewhere. He is doing his best to represent the needs of his constituency. That constituency consists of the people and organizations deemed by his employer to be important to the success of the organization. If it were up to him to come up with a standard, it would look just like his employer's specification for a particular solution.
If you put a dozen people like this in a room for a year with a typewriter, they would either run from the room screaming, or they would agree on a compromise that met the expectations of at least a majority of the members. This is how we get most of our international standards. It is the result of a dozen nerds in a room for a year.
There is not a single standard that everyone agrees is the best possible specification. Rather, standards are "good enough" to be implemented. They get their value, not from their superior technology, but from the fact that everyone agrees they are good enough.
Let us say that again. Standards are good because everyone agrees they are good.
Because standards are good enough, there are plenty of organizations that will implement them. "Plenty of organizations" means that there is a market for other organizations that want to sell their solutions. If a solution consisted of a proprietary implementation designed for two organizations to exchange information, then the market for a third-party solutions provider would be a grand total of two.
However, if everyone agrees that a particular implementation of a technology is a Good Thing, then the potential market for solution provider products is much larger. This means that there are more solution providers competing for the attention of everyone who wants a solution. This competition will provide more opportunities for everyone and drive the price down according to supply-and-demand curves.
So, standards mean that implementations are cheap.
In this chapter, we will discuss several different standards that are either completed or are under development to be completed soon.
XML is The AlphabetThe first of these important worldwide standards is XML. XML is the specification that is at the basis of all of the web services standards being implemented today.
XML stands for "Extensible Markup Language". However, its name is a misnomer. XML is not really a markup language according to the traditional definition of that term.
Rather, XML is a syntax that allows you to create your own markup languages.
XML only specifies a syntax and a set of constraints that defines a structure for marking up your information set. The actual information set that is defined is up to you.
XML does not specify a set of tags. It is your job to define the set of tags that reflects your data for your purposes.
XML is the foundation standard for our house of standards, as shown in Figure 27, XML is The Alphabet.
You can find out more about XML in Chapter 5, Extensible Markup Language (XML) on page 89.
The Schema is The VocabularyAn XML document, by itself, is not really good enough for cross-enterprise integration. Because of the syntax rules of XML, anyone can create an XML document that is perfectly conformant with the W3C XML specification, but is completely unreadable by anyone else.
That is because the W3C XML specification only defines the syntax for creating a markup language, but does not specify the tags that make up the markup language. In order to create an environment where we can use a specific set of elements with specific relationships to each other, we need two things.
- First, we need a formal specification that all parties can agree on.
- Second, we need some way to enforce that all parties are creating documents that adhere to that agreed-upon specification.
This set of tags is commonly called a vocabulary. The formal definition of the vocabulary is called a schema, and the tool that is used to enforce adherence to the vocabulary is called a validating XML parser.
There are many different schema syntaxes that have been created since XML was born. Two of these syntaxes are worldwide standards.
The first schema syntax is called the Document Type Definition (DTD). It was published along with XML 1.0 as a formal way of creating a set of tags called a "document type". The DTD has been implemented by all XML parsers that adhere to the W3C XML specification.
There are some problems with the DTD syntax, however. First of all, the DTD is expressed in a syntax that is not XML. That is, a DTD is not an XML document. Once you learn XML syntax, you need to learn another syntax in order to create your markup language or vocabulary if you use the DTD.
Another problem with the DTD is that it only has one data type, characters. The DTD was designed to describe legacy typeset documents. To do that, it was acceptable to consider everything to be a character. However, with a more modern data processing environment, it became evident that data types other than characters would be nice to have.
In 2001, the W3C adopted a schema syntax called XML Schema Definition, or XSD. XSD was designed to overcome the limitations of the DTD, and provide a standard way of defining an XML-based markup language vocabulary with rich data types. An XSD schema can be indicated by an XML document through the use of another W3C specification called "namespaces".
Continuing with our analogy of building a house of standards, Figure 28, Schema is The Vocabulary shows that schemas provide a vocabulary for XML documents.
You can find out more about schemas in Chapter 5, Extensible Markup Language (XML) on page 89.
Programming ModelsYour XML documents, whether they adhere to a schema or not, are beautiful by themselves, but really cannot do much until they are processed by an application.
There are several different programming models that can be used to process an XML document. The two most popular are the Document Object Model (DOM) and the Simple API for XML (SAX). These two programming models both process XML documents, but are radically different in their approach to the interface between your XML document and your application.
The Document Object Model provides an in-memory structure that is a tree representation of the XML document. See Figure 29, The Document Object Model.
Because of its static nature, programming using the DOM is very easy. Once the document is loaded, the entire structure becomes available to the programmer by using many different built in methods and properties.
The main drawback of the DOM is its large memory footprint. The size of the document in-memory will vary according to the size of the document and the complexity of the structure, but it is at least twice the size of the original XML document, after accounting for Unicode bloating.
So what if you have large documents, or are running in an environment that has a small memory footprint? You can use another popular programming model, SAX.
SAX reads an XML document and sends a series of events to a program. The program needs to create "handlers" that listen for these events and do something useful. SAX is illustrated in Figure 30, The Simple API for XML.
As a result, the SAX model is very fast and efficient, because it provides information about the document as the document is read. However, it is harder to program, because all of the management of the document structure is the responsibility of the programmer.
Continuing our house of standards, you can think of programming models as creating speech. That is, doing something with the vocabulary that was defined using the XML document and schema.
You can find out more about programming models in Chapter 6, Programming Models on page 121.
The Simple Object Access Protocol (SOAP)The next standard is probably the most important protocol for web services. The Simple Object Access Protocol (SOAP) started life as a way to make it easier to access objects over heterogeneous platforms.
The problem with heterogeneous platforms is that they each speak a different language. They are also difficult to integrate because they are on different physical machines, with all of the networking and firewall considerations that come with that.
SOAP was designed to be a standard envelope for delivering method invocations across different platforms. A SOAP document usually takes the form of an HTTP POST document, which means it can be created easily and read by any HTTP server you have. Inside the payload of the POST document is an XML document. To illustrate SOAP, think about making a request of a business partner about the status of a part required for manufacture. This is shown in Figure 32, SOAP for RPC.
In this situation, a SOAP request document has the information to ask for the product lead time. That information is packaged in a standard way by using the open standards HTTP and XML. TheWeb server at the vendor receives this package, parses it to find out what the request is, then initiates a workflow to determine what the product lead time is.
Then, the vendor's system will create a SOAP response document, which is also encapsulated as an HTTP package, and sends it back to the customer. The customer will receive the document, parse it to determine the information returned, and continue with his process.
In this example, we see a synchronous process. That is, the customer will send the request and wait for a response before moving on. SOAP can also be used for asynchronous business document transportation, as shown in Figure 33, SOAP for Messaging.
In this example, a business document is sent from a customer's procurement application to a vendor's resource planning application. This document is also packaged inside of an HTTP POST document, so it can easily be read by the vendor'sWeb server.
The vendor reads the document, enters the order, and sends back a confirmation that the order has been received.
Several days later, the goods are shipped and it is time to invoice. This is shown in Figure 34, SOAP Business Document Response.
The vendor now creates the SOAP request document, which contains another business document, the invoice. The customer receives it, parses the document to determine its contents and structure, then enters it into an accounts payable system.
Then, the customer creates a SOAP response document to acknowledge that the invoice was received, and will be paid.
The only difference between SOAP for RPC and SOAP for Messaging is conceptual. The same standards are being used, but the way of dealing with the data is slightly different.
Adding to our house of standards, we need three more entries, as shown in Figure 35, SOAP is The Envelope.
Low level protocols, like TCP and UDP, form the equivalent of the post office. This is the infrastructure that moves the packages around the network. On top of that are the transport protocols, HTTP, SMTP, and FTP, that can be used to reliably get messages from one place to another. These protocols are the physical-world equivalent of the mailman.
Finally, SOAP provides a standard envelope into which anything can be placed for transport.
You can find out more about SOAP in Chapter 7, Simple Object Access Protocol (SOAP) on page 139.
SOAP Implementations as FrameworksSOAP, by itself, is about as useful as a paper envelope. That is, anything can be put inside, with no rules guiding the process.
There have been several initiatives to formalize certain parts of the SOAP specification to provide interoperability and reliable messaging.
BizTalk FrameworkOne of the first of these frameworks was BizTalk. BizTalk was created by a consortium of about 80 companies that needed a way of reliably transporting messages between trading partners. The BizTalk specification was actually created at the same time as the SOAP specification. In fact, the first draft of BizTalk created its own envelope for sending business documents.
With the second draft of the BizTalk Framework, the designers extended the SOAP envelope to provide the reliable messaging, routing, and identification that is critical to any robust e-commerce application.
You can learn more about BizTalk in Chapter 10, Web Service Frameworks on page 219.
ebXMLAnother initiative to use SOAP as a transport envelope was a team driven by the United Nations body for Trade Facilitation and Electronic Business (UN/CEFACT) and OASIS, an XML industry group.
Their work, ebXML Electronic Business XML), was designed to provide an XML-based infrastructure to facilitate global trade. Their goal was to lower the barriers of entry for small and medium size enterprises and developing nations around the world.
The ebXML SOAP document has similar functionality to the BizTalk Framework document.
You can learn more about ebXML in Chapter 10, Web Service Frameworks on page 219.
Web Services Description Language (WSDL)SOAP provides a standard envelope, but how do we know what to put inside of that envelope? How do we know how to construct the body of the envelope and where to send it? How do we know how to interpret the SOAP response document when it comes back from the service?
To answer these questions, we need some kind of specification. If you and I wanted to do business, you could post your specification on a Web site or give me a paper. I could then take that information and code my system to create a SOAP request and interpret the SOAP response. However, this reliance on humans will certainly make things more difficult, and will introduce the possibility of error.
Just like a schema is a formal description of the XML document, we need a formal description of our web service interactions.
That formal description is called the Web Services Description Language, WSDL. WSDL is a W3C specification that describes the services and operations that a web service offers, and then specifies in detail how to create and interpret both sides of the transaction.
The WSDL document acts as a contract for enabling web service interaction. The conversation between the client and the server is illustrated in Figure 36, WSDL Contract Negotiation.
Usually at design time, a client application will ask the web service what kind of services and operations it offers. The web service will reply with a complete list and detailed information about how to make them work.
The WSDL document forms a web services contract, as shown in our house of standards in Figure 37, WSDL is The Contract.
You can find out more about WSDL in Chapter 8, Description and Discovery on page 165 and WSDL Syntax on page 170.
Universal Description, Discovery, and Integration (UDDI)We need one more piece before we can start using web services. As a review, we now know that XML provides an open data description that anyone can read with an XML parser. SOAP provides a cross-platform envelope for reliable data transfer. WSDL describes web services by specifying details for a two-way SOAP transaction.
But what if we have a great web service that we want to tell everyone about? How do we describe our service and get the word out? Then, how do others discover that we have this great service? We need some kind of phone book for web services. That phone book is the Universal Description, Discovery, and Integration (UDDI) initiative.
UDDI was created by a consortium of organizations that needed a standard way of describing and discovering web services. The UDDI framework consists of a series of five powerful servers around the globe. These five servers work using the DNS model, so any additions or changes to one gets propagated among the rest within 48 hours.
The UDDI servers maintain a database called the UDDI Business Registry (UBR). The UBR has information about organizations in three different areas, which are shown in Figure 38, UDDI Business Registry.
The white pages has information about an organization, such as the name of the organization, its physical address, telephone numbers, and Web site information. Each organization can have as many yellow pages entries as necessary. A yellow page entry describes a single product or service, and can be classified according to a number of different taxonomies, such as geographical area, industry code, product type, etc.
A green pages entry tells the discoverer how to "do" e-commerce with the organization. This might be a pointer to a Web site for more information, or it can be a telephone number of someone in the sales department. It can also be a reference to a WSDL document.
Adding UDDI to our house of standards, we can think of it as a phone book. You can find out more about UDDI in UDDI on page 180.
Web Services Interoperability (WS-I)The good news is that we have all these standards that can we can use to provide a baseline for communicating between organizations. The bad news is that there are too many standards, and the standards are so flexible that two parties can interpret them in different ways and be completely incompatible.
This problem is showing up as vendors try to build tools to allow ubiquitous interoperability among all parties.
Several high-profile vendors are attempting to fix this problem by forming an organization devoted to interoperability among web services. This organization,Web Services Interoperability (WS-I) is tasked with creating profiles for interoperability. Their first profile will interpret four existing standards in a single way, allowing all those who use the standards to use them in the same way. This is illustrated in Figure 40, Web Services Interoperability.
So why is not this work being done by existing standards organizations? Why do we need another industry consortium when there are already plenty around? WS-I was formed to integrate standards from other organizations. Therefore, according to the organization's documents, it was best to set up another organization to provide interoperability guidelines.
Making these four specifications work together will provide a good foundation for interoperability between vendors.
The group does not intend to be a police force for verifying that certain solutions are compatible. Rather, they will just publish these profiles, and allow the marketplace to work out the details.
Standards FrameworksCommerce usually involves two or more parties. Standardization is the key to any commerce. Mailing a letter between countries is possible because of international standards and treaties. Roads and signs are standardized. Railways work on standardized gauges. If you want to build a house, you can choose from many different products that work together because they are based on standard sizes.
Standards are very important in commerce. Once products, interfaces, and entities associated with a particular trade are standardized, it paves the way for high-volume, low-cost trading. Standards provide the infrastructure for commerce. Without standards, the parties in a transaction would need to define everything themselves. As a result, trade would be more costly and less profitable for all parties. However, the mere presence of standards is not enough. There is no lack of standards for doing e-commerce. However, these standards must be put together in an intelligent way to be effective.
A collection of standards to achieve a specific goal is called a "framework". As we write this, there is not a consensus on how web services frameworks should be put together. There are many different building blocks being built, each one solving a particular problem, such as how to send a document reliably, how to route it through intermediaries, how to apply security, and how to orchestrate the entire process from start to finish.
E-commerce applications from solution providers solve these problems in a proprietary way, at best. Data should not reside in proprietary formats in e-commerce when cross-domain interactions are required. Every specific e-commerce implementation used by an organization requires explanation with their partners. Plus, all parties need to keep up with changes.
As we move forward, frameworks will allow different organizations' architectures and implementations to integrate more effectively. The World Wide Web Consortium (W3C), Web Services Interoperability (WS-I), Universal Description, Discovery and Integration organization (UDDI), and the Organization for the Advancement of Structured Information Standards (OASIS) are among many consortiums that are working on standardized e-commerce applications, just like the standardization of roads and railways created the ability for trucks and trains carry goods for physical commerce.
In summary, standards for applications integration and communication must exist as:
- Open
- Horizontal
- International
Implementation PlanningMost current integration solutions and system architectures only address integration problems inside enterprises. They are built on distributed systems that trust each other. The clients and servers, requestors, and responders know about each other. They know their objects' names, they know the protocols that they respond to, and the languages that they speak. In a web-service environment, however, many of these things cannot be taken for granted.
Think about exposing your processes to external partners. If your internal integration architecture is applied on the Internet in a cross-enterprise integration scenario, it probably would not work. Systems on the Internet are independent and untrusted.
If your architecture for distributed computing will be built on the Internet, the integration architectures we have are not enough. The closed and proprietary standards such as COM/DCOM and CORBA cannot be deployed on the Web because they require a system where the program state can be tracked. Such a "statefull" system is opposite the Internet, which provides a stateless architecture. An organization will determine a list of services it wants to deliver over theWeb and those that they need to receive. In order to accomplish a system with such interactivity, we need a new architecture that uses open protocols, languages and standards to turn these new business ideas into a reality.
When two external applications are integrated, they should be architected such that the client is unaware of the implementation details of the server. The only knowledge required is the information required to call the server, and what to expect in return. This is called "loosely coupled" architecture, and we discuss it on Chapter 9, Integration Models on page 187.
Today when organizations pass paper documents from one to another, they do not know each other's implementation details. Therefore, some electronic equivalent of paper, a message-based system, gives the same opportunity: hiding implementation details from one another. A standard that enables "mutual ignorance" is needed.
Real-time Service AccessIf an organization uses paper documents in order to communicate and integrate with their partners, then the integration scenario is an asynchronous process. The answer to the paper document does not come in real time. However, real-time response is a big opportunity in business. In addition to replacing paper, what if we go one step further and ask for an integration scenario where information is delivered in real-time; a synchronous integration throughout theWeb? Synchronous access gives businesses many opportunities to leverage their important business data.
We need standards that turn new business ideas into frameworks that build on top of the XML foundation. We need to standardize cross-enterprise integration. We need to digitize the contracts between two partners and formalize and automate the handshakes of communications and dialogs.
All of these, and more, will enable programs to talk to each other. Humans need sounds, mailmen, post offices, contracts, and dialogs in order to communicate. Likewise, the building blocks on top of XML need to be standardized in the digital world so that programs can talk to each other.
A New Look at Your Company's Business: Service-Oriented ViewWeb services can be deployed not only among external partners but also among departments or applications within the organization.
Application integration problems among homogeneous-platform applications are already solved. Java-based applications can be accessed with Java clients. COM-based applications can be accessed with Microsoft clients. In addition to that, in some organizations, in-house application-to-application integration problems that reside in different platforms are solved in fast and scalable solutions using EAI and middleware technologies as are discussed in SOAP in Application-to-Application Integration on page 204.
SOAP is not fast and scalable enough for high-traffic application-to-application integration just yet. Therefore, it does not suit many application-to-application integration scenarios. Binary transports with SOAP are needed for such scalability, but are not standardized yet. However, most organizations have one or more application integration solutions that already solves their application-to-application integration problems.
So how does SOAP play a role in internal application-to-application integration? An organization has different services inside its organization, such as accounting, purchasing and procurement, customer relationship management. Integration between these services within the organization can be solved by SOAP, using a web services architecture. We, as programmers and architects, have been seeing the Information Technology solutions as applications, programs and objects. However, now it is time to group already existing applications, programs and objects into service definitions.
Therefore, web services are not only embracing cross-enterprise integration.
Getting the most out of web services requires looking at applications, solutions, departments, and organizations from a "services" point-of-view and integrating these ervices by building communication blocks between them using the XML-based standards.
Integration and communication among external and internal web services will be done using XML standards. These standards are not just implemented at the communication and translation level. They will also embrace other implementation problems at the application level. Solutions to the problems such as security, reliability, routing, and versioning are required. Web services standards are being developed to offer a complete framework, an infrastructure, for doing commerce between heterogeneous applications and across organizations.
ConclusionNow that we have built a house of web services standards, it is time to use these standards in an intelligent way.
The rest of this book will show you how you can apply these standards to your web services architecture, and how they fit together.
There are many more standards that are in process right now, and we are sure there will be plenty more in the years to come. Most of these standards will be based on the standards presented in this chapter. Your understanding of this house of standards will be essential as you learn more about web services and the new standards that support them.
|
|
