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: http://www.sun.com/software/jini/specs/js2_0.pdf
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: http://www.jini.org/wiki/Jini_Entry_Specification 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 ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: Wade Chandler <[EMAIL PROTECTED]> > To: [email protected] > 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. >
