Designing a WSDL (Web-Services Description Language) file

This article is aimed to get a very clear picture of various binding styles and their use while designing a WSDL file. I have tried my level best to put description in a very simple and precise manner.

The Web- Service Description Language (WSDL ) is XML based service description often pronounced “Whiz-Dull” that describes the public interface to the web-service. It abstractly describes the supported operations and messages and how they are bound to concrete network protocol and message format.

Although there are lot of discussions going on various binding style and their use, there still lies the confusion on how to determine which combination of style and use to apply while designing WSDL file.

The element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal).

This gives you four style/use models:

1. RPC/encoded
2. RPC/literal
3. Document/encoded
4. Document/literal

Add to this collection a pattern which is commonly called the document/literal wrapped pattern and you have five binding styles to choose from when creating a WSDL file.

The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

Likewise, the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping only while the actual meanings make a bit more sense.

According to the WSDL 1.1 Specification, the key differences between binding styles are as follows :-

RPC Style

• This style specifies that it has an element with the name same as
that of service method name called as wrapper element.

• This element, in turn, contains an entry for each parameter and return value of this method

• This style mandates that the parameters specified must be in the specific parameter order

Document Stlye

• When the attribute is set to document style, the client understands that it should make use of XML schemas rather than remote procedure calling conventions

• This style does not contain any wrapper element. Instead the message parts appear
directly under the element

• The contains what the sender and receiver agreed on as an XML document

Within those styles, you can also have literal use and encoded use.

Literal

• Each message part references the concrete schema definition using either the element or type attribute

• In other words, data is serialized according to the given schema agreed upon by the sender and receiver, usually expressed using the W3C XML Schema Specification

Encoded

• Each message part references an abstract type using the type attribute only

• The encoding used is SOAP encoding which specifies that the serialization will be done according to the SOAP rules. SOAP 1.1 has the set of serialization rules defined which specify how objects, arrays, and structures should be serialized

Lets discuss the Pros and Cons of various style/use combinations. As mentioned earlier, we have 5 different style/use combinations

1) RPC/encoded style

Strengths
• The WSDL is very much straightforward
• The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

Weaknesses
• SOAP message contains xsi :type encoding attributes which is usually just overhead and degrades throughput performance
• However, it’s difficult to validation to message because the service method name is not defined in the schema, but is instead a WSDL definition.
• RPC/encoded is not WS-I compliant. Thus makes it difficult for other types of clients to read the WSDL and generate appropriate stubs on the client side to call the service.

2) RPC/literal style
The RPC/literal WSDL looks almost the same as the RPC/encoded WSDL except the use in the binding is changed from encoded to literal. The SOAP message for RPC/literal is same as RPC/encoded with the type encodings been removed.
Here are the strengths and weaknesses of this approach:

Strengths
• The WSDL is still about as straightforward as it is possible for WSDL to be.
• The operation name still appears in the message.
• SOAP message does NOT contain xsi :type encoding attributes
• RPC/literal is WS-I compliant.

Weaknesses
• You still cannot easily validate this message since the service method name is not defined in the schema, but is instead a WSDL definition.
What about the document styles? Do they help overcome this weakness?

3) Document/literal

The WSDL for document/literal changes somewhat from the WSDL for RPC/literal. Here are the strengths and weaknesses of this approach:

Strengths
• There is no type encoding information in SOAP message
• You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
• Document/literal is WS-I compliant

Weaknesses
• The WSDL is getting a bit more complicated. This is a very minor weakness
• The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
• There are cases where you'll need to use one of the RPC styles.
For instance, say you have the set of methods in SEI as follows :-
public void myMethod(int x, float y);
public void myMethod(int x);
public void someOtherMethod(int x, float y);

Now assume that your server receives the document/literal SOAP message. Which method should the server dispatch to? All you know for sure is that it's not myMethod(int x) because the message has two parameters and this method requires one. It could be either of the other two methods. With the document/literal style, you have no way to know which one. Instead of the document/literal message, assume that the server receives an RPC/literal message. With this message it's fairly easy for a server to decide which method to dispatch to. You know the operation name is myMethod, and you know you have two parameters, so it must be myMethod(int x, float y).


4) Document/encoded

Nobody follows this style. It is not WS-I compliant. So let's move on.

5) Document/literal wrapped

While each style has its place, under most situations the best style is document/literal wrapped. This wrapped style originates from Microsoft®. There is no specification that defines this style. This style is meant to improve on some of the weakness of doc/literal style
These are the basic characteristics of the document/literal wrapped pattern:

• The input message has a single part.
• The part is an element.
• The element has the same name as the operation.
• The element's complex type has no attributes
• The WSDL schema now has a wrapper around the parameters

Comparison between RPC/literal and Document/literal wrapped

• In the RPC/literal SOAP message, the service method name was the name of the operation.
• In the document/literal wrapped SOAP message, the service method name is the name of the wrapper element which the single input message's part refers to.
It just so happens that one of the characteristics of the wrapped pattern is that the name of the input element is the same as the name of the operation. This pattern is a sly way of putting the operation name back into the SOAP message.
So far, this article has given the impression that the document/literal wrapped style is the best approach. Very often that's true. But there are still cases where you'd be better off using another style.

Strengths
• There is no type encoding info.
• Everything that appears in the soap:body is defined by the schema, so you can easily validate this message.
• Once again, you have the method name in the SOAP message.

Weaknesses
• The WSDL is even more complicated.
• WSDL allows overloaded operations. But when you add the wrapped pattern to WSDL, you require an element to have the same name as the operation, and you cannot have two elements with the same name in XML. So you must use the document/literal, non-wrapped style or one of the RPC styles.
As you can see, there is still a weakness with the document/literal wrapped pattern, but it's minor and far outweighed by the strengths.

So, Can there be RPC/literal wrapped also ?

From a WSDL point of view, there's no reason the wrapped pattern is tied only to document/literal bindings. It could just as easily be applied to an RPC/literal binding. But this would be rather silly. The SOAP message would contain a service method name for the operation and a child element as service method name for wrapper element. Also, even though it's legal WSDL, an RPC/literal part should be a type; an element part is not WS-I compliant.

Summary

There are four binding styles (there are really five, but document/encoded is meaningless). While each style has its place, under most situations the best style is document/literal wrapped.
In general, the literal use is gaining importance, and as far as encoded use is concerned, the Web Services Interoperability Organization (WS-I) in its Basic Profile Version 1.0a of August 2003 with web ruled out the use of SOAP encoding services.

SOA vendors promise standards body home for SCA and SDO

The Open SOA (OSOA) group held a teleconference yesterday to announce new members, a new Web site and new progress on its two key specifications -- Service Component Architecture (SCA) and Service Data Objects (SDO).

The most welcome news from one analyst's perspective was the announcement that SCA and SDO are headed for a standards body to be named later with a decision coming by the end of the year. OSOA was formed last year by tech industry heavyweights BEA Systems Inc., IBM, Iona Technologies Inc., Oracle Corp., SAP AG, Sybase Inc. and Xcalia S.A. in the hopes of giving a jumpstart to SCA – which creates neutral interfaces, implementations and references that can be bound to different technology implementations – and SDO – which accesses data residing in multiple locations and formats

Noting that he felt the technical information supplied in the phone briefing was "vague," analyst Tony Baer, principal for onStrategies, said: "SCA and SDO are great ideas, but until this gets to a standards org it's kind of hard to take this seriously."

Ask which standards bodies OSOA is considering, Michael Bechauf, vice president for industry standards at SAP AG, would not name names, but did offer hints.

"The choice needs to be made based on two criteria," he explained. "One, these specifications have to do with Web services and there are a couple of well-established organizations in the Web services space. The other thing is that these specifications have to do with metadata, which basically would hint towards a notion of model driven development. Just by the choice of words that I used you can see the opportunities that we have in terms of submission and the choices that we have to make."

After the teleconference, Baer said, "They were heavily hinting that it would be OMG."

The Object Management Group's key specification is the multi-platform Model Driven Architecture (MDA), which would match OSOA's "model driven development" criterion.

Another questioner following up on the standards body issue asked what the difference was between the work OSOA is doing, as opposed to the SOA work being done by the Organization for the Advancement of Structured Information Standards (OASIS).

Ed Cobb, vice president for architecture and standards at BEA, responded that the OASIS effort, in which BEA is involved, is more focused on best practices for organizations planning SOA implementations.

"It's not really technology focused per se," he said. "What we're trying to do here with SCA and SDO is establish some core technologies for the programming model to be used by assemblers and developers in creating services. So I think it's a different level of abstraction."

For those interested in the specifics on current status of the SCA and SDO specifications, Karla Norsworthy, vice president of software standards at IBM, said there are a series of white papers on the new OSOA website.

In a brief overview of the current status of the standards, Jeff Mischkinsky, director of Web services standards at Oracle, said the specifications have been made simple enough that business analysts as well as developers can work with them.

"The main emphasis has been on simplification," he said. "If you look at the new policy work, we're making it a lot easier for an enterprise developer or assembler to specify policy hints in a simple declarative way without having to write a lot of code."

In response to a question, Mischkinsky explained that the "policy hints" technology is aimed at allowing the business analyst to work on policies for SOA applications.

"What we're doing is providing you with a simple list of enumerated choices that you can select from and then let the SCA tools generate all the code," he said.

An example of using a policy hint would be selecting a zero security level for a Web services listing job openings in a human resources application since the goal would be to allow potential candidates easy access to that information. On the other hand, for Web services containing specific employee salary information, the highest level security would be selected by the business analyst working on the application.

OSOA has also improved description of connectivity with bindings specifications for JMS, JCA and Web Services, as well as and new BPEL and PHP authoring models, Mischkinsky said. In addition, there are now draft specifications for Service Assembly; Java and C++ service authoring.

New members being introduced in the teleconference on Wednesday include Sun Microsystems Inc., Cape Clear Software Inc., Red Hat Inc., Progress Software Corp. (parent of Sonic Software Corp.), Rogue Wave Software Inc., Software AG and TIBCO Software Inc.

Service Component Architecture: Summary from IBM

Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA divides up the steps in building a service-oriented application into two major parts: (1) The implementation of components which provide services and consume other services; (2) The assembly of sets of components to build business applications, through the wiring of service references to services.

SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware APIs.


Service Component Architecture



SCA supports service implementations written using any one of many programming languages, both including conventional object-oriented and procedural languages such as Java, PHP, C++, COBOL, XML-centric languages such as BPEL and XSLT, and also declarative languages such as SQL and XQuery. SCA also supports a range of programming styles, including asynchronous and message-oriented styles, in addition to the synchronous call-and-return style.

SCA supports bindings to a wide range of access mechanisms used to invoke services. These include Web services, Messaging systems and CORBA IIOP. Bindings are handled declaratively and are independent of the implementation code. Infrastructure capabilities, such as Security, Transactions and the use of Reliable Messaging are also handled declaratively and are separated from the implementation code. SCA defines the usage of infrastructure capabilities through the use of Policies, which are designed to simplify the mechanism by which the capabilities are applied to business systems.

SCA also promotes the use of Service Data Objects to represent the business data that forms the parameters and return values of services, providing uniform access to business data to complement the uniform access to business services offered by SCA itself.

The SCA specification is divided into a number of documents, each dealing with a different aspect of SCA. The Assembly Model deals with the linking of components through wiring. The Assembly Model is independent of implementation language. The Client and Implementation specification deals with the implementation of services and of service clients -- each implementation language has its own Client and Implementation specification, which describes the SCA model for that language..."

SCA Assembly Model Overview

The SCA Assembly Model consists of a series of artifacts, which are defined by elements contained in XML files. An SCA runtime may have other non-standard representations of the artifacts represented by these XML files, and may allow for the configuration of systems to be modified dynamically. However, the XML files define the portable representation of the SCA artifacts.

The basic artifact is the Module, which is the unit of deployment for SCA and which holds Services which can be accessed remotely. A module contains one or more Components, which contain the business function provided by the module. Components offer their function as services, which can either be used by other components within the same module or which can be made available for use outside the module through Entry Points. Components may also depend on services provided by other components — these dependencies are called References. References can either be linked to services provided by other components in the same module, or references can be linked to services provided outside the module, which can be provided by other modules. References to services provided outside the module, including services provided by other modules, are defined by External Services in the module. Also contained in the module are the linkages between references and services, represented by Wires.

A Component consists of a configured Implementation, where an implementation is the piece of program code implementing business functions. The component configures the implementation with specific values for settable Properties declared by the implementation. The component can also configure the implementation with wiring of references declared by the implementation to specific target services.

Modules are deployed within an SCA System. An SCA System represents a set of services providing an area of business functionality that is controlled by a single organization. As an example, for the accounts department in a business, the SCA System might cover all financial related function, and it might contain a series of modules dealing with specific areas of accounting, with one for customer accounts, another dealing with accounts payable. To help build and configure the SCA System, Subsystems are used to group and configure related modules. Subsystems contain Module Components, which are configured instances of modules. Subsystems, like modules, also have Entry Points and External Services which declare external services and references which exist outside the system. Subsystems can also contain Wires which connect together the module components, entry points and external services..."

From the Announcement

BEA Systems, IBM Corporation, IONA Technologies, Oracle, SAP AG, Siebel Systems, Sybase, Xcalia, and Zend Technologies today announced an effort to develop specifications and resulting collaborative technologies that simplify how organizations create and implement applications in a Service Oriented Architecture. Using the SOA Programming Model specifications, organizations can more easily create new and transform existing IT assets into reusable services that may be rapidly adapted to meet changing business requirements. Further, the specifications greatly reduce complexity associated with developing applications by providing a way to unify services regardless of programming language and deployment platform.

The specifications take advantage of an emerging trend called Service Oriented Architecture (SOA), which structures IT assets as a series of reusable services that perform business functions. By structuring applications as a series of services, IT assets become more agile and organizations are better able to align their investments in dynamic business environments. For example, using the specifications a mortgage lender can significantly reduce the complexity of automating the loan approval process by developing a set of interconnected "services" based on existing applications tying data on new home owners including credit reports to processes for ordering home appraisals and rate locking. As a result, the lender services more customers while providing more value. In addition, by adopting these specifications organizations gain a higher degree of investment protection, because they can deploy services with a variety of middleware technologies.

The SOA Programming Model specifications include the Service Component Architecture (SCA) to simplify the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats.

SCA provides an open, technology neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Vendors working to create SCA include BEA Systems, IBM, IONA, Oracle, SAP, Siebel and Sybase.

SDO complements SCA by providing a common way to access many different kinds of data. The specification reduces the skill levels and time required to access and manipulate business data. Today, a multitude of APIs are used to manipulate data. These APIs tend to tightly couple the source and target of the data making their use error-prone and subject to breaking as business requirements evolve. SDO makes it easier to use and realize the value of these APIs without having to code directly to them. Vendors working to create SDO include BEA Systems, IBM, Oracle, SAP, Siebel, Sybase, Xcalia and Zend Technologies.

SCA and SDO will be available royalty free and the authors are soliciting industry feedback. Together they offer:

*

A Language Neutral Assembly Model specification to simplify the development and usage of Business Services called: "Service Component Architecture"
*

A Java Language specification for implementing SCA service components
*

A C++ Language specification for implementing SCA service components
*

A Java Language Service Data Objects specification describing a common rendering methodology for data exchange between clients and services
*

A C++ Language Service Data Objects specification describing a common rendering methodology for data exchange between clients and services

"Service Infrastructure is a new category of software required for widespread adoption of SOA, It needs a rich ecosystem of technologies, standards, processes and partnerships to make it a reality. These new specifications — the first of their kind — represent significant progress in helping the industry achieve that goal," said Edward Cobb, vice president, architecture and standards, BEA Systems. " As an SOA leader, BEA will continue to drive standards in this area to ensure that the solid infrastructure we are providing supports composite applications from services developed on multiple platforms, using whatever technologies our customer choose. Specifications such as SCA and SDO help developers spend less time on deployment and maintenance and more on solving business problems.

"Standards have become a critical component of today's technology infrastructure," said Karla Norsworthy, vice president, software standards, IBM Software. "The rapid explosion of data and services has created challenges for developers to use all the new types of information. The collection of companies joining forces to create SCA and SDO will help ease developer pain and increase business results."

"Because the SCA specification addresses significant marketplace and user requirements for SOA development and deployment infrastructure, it has the potential to unify service runtime and tooling initiatives such as ESBs and Eclipse," said Eric Newcomer, CTO, IONA. "Our involvement as a co-author of the SCA specification is as a natural fit with IONA's ongoing participation in standards-based and open source distributed computing initiatives. Organizations adopting SOA need appropriate, efficient and cost-effective solutions. Supporting industry standards such as SCA is one of the ways we are helping our customers accomplish this."

"Open standards and specifications such as Java Enterprise Edition, Web services and WS-BPEL play a crucial role in the development of Service-Oriented Architectures," said Steven G. Harris, vice president, Java Platform Group, Oracle. "Through our work in standards organizations and now in unifying those efforts in the SCA and SDO specifications, Oracle is making it easier for organizations to realize the concrete benefits a standards based Service-Oriented Architecture can deliver today and in the future."

"We are dedicated to working with other leading companies to establish standards that allow customers to compose applications from service and data components," said Michael Bechauf, Vice President of SAP NetWeaver Industry Standards at SAP. "Today's announcement is another step forward in our commitment to help customers harness the power of Web services by leveraging the Enterprise Services Architecture (ESA), to optimize business processes and drive innovation through composite applications."

"Data value increases exponentially when business deployments extend to the true point-of-action. Services based on open standards such as SCA and SDO, accelerate management's ability to accurately reflect information-rich processes throughout their enterprise. Enabling this capability is at the heart of Sybase's Unwired Enterprise vision," said Kathleen Schaub, vice president of product marketing, Sybase, Inc. "Just as Sybase has taken a leadership role in the Eclipse Foundation, we are equally eager to contribute to this important effort."

IT Vendors Promote Service Component Architecture (SCA)


http://xml.coverpages.org/ni2005-12-07-a.html