Q) What is a Web service?
A) 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:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL).
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration.
Web services currently run a wide gamut from news syndication and stock-market data to weather reports and package-tracking systems. For a quick look at the range of Web services currently available, check out the XMethods directory of Web services.

   Your Advertisement Goes Here

Q) What is new about Web services?
A) 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.

Q) I keep reading about Web services, but I have never actually seen one. Can you show me a real Web service in action?
A) If you want a more intuitive feel for Web services, try out the IBM Web Services Browser, available on the IBM Alphaworks site. The browser provides a series of Web services demonstrations. Behind the scenes, it ties together SOAP, WSDL, and UDDI to provide a simple plug-and-play interface for finding and invoking Web services. For example, you can find a stock-quote service, a traffic-report service, and a weather service. Each service is independent, and you can stack services like building blocks. You can, therefore, create a single page that displays multiple services--where the end result looks like a stripped-down version of my.yahoo or my.excite.

Q) What is the Web service protocol stack?
A) 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:
Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
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.

Q) Does the W3C support any Web service standards?
A) The World Wide Web Consortium (W3C) is actively pursuing standardization of Web service protocols. In September 2000, the W3C established an XML Protocol Activity. The goal of the group is to establish a formal standard for SOAP. A draft version of SOAP 1.2 is currently under review, and progressing through the official W3C recommendation process.
On January 25, 2002, the W3C also announced the formation of a Web Service Activity. This new activity will include the current SOAP work as well as two new groups. The first new group is the Web Services Description Working Group, which will take up work on WSDL. The second new group is the Web Services Architecture Working Group, which will attempt to create a cohesive framework for Web service protocols.

Q) What are Web services?
A) The universal acceptance of two key standards - TCP/IP and XML - has created the technical foundation to enable companies to share information and deeply integrate business processes. Building upon these two standards, extensive industry effort has been initiated to develop a framework for interoperability between disparate business processes. This framework is known as Web services.
Web services are self-contained, modular applications that can be described, published, located and invoked over the Internet. They perform well-defined functions both for applications and other Web services. These functions can be anything from simple calculations to complicated business processes. Through their loose-coupling and dynamic real-time discovery and binding, Web Services insulate applications from the complexity and details of other components, creating systems that are more flexible and adaptable. Security is recognized as a major impediment to wide-spread adoption of Web services.

Q) What is the Secure Transaction Platform?
A) The Entrust Secure Transaction Platform is a product portfolio that delivers security to enable Web services transactions. The Entrust Secure Transaction Platform consists of a set of Foundation Security Services that provide the building blocks for integrating authentication, authorization, digital signatures, and end-to-end encryption into transactions. These fundamental trust services are provided through Web services interfaces to allow for easy integration and deployment. Like all Entrust products, the Entrust Secure Transaction Platform strives to remove complexity, and achieve consistent and transparent enforcement of security policies across applications, platforms and services.

   Your Advertisement Goes Here

Q) How do I get started with Web Services?
A)The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.
Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. These topics are also covered in Web Services Essentials. For a comprehensive treatment of SOAP, check out O'Reilly's Programming Web Services with SOAP, by Doug Tidwell, James Snell, and Pavel Kulchenko.

Q) What is SOAP?
A) SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.

To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):

< ?xml version='1.0' encoding='UTF-8'?>
< SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
< SOAP-ENV:Body>
< ns1:getWeather xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
< zipcode xsi:type="xsd:string"> 10016< /zipcode>
< /ns1:getWeather>
< /SOAP-ENV:Body>
< /SOAP-ENV:Envelope>
As you can see, the request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).

Here is a sample SOAP response from the weather service:

< ?xml version='1.0' encoding='UTF-8'?>
< SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
< SOAP-ENV:Body>
< ns1:getWeatherResponse xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
< return xsi:type="xsd:int"> 65< /return>
< /ns1:getWeatherResponse>
< /SOAP-ENV:Body>
< /SOAP-ENV:Envelope>
The response indicates a single integer return value (the current temperature).
The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.

Q) What is WSDL?
A) The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:

Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.

WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.

Below is a sample WSDL file. This file describes the public interface for the weather service used in the SOAP example above. Obviously, there are many details to understanding the example. For now, just consider two points.
First, the < message> elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the element specifies that the service is available via SOAP and is available at a specific URL.

   Your Advertisement Goes Here

< ?xml version="1.0" encoding="UTF-8"?>
< definitions name="WeatherService"
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
< message name="getWeatherRequest">
< part name="zipcode" type="xsd:string"/>
< /message>
< message name="getWeatherResponse">
< part name="temperature" type="xsd:int"/>
< /message>
< portType name="Weather_PortType">
< operation name="getWeather">
< input message="tns:getWeatherRequest"/>
< output message="tns:getWeatherResponse"/>
< /operation>
< /portType>

< binding name="Weather_Binding" type="tns:Weather_PortType">
< soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
< operation name="getWeather">
< soap:operation soapAction=""/>
< input>
< soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice" use="encoded"/>
< /input>
< output>
< soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice" use="encoded"/>
< /output>
< /operation>
< /binding>

< service name="Weather_Service">
< documentation> WSDL File for Weather Service< /documentation>
< port binding="tns:Weather_Binding" name="Weather_Port">
< soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
< /port>
< /service>
< /definitions>

Using WSDL, a client can locate a Web service, and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. For example, check out the GLUE platform from the Mind Electric.
WSDL has been submitted to the W3C, but it currently has no official status within the W3C. See this W3C page for the latest draft.

Q) Why do Web services need enhanced security?
A) Web services are recognized as the next wave of computing to achieve efficiencies of automation and faster customer service by integrating business processes within the enterprise and with business partners. As organizations provide wider access to their sensitive information, the risk of serious damage due to malicious manipulation becomes a critical challenge.

By building on widely accepted standards that enable easier connectivity between applications, Web services simplifies the development of business-to-business applications, reducing time-to-market and greatly improving the ability to change these applications over time. At the same time, the security mechanisms required for these applications must be sufficient to protect the sensitive and valuable transactions that will use Web services. Consequently, Web services will require security technologies that go well beyond the basic Secure Sockets Layer (SSL) of the browser-driven Web - Web services require enhanced security, such as that delivered by the Entrust Secure Transaction Platform.

In addition, a security solution for Web services cannot be considered as a standalone technology issue. Organizations require consistent security implementations that can be used across their enterprise, Web portal and Web services applications. Consequently, organizations need to consider how their security solution for Web services leverages and interoperates with their security solutions for enterprise and Web portal applications.

   Your Advertisement Goes Here

Q) What are Foundation Security Services?
A) Foundation Security Services are the building blocks for integrating authentication, authorization, digital signatures, and encryption into transactions. Open and standards-compliant, Foundation Security Services deliver enhanced security capabilities broadly applicable across Web services and other server-based applications. The Entrust Secure Transaction Platform's Foundation Security Services will include:

Identification Service (Authentication)
Entitlements Service (Authorization)
Verification Service (Digital Signatures)
Privacy Service (Encryption)

Q) What is the Entrust Identification Service?
A) The Entrust Identification Service is part of the Entrust Security Transaction Platform that enables organizations to centrally control which identities are trusted for automated Web services transactions so that each Web services application does not have to manage these issues independently.

Roaming is also enabled through Entrust TruePass's ability to support authentication with smart cards. By their very nature, smart cards enable users to travel from one computer to another, gaining access to their digital ID through a PIN that is only known to them. This does require some minimum operating system, browser, and hardware requirements and increased costs to be met, so this may not be an ideal roaming scenario for large-scale deployments of users.

Q) What is UDDI?
A) 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.

First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.

Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.

The data captured within UDDI is divided into three main categories:

White Pages: This includes general information about a specific company. For example, business name, business description, and address.
Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.
Beta versions of UDDI Version 2 are available at:
Hewlett Packard
IBM
Microsoft
SAP

Q) What is the Entrust Entitlements Service?
A) The purpose of the Entrust Entitlements Service is to confirm that the entity trying to access a Web service (and other types of resources, also) has the right to do so. Like the Identification Service, the Entitlements Service makes it possible for Web services applications to focus on business logic and rely on fundamental security operations occurring centrally in the Foundation Security Services by "outsourcing" the entitlements decision.

Q) What is the Entrust Verification Service?
A) The Entrust Verification Service is part of the Entrust Secure Transaction Platform designed to deliver integrity and accountability capabilities for Web services transactions through centralized digital signatures and timestamping.

   Your Advertisement Goes Here

Q) What is the Entrust Privacy Service?
A) The Privacy Service is part of the Entrust Secure Transaction Platform responsible for encrypting information so that only designated entities can access that information. Rather than each Web services application having to understand how to encrypt information, the Entrust Privacy Service takes care of the complexity of using cryptographic keys to provide data encryption in a centralized service.

Q) Is the Entrust Secure Transaction Platform a PKI?
A) No, the Entrust Secure Transaction Platform is not a public-key infrastructure (PKI). Like all Entrust products, the Secure Transaction Platform will interoperate and leverage the enhanced security capabilities of Entrust's industry-leading PKI, Entrust Authority, but the platform is not a PKI. Entrust is employing the existing industry-leading technology, knowledge, and experience used for its PKI product portfolio to create flexible, reliable, and scalable Foundation Security Services for the Entrust Secure Transaction Platform.

Q) What standards does the Secure Transaction Platform conform to?
A) The Entrust Secure Transaction Platform provides support for major Web services and Internet security standards including SAML, XACML, XML Digital Signatures, XML Encryption, XKMS, WS-Security, X.509v3 digital certificates and CMS formats, RFC 3161 Timestamp protocol, Secure Sockets Layer (SSL) and many others. Entrust is an active participant in the creation and maintenance of many Web services standards.

Q) What is XML-RPC?
A) 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 sufficiently, 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.
To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):
< ?xml version="1.0" encoding="ISO-8859-1"?>
< methodCall>
< methodName> weather.getWeather< /methodName>
< params>
< param> < value> 10016< /value> < /param>
< /params>
< /methodCall>
The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).

Here is a sample XML-RPC response from the weather service:

< ?xml version="1.0" encoding="ISO-8859-1"?>
< methodResponse>
< params>
< param>
< value> < int> 65< /int> < /value>
< /param>
< /params>
< /methodResponse>
The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.
The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.

Q) Will the Secure Transaction Platform work with my existing Entrust products?
A) Yes. Organizations require consistent security implementations that can be used across their enterprise, Web portal and Web services applications. The Entrust Secure Transaction Platform is designed to leverage and interoperate with existing Entrust security products-Entrust Authority, Entrust Entelligence, Entrust GetAccess and Entrust TruePass-currently in use by governments and businesses for enterprise and Web portal applications.
To illustrate why this is important, consider an organization that is in the process of deploying Web services-based applications, but which also currently operates a Web portal to protect resources that are accessed by the same user group (this group could include employees, suppliers, citizens, or even other computer applications). To achieve a greater return on investment, it is important to maintain centralized control over the administration of these user identities-using Entrust Authority-so that the security is applied consistently and at the lowest total cost.

   Your Advertisement Goes Here

Q) What application servers and platforms does the Entrust Secure Transaction Platform Support?
A) The Entrust Secure Transaction Platform supports leading application servers and platforms such as BEA, IBM and Sun to extend interoperable security services across an enterprise's existing infrastructure. These services provide organizations with flexible options for integrating security into any Web services environment.

Q) What gateways does the Entrust Secure Transaction Platform support?
A) The Entrust Secure Transaction Platform integrates with VordelSecure and VordelDirector to provide comprehensive content validation, threat detection and AAA access control for XML and Web services data.

First Prev javajotter Last