views:

72

answers:

2

Hi,

I need to create a system oriented around Methods where providers can register for the Methods they handle and consumers can do two things (for now) - either get Metadata for a method or execute it. I'm considering creating a REST style architecture where methods are resources with unique URIs and an interface consisting of two methods - getMetadata and Execute.

I'll need to have an equivalent of @RequestMapping so that the provider that handles specific methods can be located by the central dispatcher. As a result the provider will return either Model or Metadata object.

This looks pretty similar to Spring MVC but I don't want to expose and consume my resources(methods) over the web and use http as this will incur unnecessary overhead. Instead I want to use it like a standard java API where java methods are called and java objects are transferred. I can do that by writing my own equivalent of @RequestMapping and Dispatcher logic but I was wondering if there's a better way to do this with Spring. Any suggestions?

Thanks! Kostadin

A: 

You are saying you want to do using REST and everything will have a unique URI but not over HTTP?? Sounds like you are looking for RMI or something similar... Chech Burlap or Hessian both of them has excellent support from spring.

Teja Kantamneni
Yes, because the system consist of dynamic methods which could be provided by different parties I thought of using URIs to identify and locate the methods. But I want everything to stay inside the JVM and not go over HTTP.
Kostadin
REST itself says nothing about HTTP - it's perfectly viable to implement REST concepts over pretty much any protocol, it just so happens that a lot of people are doing it over HTTP. Just because he doesn't use HTTP doesn't make it RMI.
Gandalf
@Gandalf Right. Is there currently any other implementation of REST other than over HTTP?
Teja Kantamneni
A: 

There's software out there called NetKernel that might interest you. Its literature says that it is an implementation of Resource-Oriented Computing. It looks like it rigorously separates its logical computing model from the physical details. It's RESTful, defining a resource model, a limited set of verbs, and a naming scheme. Implemented in Java. Comes with HTTP and other transports built in.

It doesn't have a Java in-process transport, but you could probably write one for it pretty easily.

Hmm...if you never need to process requests from out-of-process sources, it's probably overkill for you, but maybe it will show you some useful patterns.

Ladlestein
This looks very similar to what I need. I'll take a closer look at it even though it doesn't support in-process transport that I need. Thanks!
Kostadin