You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alexander Veit <al...@gmx.net> on 2009/03/17 00:01:04 UTC
Starting a new incubation
Dear all,
I would like to start an incubator project at the Apache Software Foundation
with a Java library (let's call it Jaffre) I've written.
Jaffre is a lightweight RPC library for the Java platform.
It is designed to be simple, extensible, robust, and efficient with
no required dependencies other than a JRE. Currently it supports
transport over insecure or encrypted TCP channels. It supports sessions
and can be customized so that calls are performed as a particular session
dependent subject.
Implementing a service is as simple as defining a service interface,
implementing it in a pojo, and registering that pojo as a service
endpoint. The service is exposed to clients through one ore more
connectors. Clients call the service through proxy classes.
As far as I understood the Apache guides and this mailing list, the first
requirement to start an incubation is to find a champion. If this is
correct, I would herewith like to announce the search for a champion.
If I'm wrong, I would appreciate any advice how to proceed.
Regards,
Alexander Veit
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Niclas Hedhman <ni...@hedhman.org>.
Outside the WS-*, JAX-WS and JAX-RS there are at least Etch and Thrift
projects in a similar space. Those two projects are both
high-performant, light-weight and more importantly language/platform
inter-operable. Is there any particular advantage over these two
projects that you can see for Jaffre?
Cheers
Niclas
On Fri, Mar 20, 2009 at 7:05 AM, Alexander Veit <al...@gmx.net> wrote:
>> Siegfried Goeschl wrote:
>> could you provide some more technical background information
>
> The idea is quite simple and certainly not new in the Java world: method
> calls and return values are considered as data structures that are being
> serialized for transport.
>
> The data structures are
>
> JaffreCallFrame
> flags: int
> interface: Class
> method: String
> types: Class[]
> args: Object[]
> userdata: Object
>
> and
>
> JaffreReturnFrame
> exception: boolean
> flags: int
> result: Object
> userdata: Object.
>
> Call and return frames are analog e.g. to the request and response messages
> in SOAP. The userdata fields can be used to transport extra data, e.g.
> session cookies (SOAP headers can be seen as an analogy).
>
> Remote interfaces are normal Java interfaces without any decorations
> (annotations or something like that).
>
> Clients create proxys for remote interfaces. Calls to proxys are serialized
> as call frames, transported, deserialized, and then routed (per
> interface/method) to an appropriate service endpoint that implements the
> remote interface. After the call has been performed, the result is
> serialized as a return frame and then sent back to the client where the
> proxy returns the deserialized result.
>
>> +) how does it compare to RMI, JSON or Hessian
>> (http://hessian.caucho.com/)
>
> I'm not very familiar with RMI but I think it uses similar techniques. As
> Jukka pointed out, Jaffre should be considered as a RPC mechanism rather
> than a RMI mechanism. RMI is probably much more powerful than Jaffre, even
> though it may lack some ease of use and extensibility.
>
> JSON is a platform neutral web technology. It deals mainly with
> interchanging data. Remote procedure calls seem to be outside the JSON spec.
>
> Hessian is platform neutral, at least at the client side, and it uses it's
> own wire format. So it seems to be more ambitious than Jaffre. However, I
> don't know if it supports out-of-band user data and how extensible it is.
>
>
> --
> Cheers,
> Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
http://www.qi4j.org - New Energy for Java
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Alexander Veit <al...@gmx.net>.
> Siegfried Goeschl wrote:
> could you provide some more technical background information
The idea is quite simple and certainly not new in the Java world: method
calls and return values are considered as data structures that are being
serialized for transport.
The data structures are
JaffreCallFrame
flags: int
interface: Class
method: String
types: Class[]
args: Object[]
userdata: Object
and
JaffreReturnFrame
exception: boolean
flags: int
result: Object
userdata: Object.
Call and return frames are analog e.g. to the request and response messages
in SOAP. The userdata fields can be used to transport extra data, e.g.
session cookies (SOAP headers can be seen as an analogy).
Remote interfaces are normal Java interfaces without any decorations
(annotations or something like that).
Clients create proxys for remote interfaces. Calls to proxys are serialized
as call frames, transported, deserialized, and then routed (per
interface/method) to an appropriate service endpoint that implements the
remote interface. After the call has been performed, the result is
serialized as a return frame and then sent back to the client where the
proxy returns the deserialized result.
> +) how does it compare to RMI, JSON or Hessian
> (http://hessian.caucho.com/)
I'm not very familiar with RMI but I think it uses similar techniques. As
Jukka pointed out, Jaffre should be considered as a RPC mechanism rather
than a RMI mechanism. RMI is probably much more powerful than Jaffre, even
though it may lack some ease of use and extensibility.
JSON is a platform neutral web technology. It deals mainly with
interchanging data. Remote procedure calls seem to be outside the JSON spec.
Hessian is platform neutral, at least at the client side, and it uses it's
own wire format. So it seems to be more ambitious than Jaffre. However, I
don't know if it supports out-of-band user data and how extensible it is.
--
Cheers,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Alexander,
could you provide some more technical background information
+) how does it compare to RMI, JSON or Hessian (http://hessian.caucho.com/)
Siegfried Goeschl
Alexander Veit wrote:
> Dear all,
>
> I would like to start an incubator project at the Apache Software Foundation
> with a Java library (let's call it Jaffre) I've written.
>
> Jaffre is a lightweight RPC library for the Java platform.
> It is designed to be simple, extensible, robust, and efficient with
> no required dependencies other than a JRE. Currently it supports
> transport over insecure or encrypted TCP channels. It supports sessions
> and can be customized so that calls are performed as a particular session
> dependent subject.
>
> Implementing a service is as simple as defining a service interface,
> implementing it in a pojo, and registering that pojo as a service
> endpoint. The service is exposed to clients through one ore more
> connectors. Clients call the service through proxy classes.
>
> As far as I understood the Apache guides and this mailing list, the first
> requirement to start an incubation is to find a champion. If this is
> correct, I would herewith like to announce the search for a champion.
> If I'm wrong, I would appreciate any advice how to proceed.
>
> Regards,
> Alexander Veit
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Janne Jalkanen <ja...@iki.fi>.
> Jaffre does not need skeletons/stubs. The endpoints are pojos, parameters
> and return values are java.io.Serializable objects.
>
> No registry is required.
>
> Jaffre Connectors listen well-defined ports that can easily be bound to a
> specific address. They are firewall friendly.
>
> An experienced programmer will be able to fly over, and understand the whole
> Jaffre code in less than an hour.
>
> Jaffre is intended to be easily customized.
OK, I'm sold on this project by this speech alone. +1 ;-)
/Janne, who really wishes he could get back the hours he spent configuring RMI over the years
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Starting a new incubation
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Now, the only thing missing for it to be perfect, in my book,
> > is that it doesn't use maven to build... :)
> I'm not a maven expert. There's a pom that currently does not work
Par for the course. ;-) As long as it builds with Ant, people should be
happy.
--- Noel (reknowned Maven disliker)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Alexander Veit <al...@gmx.net>.
> Santiago Gala wrote:
> I think it would be more appropriate as a "commons" component
> than in any other place. I liked the stress on "not having any
> dependence beyond the JRE" and "not being XML". Both play quite
> badly with WS-*, where the norm is using XML and having lots of
> (inter)dependencies.
Yes, commons is probably a suitable place for it.
> Now, the only thing missing for it to be perfect, in my book,
> is that it doesn't use maven to build... :)
I'm not a maven expert. There's a pom that currently does not work (so it's
not in the snapshot). But if there will ever be a Jaffre release at the ASF,
it certainly will.
> Please stay lean :)
:)
--
Bye,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Mar 18, 2009 at 2:16 PM, Santiago Gala <sa...@gmail.com> wrote:
> El mié, 18-03-2009 a las 11:40 +0100, Jukka Zitting escribió:
>> Sounds like RMI is probably not the best comparison point. How does
>> Jaffre differ from XML-RPC? Are there potential synergies with
>> projects like http://ws.apache.org/xmlrpc/?
>
> Huh? I quote from a previous email in the thread:
>
>> > However, Jaffre neither does use any Web technology like HTTP* or
>> > XML, nor is it interoperable with non-Java technologies.
There's more to an RPC library than the network protocol and the
serialization format. After all, the essential purpose of an RPC
library is to hide those details as effectively as possible.
> In my book, not using HTTP and XML and not being interoperable with
> other languages/platforms makes it for something to be compared with RMI
> rather than xmlrpc.
I'm looking at it more from a functional than an
interoperability/implementation perspective. There's a difference
between calling remote methods and remote procedures, as with method
invocation you typically have things like remote object references,
distributed garbage collection, etc. As far as I can tell Jaffre
doesn't do any of that, so it's functionally much closer to procedural
RPC mechanisms like XML-RPC.
I'm by no means against this project, I'm just trying to better
understand it's main differentiators. Will Jaffre be faster or smaller
than the alternatives? Will it have better support for native Java
types? Will it be more extensible or customizable? Something else?
Alexander's earlier messages already suggested answers to these
questions, but how will these benefits be achieved? Can some of these
benefits be applied to other related Apache projects, or can Jaffre
leverage the work that has already been done?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 18-03-2009 a las 11:40 +0100, Jukka Zitting escribió:
> Hi,
>
> Sounds interesting. Is the code already available online?
>
> Sounds like RMI is probably not the best comparison point. How does
> Jaffre differ from XML-RPC? Are there potential synergies with
> projects like http://ws.apache.org/xmlrpc/?
Huh? I quote from a previous email in the thread:
> > However, Jaffre neither does use any Web technology like HTTP* or
> > XML, nor
> > is it interoperable with non-Java technologies.
>
In my book, not using HTTP and XML and not being interoperable with
other languages/platforms makes it for something to be compared with RMI
rather than xmlrpc.
I think it would be more appropriate as a "commons" component than in
any other place. I liked the stress on "not having any dependence beyond
the JRE" and "not being XML". Both play quite badly with WS-*, where the
norm is using XML and having lots of (inter)dependencies.
Now, the only thing missing for it to be perfect, in my book, is that it
doesn't use maven to build... :)
Please stay lean :)
Santiago
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Mar 19, 2009 at 12:03 AM, Alexander Veit <al...@gmx.net> wrote:
>> Sounds like RMI is probably not the best comparison point. How does
>> Jaffre differ from XML-RPC? Are there potential synergies with
>> projects like http://ws.apache.org/xmlrpc/?
>
> I'm not familiar with XML-RPC. The Jaffre wire format is binary (serialized
> Java objects). But apart from this, I believe, they're quite similar.
It should be noted, that Apache XML-RPC exceeds the standard in a
manner which would allow to use POJO's. However, that's not the
primary target, so it is likely that your code is simpler to handle.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Christian Grobmeier <gr...@gmail.com>.
This really looks cool and I surely would have evluated it for my
project, if available stable before two years.
Would hessian as a binary format be an option for Jaffre btw?
See: http://hessian.caucho.com/
its also released under ASL
I think Commons would benefit from this component and I would surely follow it.
Cheers
Christian
On Thu, Mar 19, 2009 at 12:03 AM, Alexander Veit <al...@gmx.net> wrote:
>> Jukka Zitting wrote:
>> Sounds interesting. Is the code already available online?
>
> OK, I've made an ad hoc snapshot available for download:
> http://www.jaffre.org/
>
> It's pre alpha. But the samples and also some test cases should work ;)
>
>> Sounds like RMI is probably not the best comparison point. How does
>> Jaffre differ from XML-RPC? Are there potential synergies with
>> projects like http://ws.apache.org/xmlrpc/?
>
> I'm not familiar with XML-RPC. The Jaffre wire format is binary (serialized
> Java objects). But apart from this, I believe, they're quite similar.
>
> --
> Cheers,
> Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Alexander Veit <al...@gmx.net>.
> Jukka Zitting wrote:
> Sounds interesting. Is the code already available online?
OK, I've made an ad hoc snapshot available for download:
http://www.jaffre.org/
It's pre alpha. But the samples and also some test cases should work ;)
> Sounds like RMI is probably not the best comparison point. How does
> Jaffre differ from XML-RPC? Are there potential synergies with
> projects like http://ws.apache.org/xmlrpc/?
I'm not familiar with XML-RPC. The Jaffre wire format is binary (serialized
Java objects). But apart from this, I believe, they're quite similar.
--
Cheers,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Sounds interesting. Is the code already available online?
Sounds like RMI is probably not the best comparison point. How does
Jaffre differ from XML-RPC? Are there potential synergies with
projects like http://ws.apache.org/xmlrpc/?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Alexander Veit <al...@gmx.net>.
> Marcel Offermans wrote:
>
> Out of interest, if it's a simplified kind of RMI, what are
> the tradeoffs for using RMI vs using Jaffre?
Jaffre does not need skeletons/stubs. The endpoints are pojos, parameters
and return values are java.io.Serializable objects.
No registry is required.
Jaffre Connectors listen well-defined ports that can easily be bound to a
specific address. They are firewall friendly.
An experienced programmer will be able to fly over, and understand the whole
Jaffre code in less than an hour.
Jaffre is intended to be easily customized.
--
Cheers,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 17, 2009, at 22:54 , Alexander Veit wrote:
>> Two, it sounds like your project is related to the
>> web services world. So check out the projects under
>> the Apache WS umbrella (http://ws.apache.org/), and
>> also Apache CXF.
>
> Yes, there are similarities to web services.
>
> However, Jaffre neither does use any Web technology like HTTP* or
> XML, nor
> is it interoperable with non-Java technologies. You can think of it
> as a
> simplified kind of RMI that also uses standard Java object
> serialization for
> data transfer, with a heavy commitment to the KISS principle.
Out of interest, if it's a simplified kind of RMI, what are the trade-
offs for using RMI vs using Jaffre?
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Alexander Veit <al...@gmx.net>.
Hi Thilo,
Thank you very much for your answer.
> Thilo Goetz wrote:
>
> there are two things I'd advise you to do.
>
> One, put up a project proposal in the incubator wiki:
> http://wiki.apache.org/incubator/
> You can also look at older proposals there. There is
> no need to do this all at once, you can build your
> proposal incrementally (adding a champion etc.).
OK, I'm going to formulate the proposal in the incubator wiki.
> Two, it sounds like your project is related to the
> web services world. So check out the projects under
> the Apache WS umbrella (http://ws.apache.org/), and
> also Apache CXF.
Yes, there are similarities to web services.
However, Jaffre neither does use any Web technology like HTTP* or XML, nor
is it interoperable with non-Java technologies. You can think of it as a
simplified kind of RMI that also uses standard Java object serialization for
data transfer, with a heavy commitment to the KISS principle.
It is thus somewhat orthogonal, or should I say complementary, to web
services.
> Get on their mailing lists and talk to them. They may
> champion you proposal, or have some other suggestions.
OK, I will do this as soon as the proposal sheds some more light on Jaffre.
Voluntary champions from other projects are certainly also welcome at any
time ;)
--
Cheers,
Alex
* OK, HTTP transport is likely to be added in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting a new incubation
Posted by Thilo Goetz <tw...@gmx.de>.
Alexander Veit wrote:
> Dear all,
>
> I would like to start an incubator project at the Apache Software Foundation
> with a Java library (let's call it Jaffre) I've written.
>
> Jaffre is a lightweight RPC library for the Java platform.
> It is designed to be simple, extensible, robust, and efficient with
> no required dependencies other than a JRE. Currently it supports
> transport over insecure or encrypted TCP channels. It supports sessions
> and can be customized so that calls are performed as a particular session
> dependent subject.
>
> Implementing a service is as simple as defining a service interface,
> implementing it in a pojo, and registering that pojo as a service
> endpoint. The service is exposed to clients through one ore more
> connectors. Clients call the service through proxy classes.
>
> As far as I understood the Apache guides and this mailing list, the first
> requirement to start an incubation is to find a champion. If this is
> correct, I would herewith like to announce the search for a champion.
> If I'm wrong, I would appreciate any advice how to proceed.
>
> Regards,
> Alexander Veit
Hi Alexander,
there are two things I'd advise you to do.
One, put up a project proposal in the incubator wiki:
http://wiki.apache.org/incubator/
You can also look at older proposals there. There is
no need to do this all at once, you can build your
proposal incrementally (adding a champion etc.).
Two, it sounds like your project is related to the
web services world. So check out the projects under
the Apache WS umbrella (http://ws.apache.org/), and
also Apache CXF. Get on their mailing lists and talk
to them. They may champion you proposal, or have some
other suggestions.
HTH,
Thilo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org