Re: [json] Simple Remoting Java Framework is Alive
- On Fri, Aug 28, 2009 at 8:48 AM, serhat.dirik<serhat.dirik@...> wrote:
> Hi Folks,How does this compare with DWR?
> Recently I published "Simple Remoting" ( http://sites.google.com/site/simpleremoting/home ) java open source project on sourceforge.net . The purpose of this project is creating an alternative SOA implementation which is lightweight, easy to use and flexible. I believe that this project is not a challenge to webservices, but it might be more suitable in some cases like RIA platforms, testing and projects where you have to work against tight schedules.
> If you have time to examine It and share your ideas with me, I would be appreciated.
> Many Thanks In Advance.
> Serhat Dirik
> Features At A Glance
> • It's lightweight and requires no additional knowledge.
> • Installation is quite easy as adding one listener to your web application configuration
> • Build-in support for POJO, EJB2.1, EJB3 and Spring . Framework is expandable so developers can implement additional locators as they need.
> • No programming and modification required to expose components as services. Simple xml declarations are enough.
> • Java & Java Script client implementations are out of the box. Client implementations are easily adaptable to .net and other popular languages
> • It can work in any application server which works on JVM 1.5+
> • It uses a JSON message format instead of SOAP which is more human & software friendly. Browsers can evaluate service responses at run time as java script objects.
> • Additional header fields can be embedded in service requests and responses. Thus developers can post additional fields to services to apply their policies to service calls.Message headers are accessible by interceptors and services. Message headers are accessible by both interceptors and services.
> • Service instances can be created in request, session and application contexts.
> • All exposed services can be accessed through a single – multi threaded end point implementation. Currently only a http(s) request/response end point is implemented. But the framework is quite flexible and expandable. Implementation of a single simple class is enough to have additional end points. JMS and Http Callback implementations are planned for the further versions.
> • Transformation of all java types including complex beans are supported. Serialization is not required, all object are supported. Custom transformers can be easily added to the framework
> • It comes with build-in security which is integrated with J2EE security. It supports authentication, authorization & transport layer security enforcement. It's very easy to define different role access to a single service's operations.
> • It supports idempotency of session services. Duplicate calls are prevented
> • Service calls can be filtered through custom interceptors. Each step of a service call can be controlled through interceptors.
> • It has a build in Registry Query service. Service list, operation signatures can be discovered through this service.
> • It's quite flexible and expandable.It's easy to implement your own end-points, locators or even transformers
> Yahoo! Groups Links
> How does this compare with DWR?
I don't know DWR in depth but I can say that the main difference is DWR is focused on AJAX, but SR mainly focuses on services and SOA. SR is not only targeting browsers, but java and other rich clients as well. Their intentions are different.
SR focuses on :
* Converting server side object to services
* Service registry & service registry query
* Managing server side objects life cycle
* Services security
* Message filtering mechanisms
* End-point implementations (currently only http is available, jms is planned as target)
* Messaging format (like SOAP)