Some thoughts caused by reading a chapter from book
" Programming Web Services with PERL"

Recently Paul me a chapter from his book " Programming Web Services with PERL"by Randy Ray , Pavel Kulchenko and asked if I want to write a review.

I started, but suddenly I realized that I describe personal feelings and thoughts regarding web services, rather then writing a review of the chapter. I decided to continue in a hope that it might be somehow interesting for WS proponents and opponents anyway.

• WS evangelists may better understand concerns of old-timers like me.

• WS opponents may find reasons to pay serious attention at WS stack of technologies.

The title for the article and summary would look like this:

Is this we call simple?!?!

Please, do not get me wrong, I never expected that distributed computing will be simple and transparent. My sarcasm comes from the fact that "simplicity" of XML messaging was(is) the biggest selling point for Web Services and XML messaging.

I study any new technologies from a position of a developer, who:

• has experience with CORBA and proprietary messaging systems like MQSeries;

• does not work for a software vendor;

• has experience in bringing together different "enterprise" systems;

As every person who knows how to get job done and succeed in the past, I meet new technologies with natural resistance:

• I have to spend my time time to study it. Is it really worth it?

• Will it stay for a while? We really want to maximize return of our investments (money and time).

• Is it really break-through or just a rehashed old news?

Knowing CORBA and working all the time with enterprise systems and dealing with distributed systems on daily basis I was really surprised, when XML based simplistic protocol was suddenly proclaimed as a 'hope-of-the-mankind' and 'the only solution' that brings different systems and platforms together.

Lets say it straight: complex problem does not have a simple solution - complexity of solution should match complexity of the problem. Note: I am a strong proponent and supporter of the KISS principle, but even XP ( eXtreme Programming ) states that a solution must NOT be 'too simple'. So, there are natural concerns regarding SOAP promises.

Initially I considered Web Services and SOAP as a vaporware and waited till people will realize real complexity of distributed computing and will start to use and improve CORBA spec and products. However, I was wrong and despite technical superiority and maturity of CORBA, WS took off and started to evolve.

WS evolution may seem impressive, but for CORBA guys it looks like: OK, those folks have faced real problems of distribute computing and started to add absolutely necessary features, lets see....

Lets draw some parallels (although very rough):

CORBA <-> WS

IDL -> WSDL

Naming+ Trader+ Query -> UDDI

IIOP -> SOAP over something

IDL compiler for language binding -> WSDL compiler for language binding

ORB library/framework -> SOAP library/framework (XML parser, protocol binding, and etc.)

There were(are) many false claims about CORBA, but it is inevitable: guys are trying to sell their products. It is up to consumers to make a choice.

Please, do not get me wrong: I am not saying that CORBA is problem free. I just wandering why it was necessary to throw away very capable infrastructure and try to build all from scratch. OK, OK, sometimes it is necessary, but I do not think that it is the case with CORBA.

Well, I guess it is enough to criticize WS and lets see what Web Services have to offer for enterprise developers nowadays.

We should admit that today WS based solutions frequently have ADVANTAGES over competing and more mature technologies.

Lets see what kind of advantages we may in WS stack:

1. It is mature enough and numerous features were added it and many of them have been standardized.

2. It has big acceptance among businesses and vendors.

3. It addresses some real business needs.

4. Etc. ( you may listen to any pro WS pitch for a complete list)

My point: I became a cautious supporter of WS stack. However, I would admit that most of my resistance comes from sad experience of dealing with very inappropriate use of the technology. Consequences of that are sometimes disastrous for businesses and profitable for vendors.

There are still concern regarding the fact that it is yet another to solve business problems by technology only. Although, WS stack might be more concerned about human aspect than CORBA.

Technology is no substitute for handshake. Ignoring of this is a common problem for technical people. It does not matter if we can automatically discover a supplier via UDDI, it is very unlikely that businesses will deal with unknown supplier without personal negotiations and other procedures, which help to establish mutual trust between partners.

My current state: I know well and do SOAP and XML-RPS, but I would like to know more: what WS stack has to offer?

So, I asked an expert in the area: Pavel Kulchenko , and he kindly sent me chapter 12 from his new book about web services.

What can I say? - I am impressed by variety of features and services in the WS stack and I want to share my impression:

(This is copy-and-paste list of terms and abbreviations from ch.12 )

<quote>

Message routing

Allows rich message exchange patterns and intermediaries

Reliable messaging

Implements guaranteed message delivery, sessions and events

Packaging

Establishes standards for packaging messages with attachments, indexing and

compression

Security

Provides authentication, authorization, confidentiality, nonrepudiation, privacy

and integrity of the information

Transactions

Allows the execution of distributed long-lived transactions

Workflow and orchestration

Describes and combines services into sophisticated end-to-end business processes.

Choreography and conversations

Documents message exchange and defines protocols each party has to comply with

Negotiation

Describes the protocol for negotiation of terms and conditions of contracts

Extended service description

Includes behavioral elements such as quality of service, preconditions and

constraints and others

Service management

Audits, monitors, and prioritizes version services usage; also provides fail over,

load balancing and service level agreement compliance

There isn't yet a full set of specifications to address all of these aspects. This chapter describes some of the techniques and specifications that aimed to fill the gaps in the web services architecture.

</quote>

Not impressed yet? Of course, there are not many new terms and some sense of 'deja vu'. It likes we saw all that before (DCOM? CORBA? ....). Personally, I do not expect anything particularly 'new', but I would like to see convenient and robust support for mandatory features in distributed computing. An we may see, that those features are her(not all, but it is still an interesting list).

Now, lets continue and mention some standards and specifications:

WS-Routing ( formerly SOAP-RP )- WS-Routing is relatively transport-independent and defines bindings to several transport protocols: HTTP, TCP, UDP, and

DIME ;

Web Services Referral Protocol (WS-Referral) ;

Packaging

MIME and SOAP with Attachments

DIME and WS-Attachments

XML Security

XML Signature Syntax and Processing (XML Signature ): for integrity

• XML Encryption : for confidentiality

• XML Key Management ( XKMS ): for key management

• Security Assertion Markup Language ( SAML ): for authentication and authorization assertions

• XML Access Control Markup Language ( XACML );

• There are also other specifications, like Extensible Rights Markup Language (XrML) for digital rights management and Platform for Privacy Preferences (P3P);

• X-KISS

Organization for the Advancement of Structured Information Standards (OASIS).

Web Services Security Language (WS-Security);

• - WS-Policy, WS-Trust, WS-Privacy, WS-Secure Conversations, WS-Federation, and WS-Authorization

Universal Description Discovery and Integration (UDDI) ;

Web Services Inspection Language ;

HTTPR- is a protocol for the reliable transport layered on top of HTTP (HTTP 1.1 to

be precise)

Orchestration (also composition and workflow )

Choreography

Coordination

Collaboration

WS-Coordination and WS-Transaction

Business Transaction Protocol (BTP)

Business Processing Execution Language for Web Services (BPEL4WS), devel oped by Microsoft, IBM, and BEA - is a long-awaited result of converging two previously competing standards: Web Services Flow Language (WSFL) from IBM, and Microsoft's XLANG , used as a XML business process language in BizTalk Server

Business Process Modeling Language (BPML) , developed by the Business Process Management Initiative.

Web Service Choreography Interface (WSCI) , developed by BEA, Intalio, SAP, and Sun.

Business Process Specification Schema -part of ebXML ( BPSS ), proposed by the UN/CEFACT Business Transition Working Group as part of the ebXML specification.

Enterprise Distributed Object Computing (EDOC) , proposed by the Object Management Group.

XML Processing Description Language (XPDL) , proposed by the Workflow Management Coalition.

Wow! Such a list rises mixed feelings:

• From one side it proves some maturity of the technology;

But: Is this what we call 'simple'?! It might be simplest solution possible (still arguable), but I cannot call it 'simple'

So, the summary:

• WS stack is yet another proof of the fact that distributed computing is a difficult topic to address;

• WS stack is matured enough and can be useful if applied properly;

• The chapter from Paul's book helped me a lot with understanding of WS stack and allowed me to choose parts of WS stack, which I will study more closely.

Konstantin Ignatyev