使用SOAP构建网络服务实战指南

需积分: 10 5 浏览量更新于2024-07-28 收藏 1.11MB PDF 举报

"Programming Web Services with SOAP" 是一本由Doug Tidwell、James Snell和Pavel Kulchenko合著的书籍，由O'Reilly出版社在2001年首次出版，主要介绍了使用SOAP（简单对象访问协议）、WSDL（Web服务描述语言）和UDI（通用描述、发现和集成）来构建分布式Web服务应用程序的技术。书中详细讲解了这些标准背后的XML，以及如何在Java和Perl等流行工具包中应用它们，并涉及安全性和企业级问题。本书结构清晰，读者既可以按顺序阅读，也可以根据兴趣直接跳到特定章节学习。具体章节内容如下： 1. 第一章介绍了Web服务的背景，讨论了即时集成和Web服务技术栈的概念，帮助理解Web服务在现代IT环境中的作用。 2. 第二章详细解释了SOAP的工作原理，涵盖了SOAP信封、头部、主体、错误、编码和传输方式等核心概念，以XML消息传递为线索进行阐述。 3. 第三章通过实例演示如何在Perl、Visual Basic、Java和C#中使用SOAP工具包创建基本的Web服务。 4. 第四章则展示了实际的Web服务示例，允许注册用户对数据库中的文章进行添加、删除或浏览操作，实践性较强。 5. 第五章深入WSDL，从XML和编程角度出发，阐述如何使用WSDL简化客户端编写，并讨论复杂的消息模式。 6. 第六章介绍了UDDI项目和WS-Inspection标准，讲解如何发布、发现和调用Web服务，以及WSDL和UDDI的最佳实践。 7. 第七章构建了一个使用SOAP、WSDL及相关技术的Perl和Java之间的点对点(P2P)Web服务应用。 8. 第八章关注Web服务的安全问题，重点讨论了Microsoft Passport、XML加密和数字签名。 9. 第九章分析了当前Web服务技术的不足之处，描述了标准化工作的进展，并预测了未来Web服务领域的竞争焦点。 10. 附录A总结了Web服务的各种标准，如打包、安全、事务、路由和工作流，并提供了更多信息来源。 11. 附录B为理解WSDL和UDDI提供了XML模式规范的简介。 12. 附录C包含了书中所有程序的完整源代码。该书不仅适合初学者入门，也对有经验的开发者具有参考价值，是掌握Web服务开发的重要参考资料。

Programming Web Services with SOAP

page 12

ebXML

ebXML is a suite of XML-based specifications for conducting electronic business.

Built to use SOAP, ebXML offers one approach to implementing business-to-business

integration services.

1.3.2 Discovery

The discovery layer provides the mechanism for consumers to fetch the descriptions of

providers. One of the more widely recognized discovery mechanisms available is the

Universal Description, Discovery, and Integration (UDDI) project. IBM and Microsoft have

jointly proposed an alternative to UDDI, the Web Services Inspection Language (WS-

Inspection). We will discuss both UDDI and WS-Inspection in depth (including arguments for

and against their use) in Chapter 6.

1.3.3 Description

When a web service is implemented, it must make decisions on every level as to which

network, transport, and packaging protocols it will support. A description of that service

represents those decisions in such a way that the Service Consumer can contact and use the

service.

The Web Service Description Language (WSDL) is the de facto standard for providing those

descriptions. Other, less popular, approaches include the use of the W3C's Resource

Description Framework (RDF) and the DARPA Agent Markup Language (DAML), both of

which provide a much richer (but far more complex) capability of describing web services

than WSDL.

We cover WSDL in Chapter 5. You can find out more information about DAML and RDF

from:

http://daml.semanticweb.org/

http://www.w3.org/rdf

1.3.4 Packaging

For application data to be moved around the network by the transport layer, it must be

"packaged" in a format that all parties can understand (other terms for this process are

"serialization" and "marshalling"). This encompasses the choice of data types understood, the

encoding of values, and so on.

HTML is a kind of packaging format, but it can be inconvenient to work with because HTML

is strongly tied to the presentation of the information rather than its meaning. XML is the

basis for most of the present web services packaging formats because it can be used to

represent the meaning of the data being transferred, and because XML parsers are now

ubiquitous.

SOAP is a very common packaging format, built on XML. In Chapter 2, we'll see how SOAP

encodes messages and data values, and in Chapter 3 we'll see how to write actual web

services with SOAP. There are several XML-based packaging protocols available for

Programming Web Services with SOAP

page 13

developers to use (XML-RPC for instance), but as you might have guessed from the title of

this book, SOAP is the only format we cover.

1.3.5 Transport

The transport layer includes the various technologies that enable direct application-to-

application communication on top of the network layer. Such technologies include protocols

like TCP, HTTP, SMTP, and Jabber. The transport layer's primary role is to move data

between two or more locations on the network. Web services may be built on top of almost

any transport protocol.

The choice of transport protocol is based largely on the communication needs of the web

service being implemented. HTTP, for example, provides the most ubiquitous firewall support

but does not provide support for asynchronous communication. Jabber, on the other hand,

while not a standard, does provide good a asynchronous communication channel.

1.3.6 Network

The network layer in the web services technology stack is exactly the same as the network

layer in the TCP/IP Network Model. It provides the critical basic communication, addressing,

and routing capabilities.

1.4 Application

The application layer is the code that implements the functionality of the web service, which

is found and accessed through the lower layers in the stack.

1.5 The Peer Services Model

The peer services model is a complimentary but alternative view of the web services

architecture. Based on the peer-to-peer (P2P) architecture, every member of a group of peers

shares a common collection of services and resources. A peer can be a person, an application,

a device, or another group of peers operating as a single entity.

While it may not be readily apparent, the same fundamental web services components are

present as in the peer services architecture. There are both service providers and service

consumers, and there are service registries. The distinction between providers and consumers,

however, is not as clear-cut as in the web services case. Depending on the type of service or

resource that the peers are sharing, any individual peer can play the role of both a service

provider and a service consumer. This makes the peer services model more dynamic and

flexible.

Instant Messaging is the most widely utilized implementation of the peer services model.

Every person that uses instant messaging is a peer. When you receive an invitation to chat

with somebody, you are playing the role of a service provider. When you send an invitation

out to chat with somebody else, you are playing the role of a service consumer. When you log

on to the Instant Messaging Server, the server is playing the role of the service registry—that

is, the Instant Messaging Server keeps track of where you currently are and what your instant

messaging capabilities are. Figure 1-7 illustrates this.

Programming Web Services with SOAP

page 15

Chapter 2. Introducing SOAP

SOAP's place in the web services technology stack is as a standardized packaging protocol for

the messages shared by applications. The specification defines nothing more than a simple

XML-based envelope for the information being transferred, and a set of rules for translating

application and platform-specific data types into XML representations. SOAP's design makes

it suitable for a wide variety of application messaging and integration patterns. This, for the

most part, contributes to its growing popularity.

This chapter explains the parts of the SOAP standard. It covers the message format, the

exception-reporting mechanism (faults), and the system for encoding values in XML. It

discusses using SOAP over transports that aren't HTTP, and concludes with thoughts on the

future of SOAP. You'll learn what SOAP does and how it does it, and get a firm

understanding of the flexibility of SOAP. Later chapters build on this to show how to program

with SOAP using toolkits that abstract details of the XML.

2.1 SOAP and XML

SOAP is XML. That is, SOAP is an application of the XML specification. It relies heavily on

XML standards like XML Schema and XML Namespaces for its definition and function. If

you are not familiar with any of these, you'll probably want to get up to speed before

continuing with the information in this chapter (you can find information about each of these

specifications at the World Wide Web Consortium's web site at http://www.w3c.org/). This

book assumes you are familiar with these specifications, at least on a cursory level, and will

not spend time discussing them. The only exception is a quick introduction to the XML

Schema data types in Appendix B.

2.1.1 XML Messaging

XML messaging is where applications exchange information using XML documents (see

Figure 2-1). It provides a flexible way for applications to communicate, and forms the basis of

SOAP.

A message can be anything: a purchase order, a request for a current stock price, a query for a

search engine, a listing of available flights to Los Angeles, or any number of other pieces of

information that may be relevant to a particular application.

Figure 2-1. XML messaging

Because XML is not tied to a particular application, operating system, or programming

language, XML messages can be used in all environments. A Windows Perl program can

create an XML document representing a message, send it to a Unix-based Java program, and

affect the behavior of that Java program.

Programming Web Services with SOAP

page 16

The fundamental idea is that two applications, regardless of operating system, programming

language, or any other technical implementation detail, may openly share information using

nothing more than a simple message encoded in a way that both applications understand.

SOAP provides a standard way to structure XML messages.

2.1.2 RPC and EDI

XML messaging, and therefore SOAP, has two related applications: RPC and EDI. Remote

Procedure Call (RPC) is the basis of distributed computing, the way for one program to make

a procedure (or function, or method, call it what you will) call on another, passing arguments

and receiving return values. Electronic Document Interchange (EDI) is basis of automated

business transactions, defining a standard format and interpretation of financial and

commercial documents and messages.

If you use SOAP for EDI (known as "document-style" SOAP), then the XML will be a

purchase order, tax refund, or similar document. If you use SOAP for RPC (known,

unsurprisingly, as "RPC-style" SOAP) then the XML will be a representation of parameter or

return values.

2.1.3 The Need for a Standard Encoding

If you're exchanging data between heterogeneous systems, you need to agree on a common

representation. As you can see in Example 2-1, a single piece of data like a telephone number

may be represented in many different, and equally valid ways in XML.

Example 2-1. Many XML representations of a phone number

</phoneNumber>

</phone>

Which is the correct encoding? Who knows! The correct one is whatever the application is

expecting. In other words, simply saying that server and client are using XML to exchange

information is not enough. We need to define:

• The types of information we are exchanging

• How that information is to be expressed as XML

• How to actually go about sending that information

Without these agreed conventions, programs cannot know how to decode the information

they're given, even if it's encoded in XML. SOAP provides these conventions.

剩余224页未读，继续阅读

xinxin19881112

粉丝: 656
资源: 255

使用SOAP构建网络服务实战指南

Programming Web Services with SOAP

Web Services with SOAP.

Programming_Web_Services_with_Perl

programming web services with xml rpc

building web services with abap and sap web application server

soap编程全解，web服务开发原理

.NET Programming with Visual C++: Tutorial, Reference, and Immediate Solutions

Python Network Programming Cookbook, 2nd Edition

Python Network Programming Cookbook, 2nd Edition - 2017

spring-framework-2.0-with-dependencies.zi

最新资源