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:
>  
> >>>What is Web Services if not the next attempt at a homogeneous
> >>>middleware layer???
> >>
> >>It is a lot "less homogenous" than CORBA.
> > 
> > How so? It's just *another* middleware standard. 
> 
> In having fewer pages in the specs. :-) (WSDL and SOAP). In earnest,
> I was referring to the semantically less strictly defined concept
> of service, which can be almost anything and is thus more generally
> applicable.
> 
> > CORBA and Web Services
> > both boil down to constructing/deconstructing messages (IIOP/SOAP) and
> > sending them out on the wire. 
> 
> CORBA requires more than just sending/receiving messages, the general
> behavior of both clients and servers in an interaction is strictly
> defined, and there are plenty additional little protocols (think of
> code sets, etc.), plus lifecycle issues plus plus... Implementing an
> ORB requires a larger investment than implementing a SOAP library.

I don't implement the ORB, I buy it. :-) Seriously, I don't really
care how difficult the underlying spec is to implement, provided that
someone gets a kick out of doing it. Obviously, there are numerous
orbs available, so it's not impossible. :-)

> 
> > CORBA and Web Services are available on a
> > multitude of platforms. Can you provide an example of a platform that
> > supports Web Services that does not have at least one ORB available for it?
> 
> I was not saying that there weren't enough ORBs around, although
> perhaps there aren't that many free embedded Java ORBs that I can
> run in my cell phone. I am saying you sometimes don't need one,
> or can't use it because you won't find a partner on the other side.

I still believe that if the IT industry had stuck to CORBA/IIOP, we
would see plenty of lightweight orbs around. Netscape embedded an orb
in the browser in 1996, as they saw the future of distributed objects
(services) that stretched beyond static web pages. Web Services are
another flavor of that vision.

> 
> >>Sure, that's the history, but this is ignoring the actual technical
> >>differences between CORBA and the SOA/Web Services which account
> >>for the different sweet spots. But first let me spell it out again:
> >>neither CORBA nor SOA/Web Services are "better" per se, they have their
> >>strong points in different usage areas. You seem to be implying that
> >>CORBA would have been the universal silver bullet for all your distributed
> >>scenarios, which it just not the case.
> > 
> > I am not implying it, I am stated it quite loudly and clearly.
> 
> You may state that, but it is not true. Are all these other protocols
> (PVM/MPI, ftp, http, MQ) just there because people were too dumb
> to grasp CORBA? Again, I recommend the "dark middleware" article,
> I find it quite enlightenting.
> 
> Finally, I am not saying that Web Services are generally better
> than CORBA.
> 
> > Had Microsoft embraced CORBA the way they are embracing Web Services,
> > there would be no Web Services as we know it today. 
> 
> Who knows.
> 
> > In addition, Sun
> > probably wouldn't have gone off and developed RMI, but would have had to
> > make CORBA the backbone for J2EE, as interoperability with MS desktops
> > would have (and still is) a major issue.
> 
> CORBA is the backbone for J2EE anyway, RMI/IIOP is the interop protocol
> and CSIv2 is the secure interop protocol.

Unfortunately, IIOP was an afterthought. By the time IIOP was added to
RMI, it was too late. The Java is everywhere vision had already taken
hold.

> 
> > I'm not saying that CORBA is perfect, but the "features" that make
> > Web Services so appealing could have easily been added to CORBA. If the
> > energy spent by companies such as IBM, Microsoft, Iona, Borland, Sun, etc. 
> > would have been directed at improving CORBA, e.g. firewall support, lack
> > of development tools, support for documents/XML, it would be a different
> > ballgame. Of course, I say "if", since it didn't happen.
> 
> Yes, it could have been done.
> 
> >>The two models differ in important aspects. CORBA's, with the notion
> >>of objects in the OO sense, is much richer;
> > 
> > Yes, but as I've pointed out numerous times, it's trivial to make a
> > single "Service" object that basically mimics a Web Service.
> 
> No doubt about that, I have never claimed you could not do that,
> and the OMG is certainly happy to subscribe to SOA with CORBA, too.
> However, without a simplified, XML-based transport that does not
> buy you any of the looser coupling and thus flexibility you don't
> gain much here in terms of complexity reduction.
> 
> >  While the
> > ability to make lots of little distributed objects exists in CORBA, one
> > doesn't have to use, and probably shouldn't use, this capability.
> > 
> >   interface StockService {
> >      LastSalePrice getLastSale(in StockSymbol stock);
> >   };
> > 
> > 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?

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. ;-)

> 
> >>it entails many assumptions for the interaction
> >>between clients and servers. It also means that you need to have a
> >>complete ORB marshallin engine for even simple things,
> > 
> > A complete marshalling engine??? You mean an ORB? There are dozens of
> > good orbs available, many of them free, e.g. JacORB :-) 
> 
> 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. :-)

> 
> > 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. :-)

> 
> > Shall we list the available CORBA orbs vs. the available XML parsers? I
> > would imagine that the lists aren't that different in size. Besides, if
> > IIOP had been the focus over the last few years, there would be plenty
> > of marshalling engines around.
> 
> 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.

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.

> 
> >>CORBA also spends a lot of space on specifying APIs for portability
> >>purposes (e.g. POA, PIs), which is completely out of scope for SOA/Web
> >>Services.
> > 
> > Yes, until one too many businesses get bit in the ass by having code that's
> > tied to a proprietary Web Services framework. Do you believe the POA was
> > developed because the OMG was bored? No, it was developed because it was
> > *needed*. I spent *way* too much time porting code from one orb vendor to
> > another, as did many others.
> 
> 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.

> 
> >>You can use portable APIs (e.g. JAX-RPC) but you don't
> >>have to.
> > 
> > And you don't have to use POA. Selecting a portable API makes sense.
> 
> Well, with JacORB you have to. There's no other OA. And the
> other portability APIs in CORBA (ETF, PI) also make you go
> through extra loops.
> 
> >>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.

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. :-)

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.

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?

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");
        }
    }
}
 

> 
> >>To cut this long story short: in B2B it is a lot easier to
> >>retrofit a thin Web Services layer onto applications to connect
> >>existing stuff than to agree on CORBA and on IDL interfaces
> >>and then wrap things.
> >  
> > Please provide some evidence that this assertion is true. I don't buy
> > it.
> 
> Hm, I don't see any existing technology other than Web Services that
> can connect existing applications that are distributed internally and
> are using a mix of CORBA, MQSeries, RMI, .NET, SMTP, and HTTP
> internally.

Are all those applications passing around SOAP/XML messages today? No?
Well, then you're going to have modify every one of them, regardless
of the transport. Are there XML parsers available on all the
platforms?

If not, then you're going to have to write an adapter that understand
all the messages, and converts them to X before you can send it to
your business partners.

> But I guess you will say I should be using CORBA, right?

Yup. :-)

> Too bad my C#-ORB is just not up to it yet...

That's OK, you can use Java. I know a nice Java ORB that's probably up
to the task. :-) Since it runs on just about everything, including MS
platforms, it should do the trick.

> 
> > 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.

> 
> > Any company using a J2EE application server
> > these days have the basic CORBA and Web Services facilities available in
> > the app server.
> 
> Exactly.
> 
> > This brings up an interesting point. On the one hand you talk about the
> > ease of integrating Web Services into languages such as Perl. On the
> > other hand, you state that Web Services are best utilized for business to
> > business communication. Aren't the businesses that are most likely to need
> > B2B going to be utilizing a full-blown application server framework?
> 
> Not necessarily, as many companies have large investments in
> existing non-CORBA and non-J2EE software.

Yes, software that probably doesn't speak SOAP/XML today. There's
still plenty of work to do.

> 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. :-) Seriously, I
guess I just haven't seen a good set of document-centric examples to
convince me. Everything I've seen up to date has been RPC-style use of
SOAP/XML.

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.

> 
> Cheers, Gerald.

A pleasure once again.

Mark