IBM, BEA, and HP have taken issue with a dearth of Common Object Request Broker Architecture (CORBA) support in the latest Java release, according to people involved with the process.

BEA's beef with CORBA support in 1.5 stems, not from a lack of support for the specification, but from its age. BEA officials said most of their customers don't use the CORBA support because it's outdated, and they want it updated from 2.3.1 to 2.6.

Read Big Vendors Lobby for CORBA With Their Java

This is great news. I hope that people will realize that CORBA is way much better than web services.

But telco world for example may you both approaches right now.
E.g. Parlay and Parlay X

Dmitry Namiot
http://www.servletsuite.com

Apples are better than bananas?

Unfortunately apples are far to often used as replacement for bananas, or even called bananas!

Sooo many efforts are spent because ignorant and XML blinded people did not even bother to look back and try to understand why CORBA did things in a certain way and why it seemed complex.

I agree, and it is a problem. A related problem is the "Salesguy architect" syndrome, where one is forced to use the latest buzzword technology because some sales person has been to some presentation. Maybe the fruit salad looks apetizing, but it might taste like crap.

<QUOTE>XML blinded people did not even bother to look back and try to understand why CORBA did things in a certain way and why it seemed complex</QUOTE>

They sure did. That's how web services appeared. Because finally somebody looked back to all these years of CORBA existence, and tried to realize why it never had even a fraction of HTML success.

Ha!
They tried to use CORBA, but not to understand.
CORBA has far superior architecture to anything else we have in the area.
There is one biggest cause for CORBA not to spread initially: first CORBA spec did not address underlying binary protocol (guess because vendor's pressure in the desire to lock in customers) that lead to incompatible implementations and require multiple ports to be open on firewall.

It has been addressed later, but it was too late…. "simple" solutions appeared.

Now it is time to realize that simple solution should not be simpler than necessary.

So WS were marketed as simple solution for communications between
enterprises. In terms of functionality it is indeed too simplistic
compared to CORBA. Which means WS will get more comlex in future,
as more features needed by enterprises are being added - so eventually
we'll have an ugly substitute for CORBA, with the all drawbacks that
weren't initially advertized.

There is no problem with the Web Services there is problem with communication protocol, if there is a way to send web services not over HTTP protocol then it would be fast as CORBA or RMI/IIOP and convenient as Web Services, ability to travel through the firewalls is not a feature but rather deficiency.

Stop listen to hype and open your eyes man!

Seriously, just take your time, relax and try to answer the question: Is this really simple?

<QUOTE>Seriously, just take your time, relax and try to answer the question: Is this really simple?</QUOTE>
I'm relaxed and seriously answering your question: Yes it is.
What's your problem with web services ? Can you describe it ?
What do you find complicated in web services ?
And if you do not like xml protocol, there's a binary web services implementations, for example Hessian for Caucho.

Well, binary protocols for Web Services are funny enough (somebody remember that big selling point about nice and human readable XML here) although CORBA has been binary from the beginning.

Please do not mix RPC with WS. WS are supposed to be about interoperability and standards so binary stuff like Hessian does not count (although it is a nice protocol). Although this is some corroboration to my point: there are better ways to do RPC than XML and SOAP.

My point is that amount of work to get RPC-type connection done with WS is the same as with CORBA (although I think WS way is more complicated).

To make long story short: WS stack just getting features which CORBA already has for many years and implementation is not simpler than CORBA ones. So what was the (real) need for WS at first place?

Konstantin, you are completely confusing me.
First you said "Please do not mix RPC with WS"
A good start, i thought. WS is not supposed to do RPC and in that sence any comparison to CORBA is useless. They just meant for different things.

Then you are adding: "there are better ways to do RPC than XML and SOAP."
:))) Of course there are better ways. Any way would be better to do RPC than WS simply because WS is not supposed to be used as RPC mechanism.

And afer your words "My point is that amount of work to get RPC-type connection done with WS" i realize that you were seriously thinking that WS is nothing but another attempt to implement RPC.

Let's say browser hits jsp page and gets some result back.
Do you call it RPC ? Obviously there was some remote procedure initiated :))

Actually it _is_ used as a way to do RPC in the majority of cases. WS has a rational part, which is document –oriented messaging style. But I would say that is realm of B2B document workflow solutions and asynchronous interactions. And it would be better off without SOAP and WS, which just shift attention from really important issues and spoil the broth.

Vagif,
  I'm afraid I side deeply with Konstantin with this. CORBA is 10 years ahead of WebServices, there were three principal problems with CORBA but they are far outweighed by the benefits when you compare it to "traditional" WebServices..

1. Originally it wasn't asynchronous, this restricted it's scalability
2. It was thought of as complex by the GUI brigade, the VB "programmers" of the world couldn't click on buttons and program it.
3. Microsoft never supported it.

> What's your problem with web services ? Can you describe it ?

My problem with WebServices is the hype, it's just another technology! People are trying to solve everything with WebServices. SOAP in the form of XML is not viable in most cases, high-performance for example, mobile technology etc. WSDL is "OK" but not a very significant part of WebServices and UDDI is just crap, totally useless.

> What do you find complicated in web services ?

WebServices are not complex, it's actually very simple. However if you had the problem in a pure Java world you'd never arrive at WebServices and if you had the problem in a pure .NET world you'd still not get there. To exchange a definition of service WSDL does the trick, it's OK, pretty much the same as Java reflection or IDL. To exchange data or documents though SOAP is somewhere between DCOM/RMI/CORBA and the postal service.

> And if you do not like xml protocol, there's a binary web services implementations, for example Hessian for Caucho.

I notice you mentioned binary services, this is a much better idea. If we're going to use binary let's use a good standard like IIOP or JRMP. Another option is ASN.1 but I think Microsoft should be kept away from that until they learn how to use it properly.

Sun's use for ASN.1 in "Fast WebServices"
Microsoft recent experience with ASN.1

Seriously though I can see MS, Sun, IBM and others moving towards binary WebServices, even the new SOAP spec suggests the use of binary objects. It appears we're coming full circle though. The only thing we're getting out of this is better use of the SOA or service bus.

A SOA with binary message exchange is starting to get somewhere, what's left is the ability to dynamically distribute services, something you're only going to get from VMs like Java and CLR. I doubt MicroSoft seriously expects to keep XML based SOAP, they've now got a VM, they've distracted the competition with XML so that they can surely work on something more efficient. Just an idea but I can't believe they're that stupid.

-John-

> I'm afraid I side deeply with Konstantin with this. CORBA is 10 years ahead of WebServices, there were three principal problems with CORBA but they are far outweighed by the benefits when you compare it to "traditional" WebServices..
>
> 1. Originally it wasn't asynchronous, this restricted it's scalability
> 2. It was thought of as complex by the GUI brigade, the VB "programmers" of the world couldn't click on buttons and program it.
> 3. Microsoft never supported it.

I think you need a different perspective:
http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-01-31T05:16:25Z
I am mentioning this link only to let you know why post-OBV CORBA was instrumental in leading to this webservice hype.

>
> WSDL is "OK" but not a very significant part of WebServices

Exactly what is this supposed to mean? Let me extrapolate -- IDL is "OK" but not a very significant part of COM. does that make sense?

> I notice you mentioned binary services, this is a much better idea. If we're
> going to use binary let's use a good standard like IIOP or JRMP. Another
> option is ASN.1 but I think Microsoft should be kept away from that until they
> learn how to use it properly.

Binary services? ASN.1? Are you sure? I am no expert here but there is some valid disagreements in this area. Specifically:
http://www.gotdotnet.com/team/dbox/default.aspx?key=2003-09-10T08:10:14Z
http://www.gazitt.com/ohmblog/PermaLink.aspx/13178f4f-b851-4568-972b-2886048490a2

--Dilip

Don's box you linked to is good but he's making the assumption that everything needs the same solutions, a la Microsoft. The only place where DCOM, RMI and CORBA fall down is across the internet, in fact they were never designed to work outside of an intranet and that's why people got into problems with them as we moved into the .COM hype.

XML-RPC is a good way to connect two machines that don't really have much to say to each other, something perhaps delivered by a brokerage service, UDDI for example. If two (or more) bodies have to exchange large amounts of information on a regular basis then XML-anything is not the thing to use. There is no way <amount currency="GBP">15000000</amount> is going to be as efficient as a single byte for the currency (or whatever) followed by either an IEEE double or some previously agreed number format in binary. At worst even "GBP15000000," as used by SWIFT is slightly more efficient.

I think WebServices as in WSDL/SOAP/UDDI is useful for casual interaction of services, internet browsing, finding an insurance quote, looking for the cheapest flight etc. it's perfect for that, no one cares of the message gets lost, no one cares if it takes 15 seconds to do the round trip and no one cares of the odd rogue service appears on the UDDI broker.

When I was WSDL is not a significant part of WebServices I meant that it doesn't have a huge impact on the overall speed of the service. As things go WSDL is "OK" as a language for defining services.

As for ASN.1 I'm not sure if Sun are actually taking that forward, the article was just an opinion. I agree with the posting you linked to in that it's not the best choice IMOHO but the point is that a binary replacement of XML in SOAP is on the books for most people.

-John-

Dilip:

Don says:

"The fact that we're building major pieces of Longhorn using an object-centric runtime indicates that at least one vendor believes that objects are ready for primetime and have value for new projects as well as old ones."

I guess the above statement completly invalidates his opinion about the CORBA thing since it is obviously biased.

Have you used CORBA?

One simple point is being missed out. These are not necessarily conflicting or competing technologies. From a pure middleware context (excluding all the extensive servceis that CORBA spec provides for), these are just invocation protocols. Say, in the J2EE context, an EJB can be accessed via one of these ways:
- RMI/JRMP from a Java client
- RMI/IIOP from a CORBA client (or java client)
  (the EJB in essence becomes a CORBA service endpoint!)
- as a WS (with a WS runtime- say JAX/RPC) from a WS client

Each have their strengths and weaknesses. Ideal would have been an anywhere-to-anywhere accessibility with a single protocol. WS (SOAP) surely scores on this count- Simple text (XML) based wire representation protocol, with support from leading platform vendors (including MS!). Ensures interoperability!

But then not fully evolved to offer the range of security, transaction and other abilities provided by say EJBs via RMI. Once all such capabilities are provided by SOAP, surely RMI/SOAP is an option even for localised (intranet based) application accesses from non-browser clients. But then, localised application access is not the target for WS. WS is essentially targetting access from disparate platforms. For localised access, the native connectivity (RMI) will continue to serve better!

Cheers,
Ramesh

You might be interested to look up some links from the joint work of IBM and Microsoft

Coordinating Web Services Activities with WS-AtomicTransaction and WS-BusinessActivity
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsacoord.asp

Secure, Reliable, Transacted Web Services: Architecture and Composition
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsOverView.asp

It describes an interesting scenario to orders car parts where the car company no longer makes the parts but order from a vendor,
 
the Auto company doesn't have to maintain a list of all authorized dealership employees and their passwords, it queries the dealership Web-Service..

The supplier enter an order to his own company on the car company's behalf..

WS-AtomicTransaction is used to ensure transactional behavior between the two supplying warehouses..

Regards
Rolf Tollerud

"What do you find complicated in web services ?"

SOAP stands for Simple Object Access Protocol, but it's neither simple enough for simpler tasks nor sophisticated enough for more complex needs. For simple task xml-rpc is probably easier, and I can't think of even simpler text-based solutions too. For more complex tasks, dealing with complex data types, it's not complex enough. But I'm wondering with all these WS-bla standards appearing each day where we're going!

Ara.

I totally agree with you John.

I have ripped "web services" out of systems because the performance is unacceptable and replaced them with CORBA. Sending XML messages between systems that are "far apart" - i.e where you send a single message and expect a response - is fine but for anything chatty SOAP just does not cut it. People often repeat the "loosely coupled" mantra but few people actual code web services in any kind of loosely coupled way.

CORBA has a reputation for being "hard work" which is not entirely unfair when using C++. However, I am currently using Borland Janeva (CORBA for .NET) to enable a Windows client to talk to a WebLogic back-end. It is extremely easy to use (you can even give it your EAR file and it will generate all the glue!) and the performance is excellent. Borland added some features for me to make COM interop easier which means we can even call the EJBs from Word 2000 using VBA.

I hadn't seen the article about using ASN.1 before - that looks to be an excellent idea and I hope Sun continue to pursue it.

Robert

The main purpose- "daily bread and butter" so to speak of Soap/WSDL is IMO the without-round-trip communication between Rich-Clients and the server. Simple XMLHttp can query the service with or without the SOAP envelope and still maintain security by encrypting the "ticket" and the server-response, without Java or .NET installed on the client.

Another advantage with xml is that it encourages non-chatty communication. In one case there was a legacy three tier client-server app that made 7 (seven) calls to the database to fill the main form. With xml it is easier to in one call fetch everything and the server do not need to maintain state. In that way you have the suspicious "fortress" suspecting all and everybody- authenticating and checking the legitimacy of every request. This solution is better suited to Internet.

Regards
Rolf Tollerud

"Another advantage with xml is that it encourages non-chatty communication. In one case there was a legacy three tier client-server app that made 7 (seven) calls to the database to fill the main form"---> Hardly a XML advantage but a clear sign of the incompetence of the developer in charge of implementing that page.

Was it an ASP Page?

>
> Regards
> Rolf Tollerud

Why on earth would the transport format have an impact on the nr of roundtrips to the server? Thats a design and implementation issue, not a technology issue.

Johan: Why on earth would the transport format have an impact on the nr of roundtrips to the server? Thats a design and implementation issue, not a technology issue

That is Quite Correct, but as usual there are something called "theory and practice". CORBA was made to perform in Intranets. The SOAP/WSDL real life applications are in practice completely different written than apps build to perform in a 10-100MBit network.

Regards
Rolf Tollerud

> What do you find complicated in web services ?

WSDL-based Web Services are a pain to set up compared to other remoting tools, and they are magnitudes slower. They are a good solution for cross-language communication, but they are not something to recommend for Java-to-Java remoting. Web Services marketing has really irritated a lot in that respect.

> And if you do not like xml protocol, there's a binary web services implementations, for example Hessian for Caucho.

Argh, that meaningless "Web Services" term. Does it refer to WSDL/SOAP-based remoting in particular or to any HTTP-based remoting in general now? Marketing clearly indicates the former; so I tend to call the latter, well, "HTTP-based remoting protocols", to avoid confusion with WSDL/SOAP-based remoting.

Please do not throw Caucho's Hessian or Burlap into the same bin as WSDL/SOAP: There are worlds inbetween in terms of configuration complexity and performance. Hessian (binary) and Burlap (XML-based but slim) are a great choice for Java-to-Java remoting, IMO - easy to setup, and fast.

A good question is: Why choose Hessian/Burlap over RMI-JRMP/IIOP? Well, they integrate particularly well into a web environment, allowing to expose remote services from within a web app without interfering with other apps in the same VM. In comparison, RMI has to be handled by the server, shared for all apps.

As a side note, it might be interesting to have a look at the JPetStore version that comes with the Spring Framework: It exposes the very same business object via four different remoting strategies, namely Hessian, Burlap, JAX-RPC via Axis, and RMI. This can help to get a feeling for those remoting strategies.

Even with Spring's integration classes, the difference in configuration complexity between those remoting tools is pretty obvious. The sample remote client that comes with JPetStore also tracks invocation time, indicating the difference in performance between the remoting strategies.

Juergen

Actually responding to the original posting, I think it would be an excellent idea to bring CORBA up to date in Tiger. It's perhaps not the best technology in the world but it's a darn site better, more useful, faster, easy to use, secure, transactional, efficient, maintainable, etc. than WebServices. :-)

-John-

The time schedule and resources are the problem here. Of course we want the latest CORBA specification, JSR-203, JSR-xxx and so on. Take a look at the J2SE 1.5 Tiger Feature List at jcp.org and you will see the number of features that are being dropped from the initial 1.5.0 release (about 20 I think).

A better approach would be for IBM, BEA and HP to actually implement the CORBA update and get that implementation into a subsequent relase - J2SE 1.5.1.

>
> A better approach would be for IBM, BEA and HP to actually implement the CORBA update and get that implementation into a subsequent relase - J2SE 1.5.1.

Why does a CORBA implementation need to be part of J2SE. Why don't they combine on an open source style API that they can evolve to stay current to the CORBA standard and use to help sell their core ORBs. At least they can define an interface level API and then implement specifically to their ORB

Good point!!!
JDK is sooo bloated an still we need more libraries ant tools to live with.

Please count my vote for separate CORBA package and for creating common repository of Java libraries ala CPAN.

>
> Please count my vote for separate CORBA package and for creating common >repository of Java libraries ala CPAN.

Does anyone find anything in the CORBA packages useful in non CORBA projects?
I can't think of any. They don't seem to be earning their keep in J2SE.

Gary

I can't think of any. They don't seem to be earning their keep in J2SE.

I don't think that's a very good arguement, just because you're not using it it doesn't mean it can be dropped out of core. You could use the same arguement to get rid of AWT and Swing since it's rarely used on the serverside.

The fact that we have packages like logging, regexp, xml and corba in J2SE means that they are "standardised" as part of the J2SE. Without this "standardisation" we end up with problems like whech version do we use, this is already partly true with Xerces and J2SE 1.4.

Using a third part CORBA lib is alway an option, I'd still like to see it updated in J2SE 1.5.x

-John-

Does anyone find anything in java useful in non java projects?

>
> Does anyone find anything in java useful in non java projects?

Does anybody ever find it useful to download a free library and put it in there classpath?

I do. It's pretty easy. Here's my criteria for things that should be changed to separate downloads: if it's completely useless because you don't have the right version of a propietary driver that costs thousands of dollars, it doesn't have any business in there.

I'm aware that might push java/javax.sql out, but that's okay with me. I use it a lot but I can take a minute out to download it, especially since it doesn't have umpteen bazillion versions.

Take a look at the javadoc. Listed below are the 11 most repetitive 2nd-level packages, and note who's right at the top, with double everything else but swing. Seems kind of out of place for something most people find useless.

28 ->org.omg
16 ->javax.swing
12 ->java.awt
7 ->javax.security
6 ->javax.imageio
6 ->java.util
5 ->javax.xml
5 ->javax.naming
5 ->java.security
5 ->java.rmi
5 ->java.nio

OMG also ranks high in second-level packages with the most classes:
802 ./com/sun
540 ./javax/swing
522 ./org/apache
495 ./org/omg
345 ./java/awt
142 ./java/security
132 ./java/nio
122 ./javax/print
121 ./java/util
115 ./org/w3c

Why is something so bloated and yet so rarely useful taking up so much space in the JDK? Politics, plain and simple.

Yeah - these guys - http://www.zeroc.com :).