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 <[EMAIL PROTECTED]>
> To: [email protected]
> 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
