![](https://csdnimg.cn/release/download_crawler_static/4884073/bg12.jpg)
Java Web Services
14
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.