In this two part Q&A, Web services pioneer Toufic Boubez explains the importance of Web services policy and why he believes service-oriented architecture can't rely on middleware. He also addresses architectural misconceptions about SOA and explains why he considers some WSDL tools an "abomination."

It's not WSDL's fault really, but it's the fault of the people who are building tools for WSDL. What has happened a lot in the last few years is that you have tools that allow you to write code, whether it's Java, .NET, C#,and then click a button and generate WSDL out of your code, which is to me an abomination. How can you write an interface after you write the code for it? It absolutely goes against everything you learn as an architect, everything you practice as an architect. You have to build a robust interface that's not going to change and then you write the code around it because you might want to change your code later on, but you better not change your interface. Unfortunately the opposite has been happening everywhere because of the tools and it's led to a lot of misuse of WSDL.

Read Boubez on SOA hardware and policy:
Part 1 | Part 2

I agree with the concept that the WSDL should be developed before the code but in practice, this isn't going to happen. Not with the current WSDL spec. It's obtuse and redundant. No one wants to deal with them directly.

The other thing about this is that some tools allow you to generate a WSDL, tweak it and then generate code for the WSDL - Axis does this. It's a very cost effective way to get the bulk of writing a WSDL done. Even if you can't do this, you can always create a codde layer that acts as a thin wrapper to the Web service that is not coupled to your application logic.

A major difference between CORBA and RMI that made RMI much easier to adopt for most developers was that RMI allowed the interfaces to be specified in Java, not in IDL. That meant one language less to worry about.

While it certainly is critical to keep the interface stable when it has been released, the developers who actually know WSDL well enough to work with it comfortably are a minority, so the tools do need to help.

My advice would be to write the interface in Java (or C# or whatever) and generate WSDL that can be tailored by hand before it is released (if necessary). That way you need fewer WSDL experts.

A major difference between CORBA and ...

I think we should ( even must) stop for a moment and try to take an unbiased look at the state of CORBA and SOAP.
That perceived ‘complexity’ of CORBA was surpassed many times over by complexities of SOAP related stack of technologies.

I think we should revalidate assumptions of CORBA being ‘complex’ and SOAP being ‘simple’ – both are untrue.

http://kgionline.com/articles/protocol_compare/doc/index.jsp

http://kgionline.com/articles/protocol_compare/doc/index.jsp

Ahem, with all my respect for you and my generally positive feelings for CORBA, I think you're bias (just a bit, but you are :-) ).

Actually your IDL defines use structs where you should use value types IMHO (yes, at least WSDL has polymorphism but structs don't :-/).

Even if once again I fully agree with you on the fact that CORBA is generally simpler, put OBVs in your example (with factories + registration code) and it will be less simple than it is.

In CORBA you have to understand by-reference and by-value passing semantics and know how to apply this... Of course, you don't have to care about this with SOAP since... everything is by-value anyway !!!

My $0.02

Have fun,

Remi

I think you're bias (just a bit, but you are :-) ).

It is no secret that I am CORBA advocate :)
I do not think that my little test is unfair. My point is to demonstrate that CORBA is simple for simple cases, much simpler than SOAP and wastly more efficient ( Do you hear that f..n fan's noise? – that is poor CPU crunching XML).

And I assume that everybody knows that CORBA can handle just about any interaction scenario and do not expect that usage should be as simple as for simple case. At least CORBA handles complex scenarios better than XML based Babylon tower so called XML based stack of protocols.

It is no secret that I am CORBA advocate :)

he he :-)

I do not think that my little test is unfair. My point is to demonstrate that CORBA is simple for simple cases, much simpler than SOAP and wastly more efficient ( Do you hear that f..n fan's noise? – that is poor CPU crunching XML).

I'm with you : your comparison's just simple and self-explanatory ! I love it, I'm only teasing with details (even if those kind of "details" can cost a lot !!).

Have fun,

Remi

http://kgionline.com/articles/protocol_compare/doc/index.jsp

Ahem, with all my respect for you and my generally positive feelings for CORBA, I think you're bias (just a bit, but you are :-) ).Actually your IDL defines use structs where you should use value types IMHO (yes, at least WSDL has polymorphism but structs don't :-/).

Even if once again I fully agree with you on the fact that CORBA is generally simpler, put OBVs in your example (with factories + registration code) and it will be less simple than it is.

In CORBA you have to understand by-reference and by-value passing semantics and know how to apply this... Of course, you don't have to care about this with SOAP since... everything is by-value anyway !!!My $0.02Have fun,Remi

by polymorphism, you mean single inheritance right?

Since I've written my own schema compiler in .NET, my bias 2 cents is XML Schema blows. RelaxNG, DTD and XMI are much better specifications. XML Schema allows far too many ways to define the same structure and leads to really ugly and nasty schemas that make little sense. I would love it if the industry dumped XML schema completely and went with RelaxNG.

peter lin

by polymorphism, you mean single inheritance right?

Or multiple, yes.
Well, it's slightly different you know, an XML doc is never an Object, but you have "polymorphic data" XML. A bit like you'd have classes with only public attributes !

WSDL / XSchema allows you to define entities in your doc that can "extend" other entities.

In IDL, value types are objects and you have real inheritance, in the OO meaning (you can override methods etc).

Since I've written my own schema compiler in .NET, my bias 2 cents is XML Schema blows. RelaxNG, DTD and XMI are much better specifications. XML Schema allows far too many ways to define the same structure and leads to really ugly and nasty schemas that make little sense. I would love it if the industry dumped XML schema completely and went with RelaxNG.peter lin

Well having experienced ISO STEP, I usually get spots on my face when I have to manipulate XML documents by program :-)

Honestly IMHO XML is good for EJB DDs, Hibernate mappings, Spring descriptors and other config files. When it comes to exchanging real-life data, or using it for integration...

Have fun,

Remi

by polymorphism, you mean single inheritance right?

Or multiple, yes.

I don't believe the XML Schema specification allows multiple inheritance. I could be wrong, since the I've read the darn spec about a dozen times and it's still confusing as hell.

Well, it's slightly different you know, an XML doc is never an Object, but you have "polymorphic data" XML. A bit like you'd have classes with only public attributes !WSDL / XSchema allows you to define entities in your doc that can "extend" other entities.In IDL, value types are objects and you have real inheritance, in the OO meaning (you can override methods etc).

Since I've written my own schema compiler in .NET, my bias 2 cents is XML Schema blows. RelaxNG, DTD and XMI are much better specifications. XML Schema allows far too many ways to define the same structure and leads to really ugly and nasty schemas that make little sense. I would love it if the industry dumped XML schema completely and went with RelaxNG.

peter lin

Well having experienced ISO STEP, I usually get spots on my face when I have to manipulate XML documents by program :-)
Honestly IMHO XML is good for EJB DDs, Hibernate mappings, Spring descriptors and other config files. When it comes to exchanging real-life data, or using it for integration...Have fun,
Remi

I suppose someone using a C++ soap driver could compile the object model so it does use multiple inheritance, but from the little that I know of gSoap, and one other C++ soap toolkit, many do not support multiple inheritance.

I like the idea of XML Schema, just not the actual specification. Though to be fair, it's not the worse spec to come out of W3C :)

peter lin

I don't believe the XML Schema specification allows multiple inheritance. I could be wrong, since the I've read the darn spec about a dozen times and it's still confusing as hell.

I don't think so, or it's just not used (would the XML-POJO binding tools would handle this ? here you have to use interfaces and proxies IMHO, gets a bit more tricky !).

I like the idea of XML Schema, just not the actual specification.
Though to be fair, it's not the worse spec to come out of W3C :)

100% agreed : HTML is far ahead :-)))

For the idea, once again all I can do is suggest you to have a look at STEP (ISO 10303) which is successfully used for product data exchange in the industry since years. The spec is far better than W3C's usual stuff, and it's so effective ! I've personnally used both STEP and XML for projects in building & construction where you manipulate huge CAD models, well you can imagine that >20Mb XML files were quite a burden for our application when it had to parse them ! Some could not even be loaded by Xerces :-/

STEP is more or less a modeling language (EXPRESS / EXPRESS-G), a data access interface (SDAI - late and early bindings) and the ASCII file format for model exchange (SPF). If you think about it they have everything you ask from XML, and it's much more clean and effective.

Now that the OSS way really begins for STEP (you already have very good commercial implementations), it's time for having a deeper look to it from an user's perspective. This stuff can save you so much time...

Have fun,

Remi

Woaw, they finally begin to understand they make it wrong since the beginning...

Now that they can see how WSDL is an ugly thing (maybe the guy woke up this morning screaming the hell out because he had a vision ???), they may discover that XML's not the best stuff we have when it comes to marshalling/demarshalling objects !

Have fun,

Remi - little by little

PS -> Paolo, 2 months left before the beer. Hope you're still pretty close to Nice : I don't forget you :-)

PS -> Paolo, 2 months left before the beer. Hope you're still pretty close to Nice : I don't forget you :-)

In fact I had hoped so, since I have been rather absent from TSS till last week. The sad thing is that I have my documents in order now, so I can leave Italy if I have to pay the bet.

Unless of course the many web services advocates "see the light" before end 2005. Still two months....

XML schema is all you need. JAXB makes marshalling and unmarshalling from the servlet IO a piece of cake. WSDL and SOAP just get in the way, exactly like EJB did. Too heavyweight for most projects. And ironically, SOAP/WSDL reduce interoperability between heterogeneous systems, when compared to pure XML-over-http with a domain-specific request/response XML schema.

XML schema is all you need. JAXB makes marshalling and unmarshalling from the servlet IO a piece of cake.

Perhaps, but maintenance is a nightmare. JAXB basically pushes you to hardcodes your schema into your application. You can always regenerate the classes, of course, but all your code that interacts with the existing JAXB classes often won't compile. On top of that, it's difficult to progammatically retrieve data from nested elements leavng you with reams of

if (node != null) {
  if (child != null) {
    if (grandchild != null) {

at least in the versions I have used.

JAXB compeltely misses the mark, as far as I am concerned. What is needed is a mapping layer from xml to custom types, not a huge set of bloated, statically accessed APIs.

This comes down to the JAXB implementation you are using. Most, like the reference implementation generate their binding logic into the generated classes, this can lead to the problems you mention.

TopLink has new object-to-XML support (which is JAXB 1.0 compliant), I'm the team lead for this project. Our implementation stores the binding information as metadata apart from the object model. This metadata is used at runtime to do the conversion. If after generating the model with the TopLink JAXB compiler you want to make a change then you can load the metadata into the TopLink Workbench and make the necessary adjustments.

TopLink also supports mapping your own object model to XML. This allows you to map any object model to any XML schema.

JAXB 2.0 (I am member of this expert group) is introducing support for generating an XML schema and bindings from an existing object model. This will be a significant improvement to the JAXB platform.

-Blaise

---

For more information on TopLink OXM

http://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp4/objectxml/index.html

---

Example - Using TopLink OXM support in a web service environment:

In this example the domain specific model objects (POJOs) are converted to an XML message using the new OXM support in TopLink. This is done with a custom serializer.

http://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp4/howto/jaxRpc11/index.htm

JAXB 2.0 (I am member of this expert group) is introducing support for generating an XML schema and bindings from an existing object model. This will be a significant improvement to the JAXB platform.

Significant improvement is an understatement. Actually, the JAXB implementation we are using (Sun's) generates .java files that I call c**p rather than code. It also creates a lot of trouble . In fact, this JAXB implementation/specification prevents many good programming practices that I would like to use in my current project. So I tend to disagree with the "pure JAXB is the solution" opinion. Maybe next specs solve these problems, as you promise.

The tech community just does't get it. Complex, esoteric technology will NEVER get widespread adoption. You develop a really sophisticated piece of architecture or paradigm and it will fall flat in the face of the mass developer community. That is why HTML succeeded where more complex technologies failed.

WSDL and SOAP are overly complex. I personally prefer XML over HTTP for integration. Works 99.999% of the time. Its easier to publish and digest and is human readable. WSDL and SOAP add a ton of noise with little perceived benefit.

In the beginning of "web services technology", researchers were thinking more in terms of the "internet model" where all invocations are occuring in an internet context. The notion of supporting LAN integration frameworks which is a significant concern for SOA was really not part of the charter. IMHO, the result has been some excess complexity in the specifications when one is using them in the local context. The answer to me would seem to be an abstraction of the specifications that could offer a simplified version in the local case while still offering a specialized detailed support for the internet model.

I personally prefer XML over HTTP for integration. Works 99.999% of the time. Its easier to publish and digest and is human readable. WSDL and SOAP add a ton of noise with little perceived benefit.

WSDL provides value in that it allows software tools to generate much richer code. It's really simple to access webservices with middle-ware tools.

My understanding is that too many companies had their own ideas for how the WSDL should look and had already developed their tools before the spec was created and wouldn't budge. So we eneded up with redundancy. Several sections have the same info as others represented in different ways. This makes the document not only painful for people to use, it can cause integration issues (we are dealing with this now) between vendors that prefer different portions of the document.

I personally prefer XML over HTTP for integration. Works 99.999% of the time. Its easier to publish and digest and is human readable. WSDL and SOAP add a ton of noise with little perceived benefit.

XML over HTTP might work for very *simple* interactions. The minute you try to establish a robust protocol MEP (message excahnge protocol) - errors, metho dispatching - you end up recreating your own customized mini-SOAP. Non-standard. I've seen a ton of home-grown XML/HTTP where the designers were clueless as to basic protocol design. The result was a mess. Sometimes no schemas to define the messages. How do you specify methods? Errors - HTTP response codes, XML messages? Server dispatching? Etc.

Yes, I do agree, SOAP and especially WS* are bloated. But the original intent of SOAP is inherently correct. What we need is a standard easier-to-use "slim-SOAP". We shouldn't throw out the baby with the bathwater.

Yes, I do agree, SOAP and especially WS* are bloated. But the original intent of SOAP is inherently correct. What we need is a standard easier-to-use "slim-SOAP". We shouldn't throw out the baby with the bathwater.

Exactly. Just because the implementation is flawed doesn't mean the idea is bad.

But the original intent of SOAP is inherently correct.

Hmm, I am not that sure. I tend to think about SOAP as a phenomena based on lack of understanding of the domain, desire to distinguish from “academics”, and youngsters attitude towards “old stupid fathers”.

Hmm, I am not that sure. I tend to think about SOAP as a phenomena based on lack of understanding of the domain, desire to distinguish from “academics”, and youngsters attitude towards “old stupid fathers”.

Agreed.

BTW this also applies to the reinvention of multi-tier applications (see the recent AJAX threads), the "db-driven approach" (RoR), the negation of OO concepts, and other bullshit...

Pretty crazy to see all this nonsense around.

Have fun,

Remi

But the original intent of SOAP is inherently correct.

What was the original intent of SOAP anyway? Better yet, what was it that distinguished SOAP from all the previous technologies?

To make distributed computing easier? That was the intent of every dist. comp. technology so far.

To be XML based? OK, but we've yet to see advantages of that. Anyone who has advanced past tutorials has discovered that SOAP messages are as complex and human-unreadable as those created for "binary" protocols. Evidence nr. 1: SAP's messages. Evidence nr. 2: HL7 3.0. And XML makes them resource hogs to boot.

It seems the only advantages of SOAP are that it can bypass firewalls with ease (thanks to SOAP/HTTP binding) and that it is suppored by all 500 pound gorillas of IT.

It seems the only advantages of SOAP are that it can bypass firewalls with ease (thanks to SOAP/HTTP binding) and that it is suppored by all 500 pound gorillas of IT.

Ahgrrr !!! The Dreaded Firewall issue!!!

I never ever heard of any reasons why allowing all kind of stuff to piggyback HTTP and pass over port 80 is good.
All the sane developers should fiercely fight that nonsense of firewall transparency because we go port 80.
C’mon, folks at infrastructure should do their job. Insisting on having port 80 as gate for everything lessens security and forces developers to use less efficient and less robust solutions that transforms directly into company’s monetary losses caused by:
- inefficiency of infrastructure;
- increased vulnerability to attacks;
- cost of hardware upgrades to support inefficient infrastructure;
- cost of rewriting software to accommodate “latest and greatest” XML mutation;
- cost of software and trainings which help taming XMLkenstain;

But the original intent of SOAP is inherently correct.

What was the original intent of SOAP anyway? Better yet, what was it that distinguished SOAP from all the previous technologies?

The original genius of SOAP (and XMLRPC) is that text processing scripts can join an RPC federation. There are SOAP drivers for Perl, Python, JavaScript, etc. CORBA doesn't reach scripting languages.

Perl bindings
http://people.redhat.com/otaylor/corba/
Python bindings
Fnorb, OmniOrb
http://omniorb.sourceforge.net/
http://www.fnorb.org/

JavaScript - maybe certain things should not have everything?

CORBA doesn't reach scripting languages.

CORBA supports DI (dynamic invocation ) therefore it is scriptable.

Check the facts :)

CORBA doesn't reach scripting languages.

Yes of course...

FYI it's in the spec too (I doubt you will read it but this could prevent you from saying such a bullshit again).

CORBA supports DI (dynamic invocation ) therefore it is scriptable.Check the facts :)

Aaaaah this remembers my good old CorbaScript (from the guy who now leads OpenCCM@objectweb) : the reference OMG IDLScript implementation that uses DII ! You can manipulate any CORBA object so easily with that (you can even write servants in the scripting language itself).
I remember we even had a web server with a CGI gateway and embedded CorbaScript processor (CorbaScripts in HTML pages ala JSP) :-)

Brian, in Y2K I was already scripting remote *objects*. It looked like :

// get the naming
nc = CORBA.ORB.resolve_initial_references("NameService")
// get the object
myObj = nc.resolve(nc.to_name("MyKey"));
// invoke
res = myObj.op();

Isn't that cool ?

If you were using JIDLScript (the Java version from a guy in the same lab), you could even do stuff like :

// get the naming
nc = CORBA.ORB.resolve_initial_references("NameService")
// get the object
myObj = nc.resolve(nc.to_name("MyKey"));
// show it in a JPanel (uses java objects)
myPanel = new com.mycompany.ui.MyJPanel();
myPanel.setObject(myObj);
frame = new javax.swing.JFrame();
frame.setContentPane(myPanel);
frame.pack();
frame.setVisible(true);

As you can see, once again, nothing new in the SOAP/XML/Scripting languages wave...

Have fun,

Remi

CORBA-Python: http://omniorb.sourceforge.net/
CORBA-Tcl/Tk: http://pythontech.co.uk/torb/
CORBA-Perl: http://www1.lunatech.com/cope/

Google for others at your leisure!

The originators of SOAP had as a design goal that a good developer would be able to knock together a functional SOAP stack in a weekend. Scripting was not specifically mentioned, since as Microsoft weren't very long on scripting at the time, but of course it was a straightforward thing to put a SOAP stack together using dynamic languages.

The tech community just does't get it. Complex, esoteric technology will NEVER get widespread adoption.

Would you be able to develop the Operating System you're using (even Windows :-) ) ?
Would you be able to develop the transaction part of a RDBMS ?
Would you be able to write a JVM ?
...

You develop a really sophisticated piece of architecture or paradigm and it will fall flat in the face of the mass developer community.

Well IMHO things are just getting more and more sophisticated. We used to count bytes once, now we have objects and layers etc. GOTO time is over in case you did not notice ! Once again you must be using very complicated things everyday without even noticing it. Some people obviously agreed on it, it's just that you did not get it (I put myself in that bag too : I don't understand everything either !).

That is why HTML succeeded where more complex technologies failed.

I think you mix everything : HTML is not a technology. It's not really about computer science, it's a presentation language !
What you say is more or less equivalent to "Java sucks cause it's more complicated than HTML" !

WSDL and SOAP are overly complex. I personally prefer XML over HTTP for integration. Works 99.999% of the time. Its easier to publish and digest and is human readable. WSDL and SOAP add a ton of noise with little perceived benefit.

I think you don't have any clue about what "integration" means, and the comments you make precisely fall in the category that was pointed out by the article's author !

Integration is often a complicated problem that can't be solved using simplistic solutions. Simplistic XML-RPC/REST/SOAP/WSDL/blahblah made the illusion that web developers could handle integration issues and develop distributed applications in two clicks whereas specialized people struggle with this since decades (but they must be silly : how could they miss HTML ???).

You know, some people who don't even understand all OO semantics can get a WS up and running very quick and feel he now knows everything about remoting. Guess the quality of the "application" at the end of the day...

Have fun,

Remi

WSDL and SOAP add a ton of noise with little perceived benefit.

Let's say organization A has a web service that I want to use. I know the host name and port number of the service, but not the structure of the XML that it accepts.

If this organization provides a WSDL endpoint, I can point a tool like Castor XML at it and generate Java code that is serializable to/from the XML that the web service expects.

If this organization provides a WSDL endpoint, I can point a tool like Castor XML at it and generate Java code that is serializable to/from the XML that the web service expects.

Ever heard of CORBA’s Interface Repository? – It supplies IDL definition for services and IDL compiler gladly creates bindings for any Java, C, C++, and virtually all other languages.

Ever heard of CORBA’s Interface Repository? – It supplies IDL definition for services and IDL compiler gladly creates bindings for any Java, C, C++, and virtually all other languages.

Even CLR... I've even lastly been (at least partly) reconciled with M$ when I had to deal with some .NET stuff (a service in the 'SOA-like' architecture was implemented as a set of .NET classes).
Full Java (JacORB) <-> IIOP.net (C#) interop, with pretty tough stuff in the game (dynamic gen of CORBA proxies, OBVs, ClassLoading etc), at first attempt. I was not used to such things with m$ !

BTW, and this is more in the thread's scope, the service implementor did not want to deal with IDL at first sight and went on "reversing" his C# code to IDL (a la JavaIDL for EJBs or Java2WSDL for WSs)... it resulted in an ugly set of .idl files for almost nothing (the server actually looks like your RiaServer lol) !
Well, the guy there was smart and it took him less than 1 day and a few hints to understand the basics of IDL, re-write his server in a single clean file, compile, extend the servant class and get the server running ! Of course, he agreed to say that this 'CORBA thing', as he called it was quite impressive. :-)

Have fun,

Remi

Let's say organization A has a web service that I want to use. I know the host name and port number of the service, but not the structure of the XML that it accepts. If this organization provides a WSDL endpoint, I can point a tool like Castor XML at it and generate Java code that is serializable to/from the XML that the web service expects.

Right, but likewise if they had a public CORBA service and published the IDL you could generate code from that. I see no major difference there.

The big thing with web services is the vendor support. Microsoft never joined the CORBA camp and in my opinion that made all the difference. You need all the giants to be on the same side.

Actually WSDL is pretty straightforward to write and generate. Its just a big PITA to do. The real problem is XML Schema. When you write POJOs you can't capture the, let us say, "richness" of XML schema. So you should nearly always write your schema first***.

Which is why I advocate Schema First (as opposed to WSDL first). <plug>XFire allows you to do this with XMLBeans and JAXB. You just generate your classes from the schema, write your service interface, and then XFire generates the WSDL. Although JAXB docs need to be written up yet (they will be before our next release).</plug>

*** I advocate code first when you're doing a quick prototype. In that case, why would you spend the time thinking about a schema?

When you write POJOs you can't capture the, let us say, "richness" of XML schema.

Indeed, XML Schema declarations are more expressive than either Java or IDL declarations. And XML formalizes data validation, which neither Java nor CORBA does. XML Schema is a natural winner for describing communicated data.

Indeed, XML Schema declarations are more expressive than either Java or IDL declarations. And XML formalizes data validation, which neither Java nor CORBA does. XML Schema is a natural winner for describing communicated data.

Validation definitely sounds cool. But the real question is: how much is actually _useful_ ?

With IDL (or POJO) we surely do not need to check if a supposedly numeric field has letters or uses comma instead of dot, or how it is formatted because we cannot assign letters to a double.

Maybe I can use schema and check if amount of the requested withdrawal is less than allowed limit? – Oops, no, it belongs to the realm of business logic validation. Oh! Perhaps I can check if the amount is negative! This way I will successfully scatter validation across multiple places and incur inconsistency in error messaging, plus get headache with i18n support. Hmm

Can I check if the ref-id in this field is the same as ID in the previous message? –Nope, cannot do that with schema.

Well, since I have to write significant portion of validation in my business level I tend to have all the validation in one place.

Validation definitely sounds cool. But the real question is: how much is actually _useful_ ?

If Amazon.com's Denver b2b endpoint can only accept purchase reuests that are to be shipped to Colorado, Utah, or Wyoming, then XML Schema can enumerate the 50 states' postal acronyms and then specify a restricted subset. CORBA and RMI can't declare restriction or regular expressions in the interface, and they lamely leave such concerns to error-prone business logic, which thwarts design-by-contract. This means validated XML integration can be debugged with less labor than with CORBA or RMI. If Amazon's Denver b2b endpoint used RMI, a purchase that illegally requested shipping out of the region would have its mysterious rejection accompanied by a cryptic IllegalArgumentException or something. But an XML Schema validation error would include line and value precise diagnostics. Ie, XML integration is quicker to sanitize, and therefore a labor saver.

If Amazon.com's Denver b2b endpoint can only accept purchase reuests that are to be shipped to Colorado, Utah, or Wyoming, then XML Schema can enumerate the 50 states' postal acronyms and then specify a restricted subset. CORBA and RMI can't declare restriction or regular expressions in the interface, and they lamely leave such concerns to error-prone business logic, which thwarts design-by-contract. This means validated XML integration can be debugged with less labor than with CORBA or RMI. If Amazon's Denver b2b endpoint used RMI, a purchase that illegally requested shipping out of the region would have its mysterious rejection accompanied by a cryptic IllegalArgumentException or something. But an XML Schema validation error would include line and value precise diagnostics. Ie, XML integration is quicker to sanitize, and therefore a labor saver.

The post does not have any valid statement.

Brian, you are joking, right?

XML Schema is a natural winner for describing communicated data.

And a definite loser for writing useable service specifications. I am encountering the exact problems that Konstantin Ignatyev described in the previous posts with data validation placed in the XSD files. It is not enough to express _all_ the business logic, so you still have to code some validations in the server: either you split validation logic, or you do it all serverside. Furthermore, since you cannot deactivate part of schema checking, if some of the POJOs we are using have null fields (usual in real applications, when some use cases just do not need that particular piece of info) a validation check is triggered by JAXB marshalling/unmarshalling of empty strings. The time we wasted upon solving these sort of problems is enought to have the entire dev team attend two CORBA courses and learn more "civilized" ways to describe services. But the management wanted a "web-service" architecture, so...

Perhaps the traditional idea of a single hub being your middleware is inappropriate for an SOA, but there will always be intermediaries to do transformation and routing. Intermediaries ARE middleware!

Even with TCP/IP, we have "gateways" that route LAN traffic. The open question is whether with an SOA this will be better served by software or hardware based gateways ... I think in the short run, the software based ones will probably be dominant, if anything because this area is ripe for quick turnaround time.

As for his notes that language tools that generate WSDL, it really depends on the tool. Some are very good at creating platform independent and easily interoperable schemas and WSDL, some are piss-poor at it.

Finally, lots of people enjoy saying that complex technologies like SOAP and WSDL never catch on, I can point to a number of counter-arguments. "Complex" is in the eye of the beholder. Is UNIX/Linux complex? To some people yes, to others no. In the server world it is popular, but to the desktop world it is pretty complex. Does this mean it's doomed?

How about Microsoft COM / ActiveX? Tonnes of software was built on this layer. Let's just enumerate the surface of complexity here: automation vs. late binding, IDL vs. type libraries, custom marshalling, apartment threading, etc. Sure, it didn't take over the world, but it certainly took over the Microsoft world (which isn't small)!

A more universal example might be SQL and the RDBMS. Despite all the trends and hype in the Java community about ORMs and people hiding their SQL, the majority of applications in PHP, .NET, Perl, Python, or even good old COBOL or C++ are still programmed with heavy reliance on SQL and stored procedures. Lots of people still aren't able to think in terms of sets, and DBA's are still payed a lot of money to make this stuff perform because programmers can't be bothered to understand the database. This situation isn't changing any time soon.

SOAP and WS-* are not complex by any historical measure. They're composable -- you use what you need, and don't use what you don't need. WSDL is a bit of a disappointment but is MUCH simpler than the popular IDL's that came before it. XML Schema is probably the biggest disappointment in terms of unnecessary complexity, but it looks like we're stuck with it due to the lack of interest in alternatives like RelaxNG.

SOAP and WS-* are not complex by any historical measure.

Perhaps the XMLkenstein is not _that_ complex in the absolute terms. The problem as I see it: those XMLized technologies are complex and inefficient without good cause. There are technologies, which address the complexities of the domain better and simpler, and still perceived as “complex” (CORBA). And yet, we have to deal with unnecessary complex, inefficient, and incomplete XMLkenstein.

If SOAP was the first technology around I could be more forgiving, but see such a degradation of past ideas and achievements – that is the pain.

There are technologies, which address the complexities of the domain better and simpler, and still perceived as complex (CORBA).

If text markup over HTTP is so horribly complex and not innovative, then why didn't industry choose CORBA to serve web pages?

There are technologies, which address the complexities of the domain better and simpler, and still perceived as complex (CORBA).

If text markup over HTTP is so horribly complex and not innovative, then why didn't industry choose CORBA to serve web pages?

No smiley present, so must assume it's a straight question...

Because IIOP wasn't standardized until 1995 or so and the web was already established at that point and running quite well on HTTP 1.0. Prior to that, CORBA-compliant ORBs couldn't interoperate at the wire level. Also, while the CORBA standard was published, the implementations were all proprietary, so having it as the basis of the web wouldn't really have worked out.

 --oh

There are technologies, which address the complexities of the domain better and simpler, and still perceived as complex (CORBA).

If text markup over HTTP is so horribly complex and not innovative, then why didn't industry choose CORBA to serve web pages?

Because Microsoft refused categorically to adhere to this standard (it had its own standard in DCOM), thus preventing any real interoperability unless you used bridging technologies (adapters). OTOH the Seattle crew were immediately enthusiastic about SOAP and the entire WS stuff, so other vendors steered their wheels towards WSDL/SOAP/whatsoever, hoping to stop the endless battle. There are other reasons, but this is the main one.

Not to mention that in Sun's original view, a CORBA ORB had to be the underlying middleware for EJBs, so there were attempts to standardize upon a CORBA implementation hidden under the EJB hood. Sadly, EJBs were perceived as too complex, too.

At present, we are all waiting for MS to produce a non-interoperable implementation of WSDL or SOAP or WS-*, as it always did with all other standards. Then we'll have to find another "innovative" technology to believe in.

Hope this happens soon enough, or I owe a beer to Remi...

Brian, you are still missing the point.

"Serving web pages" must be amongst the simplest client/server model in the history.

We're not talking about "exchanging documents" but about "providing services to remote programs" and ultimately "build distributed systems".

BTW, do you need any WSDL for serving web pages ? No.

Your comparison does not stand, try to find something else :-P

Have fun,

Remi