Gerald Brose said:
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 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.
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.
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.
Who knows.
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.
Yes, it could have been done.
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.
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. ;-)
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.
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.
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.
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.
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.
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");
}
}
}
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.
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.
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.
A pleasure once again.
Mark
