Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
  b=PcPP3pGYX1Cft8ONVNIFUuSJ1AxKNcf8DZYNx+EuNnTQGTmj4IpXHx1OKOQuDdH+b/gU8jD0JeYq06/tlionIerTvkcwYahywgXE92oG5F0VLBenL81WwJPtllye1oTnO0nc1WxmG2/zAY/6uWlyW7tFzFFiJHNkKdCvYwnSV8k=;
Date: Tue, 2 Sep 2008 22:20:11 -0700 (PDT)
From: Wade Chandler <hwadechandler-apache@yahoo.com>
Subject: Re: Jini, JavaSpaces, JEE, some questions,
 and some other development issues and ideas.
To: river-dev@incubator.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <685798.91421.qm@web33807.mail.mud.yahoo.com>

I'll just comment above the rest because I think I can simplify what I'm saying more based on your feedback as it seems there is still a misunderstanding. Sorry for the unclear assertiveness Gregg. 

What I'm specifically advocating isn't live objects in the JavaSpace, from that perspective it would be immutable at the field level, and I believe I misunderstood the point you were making before about mutability, but the entry could be overwritten in the space much like a RDBMS record would be. I'm advocating the Entry template and the requirements of it be loosened and describable. If no descriptor is provided, the current requirements for entries could be the default fall back for backward compatibility.

A simple JavaBean which could be used in an Entry, not that it is special or uses any complex logic in properties, but for an example, and where its fields could be used for lookup:

public class Person {
 private String firstName;
 private String lastName;
 public String getFirstName(){
   return firstName;
 }
 //..getter here
//lastname setter
//lastname getter
}

and then to have some type of meta-data as annotations or some type of a descriptor which would come from the entry level for a Person field used by JavaSpaces to store it as needed. The benefit comes to the programmer who doesn't have to create any other TO object just to use the held data within this bean just to use it in an Entry and match the current entry pattern of use. This doesn't have to change so much the way the server works or what data is stored other than on the JavaSpaces client side and how that data is described to the remote JavaSpaces client which will be requesting and pushing to a server. So instead of:

public class PersonTO {
 public String firstName;
 public String lastName;
}

and having to move data in between the bean above and the TO, the developer simply annotates, or in the case of pre annotations, provides a descriptor at the entry level for a given entries fields, and the logic in JavaSpaces can then do what it does now with the data, yet loosen it to allow for private, public, protected, or indifferent fields in realation to templates and entries so that the information used at the client side can actually be encapsulated without a bunch of wrapper logic. 

The way the server stores the information wouldn't matter so much outside of a standardized descriptor. The spaces client API could handle setting up the data for the server the way it does now, just by using the descriptive information to build it, and this be part of the spaces specification to have that standardized.

Is that more clear? The general idea I'm advocating is to reduce the complexity between where the data comes, how it gets into an entry, and out, and the amount of coding done on the developers end just to put the data into and pull it out of the space per the requirements of the entry specification. In this sense the spaces clients would be used with the same sub-systems on different distributed services, or in any manner needed really.

So, from the point of view of a description that description/descriptor could even tell the spaces server end which fields should be used for lookup and the client side spaces API how to pull the information out to build the correct entry information for the space server per a specification. That is really all I'm advocating to change, live objects and other JARs and class files should not matter to the spaces server, and the client API can be sure it is OK to instantiate a live object and populate its graph just as JavaBeans encoding/decoding/de(serialization) does now as the spaces server ensures consistent state between what is written and read between different distributed calls.

Basically, minor changes from the servers perspective to possibly accept meta information about what it is taking and how to find it, that meta information be created by the spaces client side API from entry annotations or some getDescriptors method, so the client API accept a new form of an Entry class which is annotated or returns some set of descriptors much as the JavaBeans specification does for beans, and that is pretty much it. Really, the server wouldn't even have to necessarily understand the meta-information as the client could use the current specification to build entries/templates on the fly for reading and writing to the server as it does now.

I get one could create a simple wrapper API and annotations library to generate Entry classes for them based on BOs or any other information, I'm just thinking along the specification and how information is put into an Entry. Basically it would reduce the logic much like EJB3 persistence and annotations have done for that technology yet would have the annotating done at the Entry level to keep from having to force extra classes from JavaSpaces onto the rest of a given sub-system or design and it be at the specification level versus a bunch of roll your own logic in different providers APIs.

Thanks,

Wade

 
----- Original Message ----

> From: Gregg Wonderly <gregg@wonderly.org>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, September 2, 2008 6:58:54 PM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
> 
> Wade Chandler wrote:
> > Thinking one knows better versus flexibility and giving the ability to
> > do something are two different things. This is generally the hard part
> > about working within a group to try to get something working better for
> > ones own needs or others. Better, as I'm intending, doesn't mean better
> > in the terms of a specific persons views necessarily, but better in the
> > sense that something allows a developer to perform their role for a
> > given domain or task in the way which makes best sense for a given and
> > specific situation and not be locked into a particular pattern.
> 
> The discussions in the interview detail why the choice was made.  Having a 
> public get/set pair which set a "constant" value is equivalent to having a 
> public member that you just assign and reference.  So they chose to not require 
> the use of the public get/set method.  A subtle but important issue I already 
> mentioned, is that they did not want to download code and have live objects in 
> the JavaSpace.  That would be required for the get methods to be called.
> 
> Not having live objects is a big deal!  It really makes certain things possible 
> that are otherwise not.  It also creates certain limitations.  If you need 
> something with live objects, try out my http://griddle.dev.java.net project. 
> It's not a production ready system.  It does support live objects and 
> comparisons using method calls.
> 
> If you want everything that JavaSpaces provides, but more, than that's where I 
> think we are at in this discussion.  That "more" requires something different 
> than what exists today.  There are ramifications to the "system" when you make 
> those changes, and some of those (code versioning of live objects) can create a 
> problem if you don't do all the design for versioning (serialization issues and 
> data evolution as well) from the start.
> 
> >Anyways, this is why it helps to discuss things. So, an entry can have any type 
> of data, 
> >and that data may have any type of information wrapped however it is needed:
> >http://www.jini.org/wiki/Jini_Entry_Specification
> > 
> >It seems that link states that those fields, which may be of any type and 
> serializable,
> >are still used as part of the template along with their fields, so are the 
> public
> >fields still the only things used in comparison? If so, then the argument is 
> still
> >valid as it negates any benefit of ecapsulation and comparison as private 
> fields of
> >public properties are still not usable.
> 
> There is only one level that applies here.  There are no live objects.  What is 
> compared is the "Serialized" form of the public objects as view from the Entry 
> object's public fields values.
> 
> >I just want to understand it correctly, but
> >that link, per my understanding, states: only the public fields of any entry or 
> a
> >fields fields are used for the template, and this means information must still 
> be
> >copied around between narrowed and specific business objects and transfer 
> objects
> >even when it does not make sense to do so in many situations and designs. If my
> >understanding is incorrect, then the rest of this email is useless.
> 
> I'm confused by this slightly.  Making sense, because an API/system design 
> requires it, is a given.  Making sense because it's not what you want to do, or 
> what you have to do with another system/API is perhaps an opinion, or at most, a 
> 
> point of interest worth discussion such as we are having here right?
> 
> >Do JavaSpaces use Comparable or any other such comparison interfaces to make
> >it possible for one to add their own comparison logic in the backend? I don't
> >see this in the specifications. Are there any plans for such a template
> >comparison interface to be added, or some other type of template descriptor
> >on the books? Has the idea of beans as templates been passed around as being
> >added to the specification?
> 
> Again, live code does not exist in the existing JavaSpace, so nothing is 
> "called" in any Entry object.  The serialized form is compared for equality, 
> that's all the spec requires for the equality check.
> 
> >Look, my argument is about making the technology more flexible; not to argue
> >for the sake of arguing about what concept is better over all. I tend to not
> >buy into such arguments as I have seen many things used in very innovative
> >and good ways through the years. Look how Hibernate, Spring, and other
> >libraries have influenced other specifications, and those are some very
> >flexible libraries.
> 
> Each system/library has certain limitations and necessities in the use of them. 
>   All we are trying to say is that JavaSpaces has no live code use.  So anything 
> 
> about "code" in objects, is not touchable.  Again, this is why I created my 
> griddle project.  During the development of the JavaSpaces05 spec, there was 
> this exact kind of discussion.  So, I created griddle to give people something 
> to play with and see how it might be used.  Didn't get a lick of interest in 
> such capabilities really, so I'm not sure how to weigh your assertive arguments 
> for such things against what the community has historically done.
> 
> >I could easily make a simple annotation library which does what I'm 
> >advocating for people automatically by lazily creating a transfer object
> >for a POJO or JavaBean, and that could live outside the specification.
> >I just think it makes good sense to have that live inside the
> >specification where such an extra library and logic are not always
> >needed. I guess both things could live there though. An annotation
> >library and the abiltiy to do more; this would allow many different
> > uses and not lock folks into a single pattern by allowing pure
> >transfer objects to be created without one needing to handle this
> >logic manually, TO->BO and BO->TO, and also allow for those small
> >and specific BOs in a given system to be used as both when needed.
> 
> My view is that separating a TO from a BO because of a "transfer" systems 
> requirements, is exactly the right thing to do.  Creating a layer of abstraction 
> 
> in the application software to keep an external system from impacting the 
> applications architecture is a good practice is it not?
> 
> For an HTTP web server resident servlet, would you have HTTP Request and 
> Response objects running around inside your application, or would they only be 
> visible at a particular interface?
> 
> >One can argue that is good or bad, but the real argument on 
> >whether something is good or bad should come down to a specific
> >use at a specific time within a specific design and not at some
> >high level argument of how it is always a good or bad thing.
> 
> Yes, by and large, you can make this kind of assertion.  But practically, all 
> kinds of architectural issues come into play with software because APIs are not 
> arbitrary.  Many have specific requirements for order of operations data types 
> and behaviors (like hashCode() and equals()).  I agree in principal with your 
> argument about the issues, but I'm not sure why your argument is pulling away 
> from the facts that exist so that we can focus on the issues that make it hard, 
> or impossible to do that and still meet the same service level agreements that 
> exist today with the existing JavaSpaces specification.
> 
> Live code in the JavaSpace would change everything.
> 
> Gregg Wonderly