Mark Woyna wrote:

> Gerald Brose <gerald.brose@x...> wrote in message news:<2i8uopFk86tpU1@u...>...
> 
>>Mark Woyna wrote:
>>
>>>Gerald Brose <gerald.brose@x...> wrote:
>>>
>>>>Mark Woyna wrote:
>>>>
>>>>>Gerald Brose <gerald.brose@x...> wrote:

<snip/>

>>>I noticed that nobody commented how readable my CORBA "Service" was
>>>compared to the equivalent WSDL. I've had students implement basic
>>>CORBA applications with practically no knowledge of CORBA.
>>
>>It is more readable, but WSDL is not anything that I would want
>>to write manually anyway, so there is no point here. WSDL is generated.
> 
> Arg. Isn't that one of the primary selling points of Web Services,
> that they are easier to develop? If you need a tool to generate WSDL,
> why couldn't you use a tool to generate IDL?

Sure you can, but that does not mean that Web Services are not
easy to develop.

> By the way, I bet you a beer that you couldn't write a valid WSDL file
> from scratch for a less than trivial service without referencing a
> textbook. ;-)

I guess I'd be paying for that beer :-) but we also generate our
object code these days, so why not WSDL? BTW, people also use
compilers to arrive at legal IDL, and getting that value type
syntax right takes for a non-trivial CORBA app also takes some
experience.

>>At least you don't think I have never loved CORBA in its youth (or
>>mine...) :-)
> 
> Yes, you loved it enough to write a good book about it. :-)

Thanks. (If more people were loving CORBA, there would be a market
for a new edition by now).

>>>How on earth is this any different from needing an XML Parser?
>>
>>It means that you can get a text message from just about anywhere and
>>parse it through your favorite parser API, which is simpler than
>>doing the same thing with a GIOP message that did not arrive over
>>IIOP. It also means that it is simple to build a DOM tree in
>>memory to represent a SOAP message and then serialize that to anywhere,
>>or use a pre-made template message and just fill in parameters in
>>a script etc.
> 
> 
> Sounds like a lot of busy work to simply get the data out of a
> message. I'd rather have a stub class perform the work, created by
> someone who likes that sort of thing. Me, I've got applications I have
> to write. :-)

Perhaps this is actually the point of our argument here: I am not
thinking of writing new applications, and if I were writing one,
I guess I would not be using Web Services as the middleware unless
for some very specific XML requirements. I am mainly thinking of
EAI/B2B where all your apps are there already, and its a matter of
how your model your data (IDL or XML) and how easy it is to get
from existing interfaces (perhaps file-based) to message exchanges.

>>There's a basic dilemma with IIOP that has been pointed out numerous
>>times in the past, viz. that you cannot correctly demarshal a message
>>without complete type information about the parameters. With XML
>>you can get just the parts that you are interested in (and know how
>>to process). This makes XML more suitable foor multi-part document
>>exchanges than IDL.
> 
> This could have been added as either a) an additional protocol, or b)
> adding a new datatype that supports semi-structured data. Actually,
> the structured event part of the Notification Service spec sounds like
> a close match.

True.

> My experience is that you don't get very far in extended message
> formats until you hit some mandatory field that *every* client has to
> understand and process. There just aren't that many optional fields in
> B2B interactions. It doesn't matter if I was using a relational
> database, CORBA, or XML.
> 
> Would I like the flexibility of adding a new field to a CORBA struct
> without breaking my users? Sure. However, the minute I need that data
> from them is the minute they all have to know the field.

There's a subtle difference here: if you have different participants in
a multi-domain interaction that all share a document (say, in an
order-processing workflow), then they all care about different parts
of the document. Why should I have to rebuild all the software when
the changes concern only two of those guys?

>>When you wrap a legacy COBOL (or whatever) application, how many
>>times are you going to port the wrapper? Portability is great,
>>but sometimes not a crucial issue.
> 
> It's a nice insurance policy.

Granted. But we don't buy all those policies just because they
exost, do we ;-)?

>>>>Web Services as a middleware are more modular, if you like,
>>>>and it also suffices if the two parties that actually interact know
>>>>what it means. It's enough to pick those pieces off the standards
>>>>that are required for the task at hand.
>>>
>>>And this is no different that basic CORBA interoperability. You're
>>>not making a very compelling case.
>>
>>If I can't convince you by saying that sending and receiving
>>SOAP messages is per se simpler because the message format
>>is so simple then obviously more arguing is not going to help.
> 
> 
> What is simpler? I've posted several coding examples previously that
> show that the equivalent CORBA code is much smaller and easier to read
> than constructing and sending a SOAP message. Of course, if you use a
> stub-based SOAP framework, you've effectively done the same thing that
> every orb vendor provides.
> 
> In addition, we seem to agree that WSDL is practically unreadable next
> to the equivalent IDL.

It's a lot less readable, but with the XML mode in my emacs I can
make sense of it.

> Having implemented an orb, I assume you are referring to the ORB
> developer, in which case you're probably right. However, as a user of
> the technology, I want to be shielded from the underlying complexity.
> Isn't that one of the major reasons CORBA was invented? As long as
> there is someone willing to develop orbs, I'm buying. :-)

That is true, of course. However, for niche markets, you are not
likely to find an "free lunch" ORB, so the buying may be very
expensive. What I claim is that in many cases grabbing data from
a legacy app, taking a SOAP toolkit and sending that data is
both cheaper and easier for the average developer.

> Of course, if you hide all the nasty details of SOAP behind a tool,
> then you're not really commenting on the ease of using the platform,
> but rather the quality of the tool.

The nasty details are only syntax. (Let's assume that EJB is about
as far we can go to simplify CORBA by hiding POA programming behind
a few "bean type" patterns. Any "simpler" ways for the average
programmer, anyone?)  This is still pretty complex. How far can tools
go, theoretically?

> Here's the example code of using my simple CORBA-based StockService to
> get a stock quote. You do these same for a Web Services based
> implementation, including basic error handling and UDDI query. 
> Agreed?

No UDDI, as you are not using the Trader ;-).

> package com.argonne.stockServices;
> 
> import org.omg.CosNaming.*;
> import com.argonne.idl.stockServices.*;
> 
> public class StockClient {
>     public static void main(String[] args) {
>         try {
>             org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
> 
>             org.omg.CORBA.Object rootObj =
> orb.resolve_initial_references("NameService");
>             NamingContextExt root =
> NamingContextExtHelper.narrow(rootObj);
>             org.omg.CORBA.Object object =
>                                 
> root.resolve(root.to_name("MyStockService"));
>             StockService stockService = 
> StockServiceHelper.narrow(object);
>             float price = stockService.getLastSale("IBM");
>             System.out.println("IBM Last Sale: " + price);
>         }
>         catch (NotFoundException e) {
>             System.out.println("IBM Last Sale not found");
>         }
>         catch(Exception e) {
>             System.err.println("Oh no");
>         }
>     }
> }

This is not a very useful comparison as you are using a stub-based
RPC approach which I can do, too, and then the code is almost identical.
Anyway, here it is, using the JAX-RPC API (this code is stolen off
ttp://www.sys-con.com/webservices/articleprint.cfm?id=585). It has
just four statements because it does not do a name service lookup.

package stockquote;

import javax.xml.rpc.Stub;

public class StockQuoteClient
{
    public static void main(String[] args)
    {
        try
        {
            Stub stub =
                (Stub)(new MyStockQuoteService_Impl().getStockQuoteIFPort());
            stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
                              args[0]);
            StockQuoteIF stock = (StockQuoteIF)stub;
            System.out.println(stock.getQuote("IBM"));
        }
        catch (Exception ex)
        {
            System.err.println("Oh no");
        }
    }
}

Had you used the DII to make an asynchronous call, then you could
compare with this code:

http://www.xmethods.net/download/servicefiles/stockquoteClient.java

>>>To interoperate, companies *must* agree on an interface, including the
>>>data that is carried within the messages. Implementing the interface
>>>as a simple CORBA object, or a Web Service each require more or less
>>>the same amount of work. 
>>
>>Agreed for the interface. But the point is that you need to agree
>>on data models, too. XML is a more suitable tool for that if you
>>are exchanging anything that looks more like a document than
>>a value object.
> 
> What about all the data that *isn't* a document? Is inventory data a
> document? How about bank transactions? Market data from the financial
> industry? I guess with XML everything begins to look like a document.

Pretty much :-)

 >>If all you need is
>>document exchange, why not skip the app server integration and
>>use XML right away?
> 
> Yes, I guess we should simply send it via email. :-) 

Well, there is a place for e-mail as middleware, as there is for
many other apparently trivial connectors.  Would you sent customer
news letters out of your document management systems using CORBA :-)?

> You're certainly not the only one stressing the importance of loosely
> coupled, document-centric Web Services, but unfortunately there are
> more people in the WS industry today providing RPC-style
> examples/training/tools/etc. Current "popular" examples of Web
> Services usage, e.g. Amazon, Google, are certainly RPC-like.

True. BTW, there is a really good new book on Web Services, just
in case anybody is interested:
http://www.amazon.com/exec/obidos/tg/detail/-/3540009140/103-1224462-3391836?v=glance

>>Cheers, Gerald.
> 
> A pleasure once again.

Thanks for the enjoyable conversation,
Gerald.


-- 
Gerald Brose, PhD                       mailto:brose@x...
Xtradyne Technologies                     http://www.xtradyne.com
Schoenhauser Allee 6-7,                  Phone: +49-30-440 306-27
D-10119 Berlin, Germany                  Fax  : +49-30-440 306-78