BS Remoting is very helpful in an extranet environment to handle HTTP communications between a rich (Swing) Java client and a J2EE server. It's light and elegant, and much more performant than SOAP.

The API proposes a precise way to retrieve EJB remote interface using the ServiceFactory interface. There are 2 implementations of the communication : the RMI invocation can be used in a LAN where no firewall will block the protocol, whereas the HTTP invocation is used for WAN communications as this protocol is firewall friendly.

BS remoting 2.0.1 is a maintenance release which fixes a bug when used with JOnAS 3.3. The release also updates the build Ant file to include task for the JOnAS distribution.

Last but not least, the distribution now contains the server code used for the new demo application showing the features of the BS Remoting in action ! As this demo is launchable by Webstart don't hesitate and click on the link : http://www.bs-factory.com/jboss/remoting/webstart/remoting.jnlp

Links :
BS Remoting : http://www.bs-factory.org/BSFDocs/Features/BSRemoting.html
BS Remoting is a component of the BS Framework : http://www.bs-factory.org/

Too bad it doesn't support SSL or a secure format of some kind.

We did developped it for the moment but it shouldn't be very difficult.

Gaetan Zoritchak,
www.bs-factory.org

Too bad it doesn't support SSL or a secure format of some kind. We need SSL support. http://www.developerzone.biz/index.php?option=com_content&task=view&id=97&Itemid=36&PHPSESSID=c71bb126204384eaa2413399b4edc2d9 SSL Tutorial

Congratulations, nice name! Never thought of changing it? Might spare you guys from some cheap shots.

How does this product compare to Caucho's Hessian protocol?

I believe this dilema is similar to EJB or not EJB debate. But I don´t want to start another flame. My point is to know about the arguments to use simpler "protocols facades" as an alternative to Web Services.

1) Respect to standarts :
   I am working on a project that uses SOAP. Theres no need to integrate (consume or serve) with another company (business partner) service. No assincronous processing. Althought my boss think diferent, I think there is much more cheaper (an fast) to use some similar solution like BS Remoting. BTW : I´d prefeer to use http://www.caucho.com/hessian.

2) Easy to use :
  From the begining I was scared about the learning curve to do just a simple remote call : you need to master JAX-RPC, WSDL and WSDD files, then the SOAP toolkit you have selected (we are using Axis) and if you need to transfer some binary objects you need to know about SAAJ... After some days I concluded Axis is pretty easy to use. But I´ve spend few WEEKS to start producing production code with this stuff... And I just wanted to do a remote call...(look at Hessian simplicity !)

3) Security concerns
   My boss also choosed to use WS-Security. From the begining I was wondering : Why we need all this stuff ? If there are just a few entities (sites) to certify and we arent´t consuming or serving any other external service I think we could just use HTTPS connection with mutual authentication. I think this way we are solving the authentication and the confidentially (encripted data) problems. Beside the integrity of the message will not be checked in every request, I assume its much dificult to anyone to intercept an change the messages. And authorization is not a problem for this project.

So, if I just want use HTTP as the main protocol to do a simple remote call with Java in both sides, Web Services isn´t a overkill ?

Thanks,

Rodolfo

I fully agree. A lighter-weight HTTP-based protocol like Caucho's Hessian (binary) or Burlap (XML) is indeed a good option for such a scenario. I used Hessian in a production application and had good experiences with it. A remoting protocol can't be simpler to set up, kudos to Caucho!

BTW, I've also added support for Hessian and Burlap to the Spring Framework. On the one side, there are accessors that can make any remote Hessian or Burlap service available as bean in a Spring application context. On the other side, there are exporters that can take a Spring-managed bean that implements a business interface and expose it as Hessian or Burlap service for remote clients at some given URL, as long as all the method arguments are serializable.

Juergen

Well, I've never used Hessian, did use a lot of HttpInvokers from JBoss and they're pretty cool as well! I agree that in a lightweight app, you might prefer the Hessian solution (especially in combination with Spring).

We needed a more clusterable solution for both SSBs and MDBs over HTTPs and used the HttpInvoker for that. It's a bit hard to setup, but once you're done, it's just adding some lines to the container configuration.

You are tied to EJBs then however :)

What is JBoss' HttpInvoker about? An alternative wire protocol for remote EJBs that works at the HTTP level, I assume. Is it transparent in that it does not require any change of standard EJB client access or service implementation code - but just a change of server configuration?

Hessian should be clusterable via standard web server clustering, as it is a stateless HTTP-based protocol. Of course, JBoss' EJB client proxies might be more sophisticated in that they could automatically retry a failed invocation of idempotent methods etc.

BTW, Resin Enterprise uses Hessian as its default remote EJB wire protocol. I've never worked with their EJB support though, just with plain Resin and Hessian/Burlap (which are available standalone but also included in standard Resin).

Juergen
(not affiliated with Caucho other than being a happy user)

Excellent work on Spring. I laso used Caucho's Hessian and it rocks. Next time I need something similar I'll consider using Spring altogether. Heck. I'm already evaluating Spring :-)

When you start using Burlap/Hessian there is no going back to any other remoting alternatives, and as Jurgen Holler said Spring makes it breeze to work with. You core logic is completely unaware of the fact that it is interacting with remote objects.

Brilliant and simple architecture, and great framework to work with.

I am new to Hessian. In JBoss, is it possible to use hessian to replace stateless bean? The purpose of the project is to get rid of rmi port configuration involved in session bean. When the hessian servlet running on the server side accesses to Hibernate session factory which was started via service MBean in JBoss, there was exception thrown: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]. I was thinking the reason may be Hessian was not properly configured with jndi? Will anyone give me the advise on how to configure jndi for hessian servlet on JBoss and no session bean involved? Your advice will be highly appreciated! -Jenny

> So, if I just want use HTTP as the main protocol to do a simple remote call with Java in both sides, Web Services isn´t a overkill ?
>
 
We believe that. We sometimes use web services but as you say SOAP is quite tricky and heavy to use, notably when using complex java objects. Moreover, the xml parsing consumes CPU. We think SOAP is better used only for integration purposes (B2B).

Gaetan Zoritchak,
http://www.bs-factory.org

>> My boss also choosed to use WS-Security.

He, he, maybe you boss wants bombastic and buzzword heavy resume!

MC

When lauching the Bookstore demo, either using the rich client or thin client, got an error read " The server is unavailable " ...

Our server is really too small to handle several website and demos at same time. Open source is not so profitable ;-).

Gaetan Zoritchak,
http://www.bs-factory.com

"Much more performant than SOAP"

Well is it also much more performant than XML-RPC ;-)

This might be interesting for the one or the other: COMJAT.NET's Remotor is a Java based web service system published under the LGPL (open source and still usable in commercial applications).

It is a very easy to use and a very fast remote procedure call engine. No need to bother about Stubs & Skeletons and Naming-Services. It is 100% pure Java and runs in any J2SE 1.3 and upwards. Using the Remotor you may equip any Java-Swing client and your server software with remote procedure call functionality.

As it is open source you may add new features as needed.

Also interesting: The links for downloading and coding instructions ;-)

http://www.comjat.net/net/comjat/web/systems/remotor/page.system.remotor.summary.index.html

Will BSR2 run on standard Servlet engines like Tomcat? That means a swing client and a tomcat backend? I don't want to use EJB only Tomcat.

Thanks,
Sam

Actually, no. We provide this framework as a way of invoking EJB. We find that EJB are a good place to put business code, even if you don't want to use entities.

Using a session bean in JBoss is quite easy.

Gaetan Zoritchak,
BSF Team,