File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Is there any alternate better technology than Web services? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Is there any alternate better technology than Web services?" Watch "Is there any alternate better technology than Web services?" New topic

Is there any alternate better technology than Web services?

Forumm User

Joined: Oct 03, 2013
Posts: 4
I mean what are other technologies that do the job which web services do..Any new better technology than web services?
Ulf Dittmer

Joined: Mar 22, 2005
Posts: 42965
"better" in what sense?
William Brogden
Author and all-around good cowpoke

Joined: Mar 22, 2000
Posts: 13037
Again with the historical perspective - before the massive use of the web brought us huge cheap bandwidth that makes web services practical, there were specialized communication APIs for compact transmission of business data.

Various kinds of Electronic Data Interchange networking APIs are still in use. It is my impression that they are a lot harder to implement with very strict formatting rules.

Hikari Shidou
Ranch Hand

Joined: Jan 22, 2013
Posts: 88
Better is indeed very wide.

Considering WebService as a way for different processes to communicate, its biggest advantage would be interoperability. Different platforms can "talk", as long as both has some framework for a WebService standard, or you are willing to develop your own. At these days of multicored smartphones, even embedded microcontrollers have Ethernet ports and HTTP Server.

In the past, inter-process communication used to require OS or IDE specific APIs, like Unix pipes, Windows shared objects, Java RMI, Borlands junks, etc. They were binary based or were implemented only in their own platform. It was VERY hard to make applications developed in different languages, platforms, compilers or even just different IDEs to talk to each other.

One of the oldest inter-platform communication solutions I know is CORBA. It uses IIOP(rotocol), which is binary based as long as I know. Each platform/IDE creator had to develop its own CORBA implementation. It could require a CORBA server that would interface between different CORBA implementations, if they weren't able to talk directly.

I remember when I tried to make Borland C++ Builder talk with Java. Java implements CORBA by RMI, when it uses IIOP as its protocol. Borland had its VisiBroker. it was Java 1.5 at the time and I was using BCB6. VisiBroker was developed in Java. Newest VisiBroker version at the time (6 if I rmember) didn't support BCB6, so I had to use VisiBroker 4.5. But VisiBroker 4.5 was developed using Java 1.3, which was discontinued, and VisiBroker 4.5's server didn't run in Java 1.5 and neither was able to talk to its RMI-IIOP. I had to use an old Java 1.3 JVM to execute VisiBroker, it was able to properly talk to BCB6 app, then use a Java 1.5 RMI server to talk to VisiBroker, and then this Java RMI server talk to my Java 1.5 app. 4 process involved and 2 CORBA servers...

The advantage of these binary/proprietary solutions is the performance. If you're gonna make Java talk to Java, just use RMI. But, IMHO, interoperability > performance. You may even end up getting your apps talking broken just by upgrading 1 of them's IDE/VM/Framework/Lib/etc version!
I agree. Here's the link:
subject: Is there any alternate better technology than Web services?
It's not a secret anymore!