Java Web Services：探索SOAP, WSDL和UDDI

需积分: 0 34 浏览量更新于2024-07-28 收藏 2.88MB PDF 举报

"Java Web Services" Java Web Services 是一种基于开放标准的技术，它允许不同系统间的应用程序通过网络进行通信和交互。这项技术主要依赖于三个关键组件：SOAP（简单对象访问协议）、WSDL（Web服务描述语言）和UDDI（统一描述、发现和集成）。本书"Java Web Services"由David Chappell和Tyler Jewell撰写，详细介绍了如何利用这些技术在Java环境中构建和使用Web服务。 1. SOAP（简单对象访问协议）是Web服务的基础，它定义了一种轻量级的消息传递协议，用于在分布式环境中进行远程方法调用。SOAP消息通常封装在HTTP协议中，确保了跨平台的互操作性。通过SOAP，开发者可以创建可互操作的服务，使得不同系统间的数据交换变得简单且标准化。 2. WSDL（Web服务描述语言）则是一种XML格式，用于定义Web服务的接口。它描述了服务提供的操作、使用的消息结构以及服务的网络地址。WSDL文件是公开的，允许其他开发者了解并调用服务，从而实现服务的发现和集成。 3. UDDI（统一描述、发现和集成）是一个目录服务，用于注册和查找Web服务。企业可以使用UDDI来发布自己的服务，同时也可以搜索和发现其他可用的服务。这增强了Web服务的可发现性，无论是在本地还是全球范围内。本书还涵盖了与安全、互操作性以及Java企业级技术如EJB（企业JavaBean）的集成相关的话题。特别提到了JAXM（Java API for XML Messaging）和JAX-RPC（Java API for XML-Based Remote Procedure Calls），这两个包是Java中处理SOAP消息的关键工具。此外，书中还讨论了Java Web Services与微软.NET服务的集成，展示了跨平台的Web服务实现。书中的章节安排包括： - 前言 - 阐述了Web服务的读者群体和本书的组织结构 - 提及了软件版本和本书中所用的约定 - 提供了评论和问题的联系方式 - 致谢 1. 第一章“欢迎来到Web服务”介绍了Web服务的基本概念，探讨了其在J2EE环境中的应用，以及本书将要讨论的主题。 2. 第二章“复合计算模型内部”深入解释了服务导向架构和服务对等模型，这是理解Web服务工作原理的关键。 3. 第三章“SOAP：互操作性的基石”详细阐述了SOAP在Web服务中的核心作用。 "Java Web Services"这本书提供了一个全面的指南，帮助开发者理解和实施基于Java的Web服务解决方案，涵盖了从基础概念到高级主题的广泛内容，对于想要在Java环境中构建分布式、互操作的应用程序的读者来说是一份宝贵的资源。

Java Web Services

machines, they became important for business-to-business communications. Today, fax

machines are nearly ubiquitous—you can fax in your pizza order. We expect to see the same

trend in web services. They will be used first for internal business communications before

they become part of everyday life. In all cases, though—the rapid adoption of the Web, the

slower adoption of the fax machine, and the current adoption of web services—the same

factor has enabled the paradigm shift. That factor is a standards communications mechanism.

Whether the standard be the phone line and FAX protocols, the TCP/IP stack and HTTP

(together with the phone line and modem protocols), or the web service protocols, standards

have been, and continue to be, the key factor in enabling the acceptance of new technologies.

1.2.1 Industry Drivers

Many tangible drivers make web services technology attractive, both from a business and a

technical perspective. Classic Enterprise Application Integration (EAI) problems require

applications to integrate and interoperate. Even within a particular business unit, there exist

islands of IT infrastructure. For example, a Customer Relationship Management (CRM)

system may have no knowledge of how to communicate with anything outside of its own

application suite. It may need to communicate with a third-party Sales Order system so it can

know about new customers as soon as they place their first order.

Corporate acquisitions and mergers are also an issue. Entire parallel business application

infrastructures have to be synchronized or merged. Business partners such as suppliers and

buyers need to collaborate across corporate boundaries.

These EAI and B2B problems exist in abundance and are increasing exponentially. Every new

deployed system becomes a legacy system, and any future integration with that system is an

EAI or B2B problem. As the growth of integration problems and projects accelerates over the

next couple of years, the standards-based approach that web services offer makes adopting

web services technology an attractive option for companies that need to cost-effectively

accomplish seamless system integration.

1.2.2 Lessons Learned from Recent History

Some industry analysts claim that the web service model is causing a paradigm shift that will

change the way distributed computing is done forever. Others say that this model is just a fad

that will go away soon. Currently, web services is still very much in the hype phase. Drawing

parallels to other new technologies can teach us important lessons.

Other distributed-computing models have had an opportunity to garner universal acceptance

and adoption, yet they have not. While these models offer great technical advantages for

solving real problems, none have achieved the massive widespread adoption that their

proponents had hoped for. This is largely due to their proprietary nature and the inevitable

vendor lock-in. Though COM/DCOM had a widespread following, it could not permeate an

enterprise because it was limited to Microsoft platforms. CORBA was controlled by the

OMG, a neutral standards body. However, software availability was a problem. There were

really only two robust vendor implementations: Iona and Visigenic.

Forcing middleware infrastructure down the throats of other departments and business

partners is not easy. Both CORBA and DCOM required that a piece of the vendor-supplied

middleware be installed at every node of the system. You can't always force a business

Java Web Services

partner to install a piece of your software at their site for them to be able to participate in

business transactions with your systems. Even within the four walls of an organization,

agreeing upon and rolling out an enterprise-wide middleware solution is a huge, concerted

effort. CORBA implementations eventually achieved cross-vendor interoperability, but by

then it was too late; the wave had already passed.

Crossing corporate boundaries in a secure, reliable fashion is key. If you go back only as far

as 1996 to 1997, you would have seen every trade magazine talking about a world of

distributed CORBA objects happily floating around on the Internet, discovering one another

dynamically and communicating through firewalls. Standards were proposed for firewall

communications, and IIOP was going to be adopted by all major firewall vendors as a

recognizable protocol. It just never happened—partly due to the aforementioned adoption

problems and partly due to widespread adoption and general acceptance of HTTP as a

firewall-friendly protocol.

1.2.3 Why Web Services, and Why Now?

What is so different about web services, and why are they poised for success, whereas other

preceding technologies have failed to achieve widespread adoption? The answer lies in the

challenge that every organization faces today: to create a homogeneous environment while

still leveraging its core abilities and existing applications. IT needs a simple, platform-neutral

way of communicating between applications.

For starters, XML is ideal for representing data. IT developers have had exposure to XML for

a few years and they understand what it's good for. Even though the average IT developer

hasn't yet become a walking XML parser, by now most developers understand the concepts

behind XML and how it can be used.

Also, the base technologies of SOAP, WSDL, and UDDI are not themselves very exciting;

they are just new dressings for the same old distributed-computing model. What draws people

to them is the promise of what they enable. Finally, we have a platform-neutral

communication protocol that provides interoperability and platform independence. A

bidirectional conversation may occur between a Biztalk server and a set of hand-rolled Perl

scripts. The Perl scripts may be simultaneously involved in a conversation with a set of

applications held together by a J2EE-based application server or a message-oriented

middleware (MOM) infrastructure. The minimum requirement is that each participant in the

multiparty collaboration knows how to construct and deconstruct SOAP messages and how to

send and receive HTTP transmissions.

The heavy involvement of the Microsoft camp and the J2EE camp in web services is good for

everyone. It's advantage is not about .NET versus J2EE or .NET versus SunONE; it's about

the fact that you no longer have to let that debate or choice get in the way of achieving

interoperability across the enterprise. The programming languages and associated

infrastructure of each respective camp will continue to coexist and will remain "camps" for a

long time.

1.2.3.1 Low barrier to entry means grass-roots adoption

The widespread adoption of web services can be predicted by drawing parallels to the CGI

phenomenon discussed earlier.

Java Web Services

Similar conditions exist today. The straightforward approach that SOAP takes—XML

messages sent over HTTP—means that anyone can grab Apache SOAP and start exchanging

data with the application owned by the guy down the hall. There isn't any overly complex,

mysterious alchemy involving a strategic architecture group that takes two years to figure out.

A corporate-wide infrastructure adoption shift doesn't need to occur for a company to start

working and benefiting from web services; companies can be selective about how and where

they adopt these technologies to get the best return on their investment.

1.3 Web Services in a J2EE Environment

A common thread found throughout various web services specifications is the regular

reference to web services "platforms" and "providers." A web services platform is an

environment used to host one or more web services. It includes one or more SOAP servers,

zero or more UDDI business registries, the security and transaction services used by the web

services hosted on it, and other infrastructure provisions. A web services provider is generally

considered a vendor-supplied piece of middleware infrastructure, such as an ORB, an

application server, or a MOM. The provider may fully supply a platform, or it may deliver

some base J2EE functionality plus some web service add-ons.

Web services are a new approach for exposing and advertising enterprise services that are

hosted on a platform. These platform services still have a variety of enterprise requirements,

such as security, transactions, pooling, clustering, and batch processing. Web services do not

provide these infrastructure capabilities, but expose the services that do. J2EE and .NET still

play an important role in the enterprise as platform definitions: they define the behavior of

core capabilities that every software program needs internally. Web services, however, offer a

standard way to expose the services deployed onto a platform.

An important question is, "What is being web service enabled?" If the answer is the business

systems that run the enterprise, then the role of J2EE in the whole web services picture

becomes abundantly clear. The core requirements of a web service enabled ecosystem are the

same as they have always been—scalability, reliability, security, etc. Web services provide

new ways of wrapping things at the edge of the enterprise, but if you poke your head through

the web services hype, the requirements for holding together your core systems don't change

that much. The implemention of the web services backbone should still be based on the J2EE

architecture. Web services and J2EE come together at multiple points. The use of each J2EE

component depends on the application's requirements, just as it did prior to the advent of web

services. If the nature of the web service is for lightweight, quick-and-dirty processing, then

use a web container and implement the web service directly as a JSP. If the solution requires

a distributed component model, then use EJB. If the solution requires a highly distributed,

highly reliable, loosely coupled environment, then use JMS. Naturally, any of these

combinations is allowed and encouraged, as illustrated in Figure 1-4.

Java Web Services

Figure 1-4. SOA based on a J2EE backbone

1.4 What This Book Discusses

This is a book on Java and web services. It is for developers who need to develop client- or

server-side programs that either use web services or are exposed as web services. Web

services are built on XML and have specifications that focus on the XML nature of the

technology. These specifications do not discuss how these technologies might be bound to a

particular programming language such as Java. As a result, a plethora of industry technologies

that facilitate Java/web service integration have been proposed.

This book introduces the basics of SOAP, WSDL, and UDDI, and then discusses some of the

different Java technologies available for using each of these platforms within a Java program.

The technologies we've chosen range from open source initiatives, such as the Apache

project, to big-ticket commercial packages. One reason for touching on so many different

packages is that the web services story is still developing; a number of important standards are

still in flux, and vendors are providing their own solutions to these problems. Of course, this

book looks at the standards efforts designed to consolidate and standardize how Java

programs interface with web services. Most notably, this book discusses Java/XML

technologies, such as JAXR, JAX-RPC, and JAXM, and how they can be used in a web

services environment.

These standards are still works in progress; their status may be clarified by the time we write a

second edition. In the meantime, we thought it was important (and even critical) to show you

how things look. Just be aware that changes are certain between now and the time when these

standards are finalized and actual products are released.

Additionally, for developers who are producing J2EE applications, this book discusses

different technologies that are being proposed to web service-enable standard J2EE

applications. This book discusses how a web service facade can integrate with a J2EE

infrastructure. It also introduces some of the standards efforts proposed for solidifying this

work.

剩余248页未读，继续阅读

aulbath

粉丝: 0
资源: 10

Java Web Services：探索SOAP, WSDL和UDDI

RESTful Java Web Services

Java Web Services教程

关于java web方向的书籍推荐

程序包javax.jws不存在

基于JWS的Web Service

创建基于JWS的Web Service

(Java API for RESTful Web Services

java应用服务器包含哪些模块

cxf javax.xml.ws.Service

javaweb外文文献

最新资源