river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sarman" <johnsar...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Tue, 02 Sep 2008 16:18:12 GMT
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 <niclas@hedhman.org>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message