Hi Wade,
(Warning: Non-expert response follows. ;)
I think they key problem with setter/getter matching is it would REQUIRE
the javaspace to make the entry "live" in order to execute the getter
used during matching. (I think this is why Gregg focused on the "live
objects in a space" topic.)
Even with metadata, you must have a live object in order to execute a
method (ie: getter) on that object.
If you are proposing that additional metadata allow matching on
non-public fields WITHOUT actually executing the getter, things get
muddy fast. For example: if you change your Person example code to:
> public class Person {
> private String firstName;
> private String lastName;
> public String getFirstName(){
if (true) { throw new RuntimeException("some validate failure); }
> return firstName;
> }
> //..getter here
> //lastname setter
> //lastname getter
> }
Assuming a "metadata matcher" existed, I see only two options:
1. If the space just matches on the serialized/marshalled "value" of the
firstName field, the "validate" logic of the getter never runs. To me,
this feels like black magic that would confuse users.
2. If the space must call "entry".getFirstName(), you are back to
requiring the space to deserilize (make "live") the entry object to do
the matching. This lands you back at: http://griddle.dev.java.net
Am I missing some concept that would allow a non-live/marshalled object
to be matchable?
Dan Rollo
Wade Chandler wrote:
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
