|
Web Services
FAQ One of the primary advantages of the XML Web services architecture is
that it allows programs written in different languages on different platforms to
communicate with each other in a standards-based way. Those of you who have been
around the industry a while are now saying, "Wait a minute! Didn't I hear those
same promises from CORBA and before that DCE? How is this any different?" The
first difference is that SOAP is significantly less complex than earlier
approaches, so the barrier to entry for a standards-compliant SOAP
implementation is significantly lower. Paul Kulchenko maintains a list of SOAP
implementations at: http://www.soapware.org/directory/4/implementations which at last count contained 79 entries. You'll find SOAP
implementations from most of the big software companies, as you would expect,
but you will also find many implementations that are built and maintained by a
single developer. The other significant advantage that XML Web services have
over previous efforts is that they work with standard Web protocols—XML, HTTP
and TCP/IP. A significant number of companies already have a Web infrastructure,
and people with knowledge and experience in maintaining it, so again, the cost
of entry for XML Web services is significantly less than previous
technologies. We've defined an XML Web service as a software service exposed on the
Web through SOAP, described with a WSDL file and registered in UDDI. The next
logical question is. "What can I do with XML Web services?" The first XML Web
services tended to be information sources that you could easily incorporate into
applications—stock quotes, weather forecasts, sports scores etc. It's easy to
imagine a whole class of applications that could be built to analyze and
aggregate the information you care about and present it to you in a variety of
ways; for example, you might have a Microsoft® Excel spreadsheet that summarizes
your whole financial picture—stocks, 401K, bank accounts, loans, etc. If this
information is available through XML Web services, Excel can update it
continuously. Some of this information will be free and some might require a
subscription to the service. Most of this information is available now on the
Web, but XML Web services will make programmatic access to it easier and more
reliable. Generic Web Service
architecture The key benefits of Web
Services are:
FAQ What is a Web service?
Many people and companies have
debated the exact definition of Web services. At a minimum, however, a Web
service is any piece of software that makes itself available over the Internet
and uses a standardized XML messaging system. XML is used to encode all
communications to a Web service. For example, a client invokes a Web service by
sending an XML message, then waits for a corresponding XML response. Because all
communication is in XML, Web services are not tied to any one operating system
or programming language--Java can talk with Perl; Windows applications can talk
with Unix applications. Beyond this basic definition,
a Web service may also have two additional (and desirable)
properties:
Web services currently run a
wide gamut from news syndication and stock-market data to weather reports and
package-tracking systems. 2. What is new about Web services?
People have been using Remote
Procedure Calls (RPC) for some time now, and they long ago discovered how to
send such calls over HTTP. So, what is really new about
Web services? The answer is XML. XML lies at the core of Web
services, and provides a common language for describing Remote Procedure Calls,
Web services, and Web service directories. Prior to XML, one could share
data among different applications, but XML makes this so much easier to do. In
the same vein, one can share services and code without Web services, but XML
makes it easier to do these as well. By standardizing on XML,
different applications can more easily talk to one another, and this makes
software a whole lot more interesting. 4. What is the Web service protocol
stack?
The Web service protocol stack
is an evolving set of protocols used to define, discover, and implement Web
services. The core protocol stack consists of four
layers:
Beyond the essentials of
XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole
zoo of newer, evolving protocols. These include WSFL
(Web Services Flow Language), SOAP-DSIG (SOAP Security
Extensions: Digital Signature), and USML
(UDDI Search Markup Language). For an overview of these protocols, check out
Pavel Kulchenko's article, Web Services Acronyms,
Demystified, on
XML.com. Fortunately, you do not need
to understand the full protocol stack to get started with Web services. Assuming
you already know the basics of HTTP, it is best to start at the XML Messaging
layer and work your way up. 5. What is XML-RPC?
XML-RPC is a protocol that
uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML
and sent via HTTP POST; XML responses are embedded in the body of the HTTP
response. More succinctly, XML-RPC =
HTTP + XML + Remote Procedure Calls. Because XML-RPC is platform
independent, diverse applications can communicate with one another. For example,
a Java client can speak XML-RPC to a Perl server. What is UDDI?
UDDI
(Universal Description, Discovery, and Integration) currently represents the
discovery layer within the Web services protocol
stack. UDDI was originally created by
Microsoft, IBM, and Ariba, and represents a technical specification for
publishing and finding businesses and Web services. At its core, UDDI consists of
two parts.
The data captured within UDDI
is divided into three main categories:
Q.What are Web services?
A.Web services allow for programmatic access of business
logic over the Web. Web services typically rely on XML-based protocols,
messages, and interface descriptions for communication and access.
Q. What is the difference between using Web services and
other distributed computing paradigms such as RMI or CORBA?
A. Web services are primarily used to traverse Internet
Infrastructures (HTTP, SMTP, FTP) whereas RMI and CORBA are traditionally used
intra-enterprise. However, both RMI and CORBA assume the use of RMI everywhere
or CORBA everywhere, and as a result are not inclusive of non-RMI or non-CORBA
applications respectively. Web services are based on SOAP, which is independent
of RMI, CORBA, or other specific distributed computing systems, which means that
Web services implementations can be built using RMI, CORBA, or other
technologies. Q. Are Web services a replacement for
other distributed computing platforms? SOAP FAQ
Soap is the communications protocol
for XML Web services. When SOAP is described as a communications protocol, most
people think of DCOM or CORBA and start asking things like, "How does SOAP do
object activation?" or "What naming service does SOAP use?" While a SOAP
implementation will probably include these things, the SOAP standard doesn't
specify them. SOAP is a specification that defines the XML format for
messages—and that's about it for the required parts of the spec. If you have a
well-formed XML fragment enclosed in a couple of SOAP elements, you have a SOAP
message. Simple isn't it? There are other parts of the SOAP
specification that describe how to represent program data as XML and how to use
SOAP to do Remote Procedure Calls. These optional parts of the specification are
used to implement RPC-style applications where a SOAP message containing a
callable function, and the parameters to pass to the function, is sent from the
client, and the server returns a message with the results of the executed
function. Most current implementations of SOAP support RPC applications because
programmers who are used to doing COM or CORBA applications understand the RPC
style. SOAP also supports document style applications where the SOAP message is
just a wrapper around an XML document. Document-style SOAP applications are very
flexible and many new XML Web services take advantage of this flexibility to
build services that would be difficult to implement using RPC.
Q.What is Simple Object Access
Protocol (SOAP)? A. SOAP is an XML-based messaging framework specifically
designed for exchanging formatted data across the Internet, for example using
request and reply messages or sending entire documents. SOAP is
simple, easy to use, and completely neutral with respect to operating system,
programming language, or distributed computing platform.
Q: What does SOAP do? A: SOAP allows applications to communicate with each other
applications across the Internet. SOAP currently sends Extensible Markup
Language (XML) messages over the Hypertext Transfer Protocol (HTTP), although
mapping to other transports is possible. SOAP facilitates
application-application communication because it's compatible with existing
Internet infrastructure such as firewalls and routers. SOAP messages are
self-describing so that applications receiving them can easily understand them.
SOAP is independent of any
operating system, programming language, or object model. For example, SOAP's
neutral, standard format allows Java and CORBA applications to quickly and
easily talk to DCOM applications. Q: What's A: Q: How does SOAP relate to CORBA, especially IIOP?
A: SOAP's object model independent allows CORBA based
applications to easily communicate with COM and EJB based applications across
the Internet, using existing Internet infrastructure. SOAP is immature compared
to CORBA and IIOP in that it doesn't have all of CORBA's services and is
text-based instead of binary (IIOP's binary based protocol is more efficient on
the wire). We envision SOAP as a simple, yet effective means of bridging any two
(or more) applications across the Internet, regardless of operating system,
language, or object model. However, we still see CORBA, and CORBA-based EJB
(that is, J2EE) continuing to be vital for any enterprise's internal computing
infrastructure. The iPortal Suite, which includes Orbix 2000 for C++ and Java,
the EJB/J2EE-based iPortal Application Server, the iPortal Integration Server
for enterprise application integration (EAI) and the Portal Server itself meet
the total requirement for end-to-end e-business integration for any enterprise.
The "inside the firewall" story relies very much on CORBA infrastructure,
including IIOP, while SOAP provides the mechanism for exporting the enterprise's
external view. Q: Is SOAP suitable for use in CORBA natively, or is it
only suitable for bridging across object domains? A: SOAP is suitable for both. The SOAP transfer protocol
provides a basic skeleton that can easily be extended and therefore take its
place as an optional native CORBA protocol -- by mapping GIOP to SOAP for
example. Unlike GIOP, however, SOAP does not define any connection semantics and
its encoding rules (serialization rules) are optional. However, SOAP's basic XML
format provides the means to bridge object models and transmit enterprise data
using a language and object neutral representation.
What is new in SOAP Version
1.2?
SOAP Version 1.2 is based on a
layered and extensible model.
Is SOAP Version 1.2
internationalized?
SOAP Version 1.2 has
provisions for internationalization, including the ability to provide multiple
error messages in different languages, encodings, character sets. Applications
themselves still have to be internationalized, but that is a separate matter.
SOAP Version 1.2 itself puts no restriction to a particular
language. WSDL FAQ
WSDL (often
pronounced whiz-dull) stands for Web Services Description Language. For our
purposes, we can say that a WSDL file is an XML document that describes a set of
SOAP messages and how the messages are exchanged. In other words, WSDL is to
SOAP what IDL is to CORBA or COM. Since WSDL is XML, it is readable and editable
but in most cases, it is generated and consumed by software.
Q.What is Web Services Description
Language (WSDL)? A.After SOAP became available as a mechanism for
exchanging XML messages among enterprises (or among disparate applications
within the same enterprise), a better way was needed to describe the messages
and how they are exchanged. The Web Services Description Language (WSDL) is a
particular form of an XML Schema, developed by Microsoft and IBM for the purpose
of defining the XML message, operation, and protocol mapping of a web service
accessed using SOAP or other XML protocol. WSDL defines web services in terms of
"endpoints" that operate on XML messages. The WSDL syntax allows both the
messages and the operations on the messages to be defined abstractly, so they
can be mapped to multiple physical implementations. The current WSDL spec
describes how to map messages and operations to SOAP 1.1, HTTP GET/POST, and
MIME. WSDL creates web service definitions by mapping a group of endpoints into
a logical sequence of operations on XML messages. The same XML message can be
mapped to multiple operations (or services) and bound to one or more
communications protocols (using "ports"). Q. How do WSDL and IDL compare?
A. WSDL goes further than simply defining an object
interface (methods, parameters, and parameter types). It also defines request
and response semantics for both document passing and RPCs(link to definition of
RPC). WSDL also describes the locale of the service location within it. IDL
describes an implementation interface, but does not specify anything about where
the service actually exists. Q. Is WSDL capable of describing a software entity that
accepts documents as well as method calls? A. WSDL is capable of describing either, just as SOAP is
capable of carrying either. Basically it means SOAP, WSDL, and web services in
general think of messages at a level of abstraction capable of reflecting RPC
style interactions and also reflecting document exchange types of interactions.
Q. What is the
difference between "document exchange" and "RPC(link to definition of RPC)
style" interactions? A. Document passing is generally used in business
processes. Document passing means the entire XML message is transferred in bulk
and in the format of a specific document type, like a RosettaNet PO, fpML order,
etc. The operation on the document might be just to acknowledge its receipt.
There's no concept of a method name or input/output parameters as with RPCs.
Distributed objects invoke RPCs as method call oriented interfaces. The message
paradigm for RPCs tends to be more conversational. Q. What is the main difference between business process
driven interactions and RPC messaging? A. In the former, the point is to interact between
businesses using a predefined document type, a predefined business process flow,
and data that fits into spaces on the document. In the latter the idea is to
pass data to be consumed or processed. UDDI FAQ
Universal Discovery
Description and Integration is the yellow pages of Web services. As with
traditional yellow pages, you can search for a company that offers the services
you need, read about the service offered and contact someone for more
information. You can, of course, offer a Web service without registering it in
UDDI, just as you can open a business in your basement and rely on word-of-mouth
advertising but if you want to reach a significant market, you need UDDI so your
customers can find you. Q. What is Universal Description,
Discovery, and Integration (UDDI)? A. The Universal Description, Discovery, and Integration
(UDDI) framework defines a data model (in XML) and SOAP APIs for registration
and searches on business information, including the web services a business
exposes to the Internet. UDDI is an independent consortium of vendors, founded
by Microsoft, IBM, and Ariba, for the purpose of developing an Internet standard
for web service description registration and discovery. Microsoft, IBM, and
Ariba also are hosting the initial deployment of a UDDI service, which is
conceptually patterned after DNS (the Internet service that translates URLs into
TCP addresses). UDDI uses a private agreement profile of SOAP (i.e. UDDI doesn't
use the SOAP serialization format because it's not well suited to passing
complete XML documents (it's aimed at RPC style interactions). The main idea is
that businesses use the SOAP APIs to register themselves with UDDI, and other
businesses search UDDI when they want to discover a trading partner, for example
someone from whom they wish to procure sheet metal, bolts, or transistors. The
information in UDDI is categorized according to industry type and geographical
location, allowing UDDI consumers to search through lists of potentially
matching businesses to find the specific one they want to contact. Once a
specific business is chosen, another call to UDDI is made to obtain the specific
contact information for that business. The contact information includes a
pointer to the target business's WSDL or other XML schema file describing the
web service that the target business publishes. ebXML FAQ
Q.What is Electronic Business XML
(ebXML)? A. The ebXML initiative is sponsored by an international
group established by the United Nations (UN/CEFACT) and OASIS to research,
develop, and promote global standards for the implementation of XML to exchange
electronic business data. The ebXML architecture begins with a business process
and information model, maps the model to XML documents, and defines requirements
for applications that process the documents and exchange them among trading
partners. The ebXML group works to promote the creation of a global e-business
market place through the exchange of XML documents and messages, regardless of
geographic or political boundaries. The ebXML architecture
defines:
The ebXML initiative is intended to
allow businesses to find each other using the registry, define trading partner
agreements, and exchange XML messages in support of business operations. The
goal is to allow all of these things to be performed automatically, without
human intervention, over the Internet. There are many similarities between ebXML
and SOAP/WSDL/UDDI, and some level of convergence is already taking place with
the recent adoption of SOAP in the ebXML transport specification.
XML FAQ
Q.Do I need to know how to program
with XML to use the XMLBus? A. No. The IONA Orbix E2A™ XMLBus Edition automates all of
the XML handling for you. Q.What is Extensible Markup Language (XML)?
A. XML is a form of markup language similar to HTML, and
has a common root in SGML with HTML. It was first published by the World Wide
Web Consortium (W3C) in 1998 and has been widely adopted as an independent data
representation format. What is important about XML in the context of web
services is that XML is used not only as a message format, but also as the way
in which services themselves is defined. Therefore it is important to know a
little about XML itself, especially in the context of how it is used to define
and implement web services. XML is a markup language, and
therefore XML data is passed in the form of a document, or fragment of a
document. XML is very generic, and allows tags to be defined for almost any
purpose. What is XML
Schema? Questions
|