CODEWITHSUNDEEP
javaweb-servicesprotocolsvote
Rohit Banga
Rohit Banga

Reputation: 18926

Vote for the best protocol for the given scenario

I have a design decision to make. I need your advice.

Requirements:

Option 1 A binary protocol that I design for my application.

Option 2 Implement my server as an HTTPServlet. Client sends post requests and the query in the post message and servlet sends response in the message. However, I think that for real time interaction, this is not a good option as a new thread would be created for each post request even for the same client and session. Please comment on the efficiency of this.

Option 3 Use a normal servlet. Would face the same problem as above.

Option 4 Use SOAP

Option 5 Use REST

Option 6 Use Google Wave (I haven't read the specification yet)

Option 7 Suggest some other protocol

Right now, I don't have experience with web services, but if it is the option then I don't mind investing time in it.

Basically, I want the speed and efficiency of option 1 with a standard way of doing things.

Thank you

Upvotes: 9

Views: 1078

Answers (9)

Jason Gritman
Jason Gritman

Reputation: 5311

Hessian is a lightwieght binary protocol over http. There are a lot of different Hessian implementations so you could serve a number of different clients.

Since you're concerned with efficiency, you can find some metrics on different Java remoting protocols here: http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/

Upvotes: 1

sfussenegger
sfussenegger

Reputation: 36115

Option 7 Why don't you go for XMPP?

  • It's a standard

  • it allows messages in both directions.

  • you may use existing XMPP infrastructure (clients might connect using their Google Talk accounts for instance) or easily build your own using open source XMPP servers

  • I also like the fact, that you basically only write client code (as the server is also an XMPP client) - assuming server and client are both written in same language, you may even use the exact same code.

  • file transfers are supported.

  • easily extensible to your needs

  • it's buzzing (Google Wave) ;)

The only thing people might argue about is its efficiency - or the efficency of XML in general. I don't think it's a problem though.

Upvotes: 12

ntd
ntd

Reputation: 7434

The real-time need (if taken literally) cuts a lot of choices: the HTTP protocol is not real-time and so anything above it (including SOAP and REST) shares the same weakness. If this is a strong requirement you should look at the RTP protocol or something else that (at least) does not do handshaking.

Upvotes: 3

monksy
monksy

Reputation: 14234

Sounds like to me that you would be best served by the HTTP protocol. It has a low overhead, already well accepted. Uses TCP [which is a requirement for mobile communication], it has session negotiation [well connection wise not the actual state of the session]

Use a different protocol for sharing of video and audio, but set the connection up with the http one.

Using SOAP/web services would not be optimal, due to the processing required. From personal experince webservice clients on mobile machines is easier but the processing required is tremedious and can create a bottleneck in your application. [Mobile machines don't handle threads too well]

Also: Since you are sending data over wireless you also have to account for the additional issues dealing with unguided media.

Your requirements:

  • A server and a client. client is typically a mobile phone. : Yep
  • Connected through the Internet. : Yep, depends on how your device network is setup
  • Server and client want to talk to each other. : Yep
  • Exchange of text, multimedia between the client and the server. : HTTP works well with text and images, but you need to switch to something unreliable like UDP for video.
  • Text would be some standard format. that is predecided. : Yep
  • Real time requirements : This is impossible, but can be attempted.
  • Session would typically last for 5-15 minutes. In some cases for under a minute. assume 5 minutes as the session duration.: There are headers to keep the session open
  • The protocol should adhere to standards. : RFC Something
  • It must be efficient. : The only processing you have to do is line by line parsing of Key: data.

Also, I forgot to mention SOAP/Webservices is XML over HTTP.

Upvotes: 13

Sadi
Sadi

Reputation: 2416

Option 1 is a good option if you can make it efficient for your purpose. But I would like go for option 2 as long as option 1 is not required. Option 2 is well implemented and have good support. It should not create new threads every time if you use HTTP 1.1

But if you only have to transfer text then you can use your option 1 and some text compressing. Though there is a bit overhead to decompress the text it should too much. But it will reduce the bandwidth use of the mobile devices.

Upvotes: 1

Paulo Gaspar
Paulo Gaspar

Reputation: 11

For starters, avoid SOAP if you want to put the client on a mobile phone and have a light solution. SOAP is a pig on wasting CPU and bandwidth. It is not the simplest solution either.

If you plan on having clients implemented on the browser (using javascript) a JSON based solution is the obvious path to follow, and it is simple too. For an aidea of what it would be like, please read this article:

You can find more resources at json.org

You can probably use a JAX-RS just as a glorified Servlet implementation. (Many of us are saying that JAX-RS's JSR 311 looks like what the Servlet spec should have been from the start... which is not exactly that simple, but... )

About the "one thread per post" - that is a non issue since all the technologies you mention will behave that same way on most Application Servers / Servlet Engines - each request being processed at a given time will take its own thread.

(You are not talking about Comet here - a tecnhology which tends to take a thread per session unless you have a special bread of application server.)

Upvotes: 1

John Haager
John Haager

Reputation: 2115

I'd recommend option 3, and don't worry about the threading issues. If you are hosting this in a servlet container, the container will almost certainly make use of thread pools to optimize the processing of incoming requests and control the number of threads in the application.

Also HTTP/1.1 supports pipeline and reuse of connections for subsequent requests. This reduces the burden on the server for setting up and tearing down connections.

Upvotes: 1

Wim ten Brink
Wim ten Brink

Reputation: 26682

Use option 1, use ASN.1 as protocol! (Sometimes called binary XML.) This results in small, structured messages that can be understood by others. It's a popular standard and when you're reading this message, you've just used it. :-)

ASN.1 is part of several Internet protocols.

Upvotes: 2

Adamski
Adamski

Reputation: 54725

Go for option 1 and use Google Protocol Buffers to autogenerate your code from the protocol definition (i.e. it gives you some consistency / standardisation whilst still being efficient).

Upvotes: 1

Related Questions