river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 00:03:14 GMT
Maybe more clearly stated...will give it a try.

This is one of the initial specifications which I'm referring as it relates to JavaSpaces:

Here it details, plus more, that which I'm addressing. 

It formulates the use case to be one of a  (long adjective) persistent concurrently sound
event based distributed data store. In short, I haven't been trying to address the event based
mechanisms and what that means to the logic using it as that isn't central to my argument
as to why, at least to me, it makes sense for this to allow bean patterns in the search versus
purely forcing public fields as a location mechanism. Of course, if what Gregg is detailing
is that spaces doesn't store the actual entry, but only serializes those fields or fields
of fields, and not the object graphs of the fields then that is one thing, but I believe that:

details a fields object graph is stored, and thus a bean or POJO which is a field is serialized
and stored and can be used in the lookup/fetch/read, but I'll check out his project which
he gave a link to see the sources. 

Regardless of how it is stored, I'm just advocating to not force transfer objects and entries
to be required to use public fields so that encapsulation and bean patterns can be used, and
be used in the lookup of templates and entries and transfer objects. This simply allows TOs
to be perform double duties in the logic which will use them, and does not bind them to JavaSpaces
patterns. So, objects being distributed through either type of backing store, JavaSpaces,
LDAP, JMS, or even serializable objects attached as fields in an EJB, can be used to seamlessly
replace that backend mechanism which is used to store them or to concurrently move them from
place to place, and is why I have chose not to really get into the most cool aspect of using
JavaSpaces behind the scenes to produce a work flow through its event notification system.


Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

----- Original Message ----
> From: Wade Chandler <hwadechandler-apache@yahoo.com>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, September 2, 2008 7:20:41 PM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
> Not trying to hammer, and sorry if there has been some confusion, but really 
> this one major issue in contributing to anything. 
> "Try it" or "use it". That is an easy answer, and not to bash or put you or 
> anyone on the spot, but depending on how one reads another's message, they can 
> take it in any context they see, but you have to dig into what I'm saying, 
> reading it all, to get that I'm not asking how to use it from the aspect of what 
> it is or the semantics of what is on the surface of the current specification. 
> I get that; I mentored a project centered on JavaSpaces, but rather how it 
> compares to JEE from my orginal email, and too, the particular forced style of 
> entries and their fields and how they are used in looking up instances is 
> restrictive from my point of view, and I'm trying to express that as an issue 
> for myself and why it is. Naturally fields and state are going to determine 
> uniquenes and what to read/write from a shared context or distributed memory 
> unless it some kind of an indexed array style memory; in generalitities it is 
> the same concept as that of a database, and in reality one would assume a spaces 
> server would use some type of indexing even if it be a hash for the templates 
> written to it.
> Too, I'm not specifically talking about the BO being the Entry itself, but could 
> be a field in an entry and decoupled for the most part from JavaSpaces except 
> from usage as a template. Then, that object just being a POJO used in the manner 
> I wish in a given and specific design, but a BO could be an Entry if someone 
> wanted to lock into JavaSpaces as their shared memory. Now, obviously from the 
> perspective Gregg has written, and Sean, I need to look more into that.
> I think it important when someone comes trying to look at something from the 
> different perspectives of possible, known and unknown, use cases, it is best not 
> to key hole, to fix or lock, the conversation into a particular context which 
> really doesn't address what the person is attempting to address. Maybe I haven't 
> been clear enough in what it is I'm trying to address, and if so, appologies, 
> and I'll try to work on that, and try not to get frustrated when I have confused 
> the conversation, but I think some of the conversation is getting twisted into a 
> *best way to do a general pattern* versus what I'm talking about.
> Now, if what Gregg is talking about is a real issue with concurrency and 
> JavaSpaces, then that to me is an issue which needs addressed, but, per my 
> understanding when reading the initial JavaSpaces specifications its main design 
> and use case was to be a concurrently shared distributed memory. To me that 
> implies concurrently sound shared distributable memory which is supposed to be 
> mutable, and I may find in the specifications my assumption wrong and incorrect 
> and I have misread or that my assumption is incorrect only in reality, as Gregg 
> mentioned a class loader issue. Not saying *anyone* is wrong, but that I'm 
> looking at it from the specifications perspective and my uses of it thus far and 
> what that actually means to not only me, but new adopters. I would really like 
> to get input from the specification authors or those who are taking up the 
> mantle, so to speak, on what was intended and what was not, or even what is 
> intended moving forward.
> I think the technology is cool already, especially from the discoverabitlity 
> perspectives of Jini services, and my understanding of JavaSpaces. But, I still 
> want to improve it in places that seem cumbersome to me. Again, that may be 
> incorrect, and my understanding of the general use case which JavaSpaces was 
> trying to address may be incorrect, and that may be the answer to this 
> conversation. I just want to make sure the answer I get is inline with the issue 
> I'm trying to resolve as to me it relates to adoption of the technology. 
> My main reason for writing is I'm interested enough in the technology to want to 
> contribute to it, and not just use it. If I join a community and get a burden of 
> time and commitment into something I want to make sure it is something which can 
> grow and advance not only from a technology perspective, but also from a 
> community perspective.

View raw message