JBoss Remoting 1.0.1 beta has just been released. The purpose of JBoss Remoting is to provide a framework with a single, simple API for most network based invocations and related services.

The design of JBoss Remoting is such that the user only needs a simple url string in order to be able to identify and call upon any remote server.

To wet your appetite, here is a list of features included in JBoss Remoting:

    * Server identification – a simple String identifier which allows for remoting servers to be identified and called upon.
    * Pluggable transports – can use different protocol transports, such as socket, rmi, http, etc., via the same remoting API.
    * Pluggable data marshallers – can use different data marshallers and unmarshallers to convert the invocation payloads into desired data format for wire transfer.
    * Automatic discovery – can detect remoting servers as they come on and off line.
    * Server grouping – ability to group servers by logical domains, so only communicate with servers within specified domains.
    * Callbacks – can receive server callbacks via push and pull models.
    * Asynchronous calls – can make asynchronous, or one way, calls to server.
    * Local invocation – if making an invocation on a remoting server that is within the same process space, remoting will automatically make this call by reference, to improve performance.

Read Remote invocations simplified

See the project page (http://www.jboss.org/products/remoting) for more info on remoting (including full user’s guide, demo, and distribution).

Haha, i've made something similar using spring recently. Now i'm gonna sue JBoss <LOL>.

Haha, i've made something similar using spring recently. Now i'm gonna sue JBoss

I've just released Commons Remoting version 0.000013, an API that abstracts both your Spring-based implementation and the JBoss implementation, so you can switch between them just by changing four XML files, and it also includes pluggable support for a half-dozen Apache Commons remoting projects, plus it replaces the JBoss logging with Clogging, and the whole thing is built with Maven.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Ok, that was uncalled for. That's just nasty.

that's funny. clogging is a good exercize, if I were to get off my fat bottom and could dance.

would you mind refactoring your api completely to accomodate my javascript xml-rpc remoting library? its worth having a good look at my api, i've left threading and pooling to the user, but i suppose i could use some other commons projects for that too.

this guy is just too kool man.. purdy turdy strike the fire again but just little boy who like to advertise his little framework creation when he getting the opportunity...

shame shame purdy turdy
Coherance-Is-The-Shit

heh

this guy is just too kool man.. purdy turdy strike the fire again but just little boy who like to advertise his little framework creation when he getting the opportunity...

What's wrong, Patel, suddenly forget how to speak English again?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

.. now u calling me patel .. this i like .. please calling me the dude because we knowing you can read!

where gone the trusty sidekikc to defending you? he working for tanggrosol also. anyways ..

The Dude
DudeCompany Inc.
ProductivePlug - Spring Killer!

KICK #tss "the dude" Stupidity!

The dude goes that a way >>>>>>>>>>>>

Can you actually prove that ?

TheDude looks very much like an act ideed.
So, let's hear it !

this guy is just too kool man.. purdy turdy strike the fire again but just little boy who like to advertise his little framework creation when he getting the opportunity...shame shame purdy turdy

Hmm, guys, wake up, it was meant to bu funny.
I hate those undocumented little crappy frameworks too.

I've just released Commons Remoting version 0.000013, an API that abstracts both your Spring-based implementation and the JBoss implementation, so you can switch between them just by changing four XML files, and it also includes pluggable support for a half-dozen Apache Commons remoting projects, plus it replaces the JBoss logging with Clogging, and the whole thing is built with Maven

I hate maven actually, but you are very close ;-). Just thought it's funny to see something with similar idea from JBoss.
Btw, using just string to locate the service is not so nice as one would think.

Haha, i've made something similar using spring recently. Now i'm gonna sue JBoss

I've just released Commons Remoting version 0.000013, an API that abstracts both your Spring-based implementation and the JBoss implementation, so you can switch between them just by changing four XML files, and it also includes pluggable support for a half-dozen Apache Commons remoting projects, plus it replaces the JBoss logging with Clogging, and the whole thing is built with Maven.Peace,Cameron PurdyTangosol, Inc.Coherence: Shared Memories for J2EE Clusters

Implemented using inventive component data structures I hope.

The point of JBoss Remoting is to satisfy the multitude of requirements that the JBoss family of projects/products requires and to unify these requirements into one API. If the community can take advantage of it, then even better, which is why Telrod is packaging this stuff and treating it as a product.

Will it work in non-IP networks? Does it have iteroperability with SOAP or CORBA? How does it relate to REST? Could not access the User's Guide page without registration Ah, well.

Will it work in non-IP networks?

If you mean networks like ATM, then no. Would be interested in what use case you would have for this.

Does it have iteroperability with SOAP or CORBA?

No. I did have a SOAP transport, but really does not make sense because would require jaxrpc mapping file for any complex objects being passed or returned. At that point, a full web services stack is more appropriate. IIOP interoperability is not supported either. Unless there is a clear demand for it, I will delay implementing it as I spent many years back in the day doing CORBA development and don’t relish returning to it. If anyone has fonder sentiments towards CORBA, please feel free to step up and contribute.

How does it relate to REST?

Never heard of it, so can't say.

Could not access the User's Guide page without registration Ah, well.

Your kidding, right?

The signal-to-noise ratio in this place is getting almost as bad as Slashdot. I half-expect to see a post that references Natalie Portman and hot grits -- then I'd really know the end is near.

(Ooops...)

Check it: When Will We Come Full Circle?

Otherwise I will send my posse after you

The signal-to-noise ratio in this place is getting almost as bad as Slashdot.

I apologize .. I'm marking my previous off-topic posts as noisy. I just couldn't resist the "commons" reference.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Cameron Purdy said:

The signal-to-noise ratio in this place is getting almost as bad as Slashdot.

I apologize .. I'm marking my previous off-topic posts as noisy. I just couldn't resist the "commons" reference.

Huh? Just searched for the word "commons" in this thread. The very first occurrence was in Cameron's message:

I've just released Commons Remoting version 0.000013, an API that abstracts both your Spring-based implementation and the JBoss implementation, so you can switch between them just by changing four XML files, and it also includes pluggable support for a half-dozen Apache Commons remoting projects, plus it replaces the JBoss logging with Clogging, and the whole thing is built with Maven.

Regards,

Francisco

JERI does this (and more) already.

See:

http://www.artima.com/intv/jeri.html

Had not heard of JERI before, so thanks for the link. From the article, it looks like JBoss Remoting carries a lot of the same design concepts as JERI in regards to marshalling and transports. JERI also has support for security, which JBoss Remoting does not at this point. However, I didn’t see anything about callbacks or async/sync invocation support. Also didn’t see anything about automatic discovery, but assume this is done using Jini?

Tom, you forgot remote classloading.

As for security, transaction propagation, and clustering, it is currently a layer built on top of JBoss Remoting

Had not heard of JERI before, so thanks for the link. From the article, it looks like JBoss Remoting carries a lot of the same design concepts as JERI in regards to marshalling and transports. JERI also has support for security, which JBoss Remoting does not at this point. However, I didn’t see anything about callbacks or async/sync invocation support. Also didn’t see anything about automatic discovery, but assume this is done using Jini?

async/sync invocation support is there. Callbacks - not directly part of the JERI model - but Jini supports event listeners (which I believe could do the same thing). Discovery would be done with the normal Jini mechanisms (using a Lookup Service).

Note there is discussion around putting the Jini code under an open source license of one form or another. If folks have a strong opinion on what type of license to use their is a poll running on http://www.jini.org.

How does JBoss remoting compare to WSIF, Mule, and ESB?

WSIF comes from a much more web services point of view (basically providing an api for invoking web services). Nothing wrong with this, just a different goal. Also looks like last release was over a year ago, so would assume this is no longer being worked on.

Mule is a more message oriented framework (think ESB or MOM, as it used to be called). Is useful for when needing to build a message, send it out, and modify it as it makes it's way to it's final destination. I think Ross has done a great job with it, but think it serves a different purpose.

We developed something similar in the past and used the JCA Common Client Interface as the Client API instead of a custom API.