Parisista

WSDL is a core part of WebServices standard, but has become more of multi-headed monster. The problem — In order to be generic enough for a refrigerator to find and bind to a WebService advertised by a microwave, the WSDL specification has become incomprehensible and is now touching the 140-page mark.
Probably, the chair leaders and the participants forgot to read the charter. I quote, “Focus must be put on simplicity, modularity and decentralization.”
No wonder, alternatives (SSDL, SMEX-D, NSDL etc.) are springing up and Tim Bray (co-author of the original XML 1.0 spec.) is already calling it quits on WSDL.

Jorgen Thelin reports about WS-Management, a new spec. for managing Web Services.
A group of technology vendors that includes AMD, Dell, Intel, Microsoft and Sun Microsystems, last week published a new Web services specification designed to simplify network administration across a range of devices. Dubbed Web Services Management (WS-M), the spec describes how to use Web services as a remote management access protocol.
WS-M was originally known as WMX (Web services management extensions), and was first demonstrated at the WinHEC 2004 conference in Seattle. The spec could serve as a replacement for older standards, such as Simple Network Management Protocol (SNMP), according to the authoring companies.
What happens to WSDM (Web Services Distributed Management) Spec? IBM, & HP are backing WSDM.
How many more we need? Read the original post on WS-SPAGHETTI.

WebServices were supposed to be simple:

1. Do an HTTP GET request, pass some query parameters,
2. Retrieve XML instead of the regular HTML.
3. Process the XML and extract data.

One of the very early implementations of WebService I did, was just that. Send a GET request for news stories for a ticker symbol. Retrieve the RDF document with stories and other data. Massage retrieved data the way you want–cache it, format it, archive it. Straight-forward.
In real world, If the request happens to be more than just query parameters, do an HTTP POST of an XML document. Then SOAP comes into picture–a way to formalize the passing of parameters, generalization of target functions, abstraction of network end-points, transport and marshalling of values. SOAP was good, provided us a means of exposing the remote method calls. Then we had WSDL, a language for describing WebServices.
Then came the boom, much fuelled by rivalries between companies, and the consortium jump started by these companies. SOAP, itself has its own competitors in terms of the XML-RPC protocol.
Here is the reality–For every WS-XXX specification, claiming to enhance the security, reliability of WebServices, there is an equivalent XXX4WS already being proposed by a competing consortia formed by the rivals of the former.

1. Messaging and Transaction Coordination BPEL4WS, BTP, WSCI, WS-CAF, WS-CDL, WSCL, WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity, BPML, WSFL, XLANG, ebBPSS.
2. Reliable Messaging ebMS, WS-ReliableMessaging, HTTPR, WS-Reliability
3. WebServices Addressing WS-Eventing, WS-Addressing, WS-Routing, WS-Discovery

That’s not the definitive list, there are many other specifications, which I don’t know where to bucket, unless I pore through the specifications, use cases and relevance related to the base SOAP & WSDL specifications.
What we want is simplicity–WSDL to expose the service interface and their end-points, SOAP to exchange the payload and a protocol for doing 2-phase commit operations on the services. Bingo–95% of the applications using WebServices for SOA implementations would be covered. Rest of the 5% will customize anyway.
On the similar lines–Adam Bosworth’s latest entry.

Business Process Execution Language (BPEL) is an XML-based standard for composing WebServices to create processes. In the stack of WebServices standards it sits on top of WSDL, SOAP and XML Schema. WSDL documents of a WebService defines the execution and behavior–parameters, types, returns, error conditions, invocation etc. BPEL interconnects two or more WSDLs. BPEL as a standard defines the notation and semantics of composing two or more individual services in order to create a process.
Why a standard for composing WebService? Why not write a program in Java, C# to integrate two WebServices ?
The answer is loose-coupling–the same reason why we have WSDL for fine-grained services. Its abstraction. The loose-coupling allows for run time typing and invocation from the WSDL to the fine-grained service. Same holds true for modelling the integration of services using BPEL. BPEL proposes the notations as to how the individual services could be executed.
On a different note–While BPEL is being developed under OASIS, parallel efforts are underway:

• WSCI. Developed at W3C (Authored by HP, SUN, BEA, SAP, etc.)
• WSCL. Submitted by HP to W3C
• WSFL. Proposed by IBM (pdf)
• BPML

.Hosted at BPMI.org (Members–BEA, IBM, Fujistu, SAP, etc.)

• BPSS. Hosted at ebXML.org

Read on if you believe the analysts…
Grid Computing Adoption Rises by 75% in Six Months; Huge Growth in Business Intelligence Mirrors Grid Computing Rise in Adoption.

The Enterprise Grid Alliance was launched, with a strong focus on “Grid for the Enterprise”. Now, The GGF is focusing on the enterprise as well. The Twelfth Global Grid Forum has a plenary program with the theme of “Grids Deployed in the Enterprise”.
Now, It’s Grid Computing’s turn to go into war of words, standards, proposals for the same technology. Seen this before? Anybody?

At OracleWorld in Fall 2003 Oracle proposed a commercial grid consosrtium with an enterprise focus. Well, we already have GGF.
Why another one?
Quoted in the press–Chuck Rozwat, Oracle EVP for server technologies, told OracleWorld attendees that the company is “interested in forming a commercial Grid consortium so that, together with other members of the industry, we can define standards that make up the APIs and functions for the commercial Grid computing infrastructure.
The alliance was formally launched on 20th April, 2004.
On Board is:EMC, Fujitsu Siemens Computers, HP, Intel, NEC, Network Appliance, Oracle and Sun Microsystems. Other founding members include AMD, Ascential Software, Cassatt, Citrix, Data Synapse, Enigmatec, Force 10 Networks, Novell, Optena, Paremus and Topspin.

The Web Services Security specification set includes: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), Web Services Security UsernameToken Profile 1.0, Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas. The WSS TC is also creating additional token profiles for use with the core SOAP Message Security 1.0 specification, including the Web Services Security: SAML Token Profile, now in an advanced state of preparation.
Read more at OASIS Web Security TC website