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 Tue, 02 Sep 2008 23:20:41 GMT
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.

Thanks for all the input and answers,

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 <hwadechandler-apache@yahoo.com>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, September 2, 2008 6:44:19 PM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
> 
> Obviously from my email I know *how* to use it in its current form. The point 
> I'm making has nothing to do with this.
> 
> 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: John Sarman 
> > To: river-dev@incubator.apache.org
> > Sent: Tuesday, September 2, 2008 12:18:12 PM
> > Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development 
> issues and ideas.
> > 
> > Wade,
> > I just have one question,  have you ever used JavaSpaces.  If not give it a
> > try!
> > 
> > // do ctrl-shift-I in netbeans to fill in the imports..  Thank you netbeans
> > :)
> > 
> > public class WadesEntry extends AbstractEntry {
> > 
> > public WadesBusinessObject bo;
> > 
> > public String name;
> > public String version;
> > public String blah;
> > 
> > public WadesEntry() { }
> > 
> > }
> > 
> > public class WadesBusinessObject implements Serializable {
> > 
> > private String somePropertyOnlyAccessableThroughMethods;
> > private String somethingSomethingSomethingDarkSide;
> > 
> > public WadesBusinessObject () {
> > 
> > }
> > 
> > //hit crtl-space and choose the gets and sets for above variables again
> > thanks netbeans
> > 
> > }
> > 
> > 
> > //write code to get an instance of a space
> > WadesEntry entry = new WadesEntry();
> > entry.name="familyguy";
> > entry.bo = getTheBizObj();
> > entry.bo.setSomethingSomethingSomethingDarkSide("Something Something
> > Something Complete");
> > 
> > space.write(entry,null,Lease.FOREVER);
> > 
> > //now write another app also with an instance of a space
> > WadesEntry entry = new WadesEntry();
> > entry.name="familyguy";
> > 
> > WadesEntry e = (WadesEntry)space.takeIfExists(entry,null,60000);
> > 
> > String s = e.bo.getSomethingSomethingSomethingDarkSide();
> > 
> > System.out.println(s); // prints Somethin Something Something Complete which
> > is from Family Guy if you dont watch it
> > 
> > So the point of the close but non compilable code is that you write an entry
> > that has your business object and is referenced with a String name into the
> > space.  You then create a template with only the name set and you get back
> > the biz obj.
> > Now to me thats Cool!!!  It wasnt cool until i set down and got jini working
> > on windows 98 (Good grief that was so hard in 99)  then I started up a
> > space, got a good lesson of serializable, via the NotSerializableException.
> > finally got it and was like " I GET IT" Oh course I only knew java for 1
> > year at that point.
> > 
> > 10 years later.  Still cool.  What would be real cool would be to say
> > @EJB
> > SpaceLocator locator;
> > 
> > then run the above code in glassfish , bridging the 2 worlds.  Which Im sure
> > has been done more than once.
> > 
> > look I dont wanna convince you how cool the Javaspace is, I do want you to
> > just try it and see for yourself.  Mainly for selfish reasons, because I
> > cant add the Jini/river plugin into Netbeans(havent seen that) , then add
> > that to my JEE project. I notice that you are on many great groups and
> > convincing a guy like you means that my job of writing code becomes easier,
> > because you catch the Jini bug. And like me you may infect someone else with
> > it, who then takes the initiative to create the river plugin.
> > 
> > One more thing you may say well I could just use a PersistanceContext to
> > easily do the above example, but try storing a smart proxy in a database.
> > What what what a smart Proxy, well a good real example is John Mcclains
> > Holowaa project.  Using the JavaSpace you can store a smart proxy of an
> > InputStream. When you pull that from a space you can read the stream,  the
> > stream doesnt have to be closed in the space, because the object in the
> > space is just a reference to a backend jini service, and not the actual
> > data.  I bring this up because I in the past used this to store live feeds
> > of data from remote weather stations in the field. upon connection you get
> > all the data in the past, plus you get the updating info also.  Now I have
> > never heard of querying a database and getting data that then updates
> > without having to requery.
> > 
> > Ok enough rambling, crank up netbeans spend a day on getting Jini up (my
> > biggest complaint)  and try it for yourself!
> > 
> > Rambling Completed
> > John Sarman
> > 
> > 
> > On Tue, Sep 2, 2008 at 10:35 AM, Wade Chandler <
> > hwadechandler-apache@yahoo.com> wrote:
> > 
> > > ----- Original Message ----
> > >
> > > > From: Niclas Hedhman 
> > > > To: river-dev@incubator.apache.org
> > > > Sent: Tuesday, September 2, 2008 2:41:27 AM
> > > > Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other
> > > development issues and ideas.
> > > >
> > > > On Tue, Sep 2, 2008 at 4:23 AM, Wade Chandler
> > > > wrote:
> > > > > What I'm getting at is those TOs can hold some logic used on both
sides
> > > in the
> > > > situations where needed, and that logic itself is not going to be
> > > serialized for
> > > > instances held within a JavaSpace. The logic I'm talking about is of
> > > course
> > > > state mantainence as it relates to properties or JavaBean specifications.
> > > The
> > > > only thing being marshaled are the fields not the methods. Just being
> > > able to
> > > > encapsulate some things means you can control state and double duty those
> > > > objects a bit better...more protection even in logic you intend to always
> > > be
> > > > secure. And, that logic will not be marshaled, just the state or fields.
> > > >
> > > > AFAIK, you can serialized anything into the JavaSpace. The public
> > > > field requirement is only for what can be used to look up those
> > > > instances later.
> > > >
> > > > The rest of this discussion is mostly about programming patterns, and
> > > > every developer thinks he knows better.... ;o)
> > > >
> > > >
> > >
> > > 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.
> > >
> > > 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. 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.
> > >
> > > 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?
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > One can argue that is good or bad, but the real argument on whether
> > > something is good or bad shoud 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.
> > >
> > > Thanks,
> > >
> > > Wade
> > >


Mime
View raw message