web services FAQ 2

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.

The key benefits of Web Services are:

Software as a Service As opposed to packaged products, Web Services can be delivered and paid for as streams of services and allow ubiquitous access from any platform. Web services allow for encapsulation. Components can be isolated such that only the business-level services are exposed. This results in decoupling between components and more stable and flexible systems.

Dynamic Business Interoperability New business partnerships can be constructed dynamically and automatically since Web Services ensure complete interoperability between systems

Accessibility Business services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communications devices

Efficiencies Businesses can be released from the burden of complex, slow and expensive software development and focus instead on value added and mission critical tasks . Web services constructed from applications meant for internal use can be easily exposed for external use without changing code. Incremental development using Web services is natural and easy and since Web Services are declared and implemented in a human readable format there is easier bug tracking and fixing. The overal result is risk reduction and more efficient deployability.

Universally Agreed Specifications Web Services are based on universally agree specifications for structured data exchange, messaging, discovery of services, interface description, and business process orchestration.

Legacy Integration Greater agility and flexibility from increased integration between legacy systems

New Market Opportunities There will be greater feasibility to the dynamic enterprise and dynamic value chain businesses

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.

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.

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.

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?
A. No. Web services is just a new way of looking at existing implementation 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.

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.

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.

A: IONA is a standards-based company and we are helping SOAP become an open standard for business to business portal interoperability. At the same time we will be providing a best in class SOAP implementation in the iPortal Suite of products.

IONA is a co-submitter of SOAP V1.1 to the World Wide Web Consortium (W3C) and we will be actively contributing to the SOAP standardization activity.

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?

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.

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").

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.

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

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 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

A. No. The IONA Orbix E2A™ XMLBus Edition automates all of the XML handling for you.

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?
XML provides structure and type over data. Classically, XML's strength has been providing structure, both in terms of its transfer syntax (that is, the angle brackets we all know and love) and in terms of its abstract data model, the Infoset, upon which all other XML technologies are based. However, prior to the advent of XML Schemas, XML lacked a type system capable of addressing the needs of software integration technologies such as SOAP or Web Services. Now that the XML Schema specification has been ratified as a W3C recommendation, virtually every major XML vendor (including Microsoft) is burning the midnight oil to integrate XML Schema support into their platforms, applications, and tools.

What is the underlying protocol that is used to access XML Web Services?

What is the exception name that is raised from an XML web service? (E.g. The name of the exception raised on divide by zero)

Web Services in .NET enviroment

Elaborate on the differences between the different Web services offered

What is the difference between remoting & web services