river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Calum Shaw-Mackay" <calum.shawmac...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Wed, 03 Sep 2008 22:04:33 GMT
Hi Wade -

I've stayed out of this conversation for a while, as the only view
point I can give you is based on the stuff I've been doing in Neon
(and it's now near-mythical 0.2 release, which is now becoming the
stuff of urban legends).

Just talking a little bit about the usage of public fields as search
criteria in templates. Neon has the ability to automatically encrypt
java entries using key pairs in a keystore, and it does this
completely on the fly. However the issue then becomes how do you
search on something that is encrypted?

The point comes down to that, in general, only a few fields are used
for matching, the rest are left as null. In Neon, if encryption is on,
it accesses the public fields in the original entry and (through
convention looks for a encrypted class definition for the entry class,
placing the search fields in the encrypted entry, unencrypted for
searching, and encrypting the entire original entry inside this new
entry before sending it to the space. It does exactly the same before
performing a search.

The point is that you may only need certain fields to be searchable,
or certain key information out of your BO. In the case of encryption
it's a case of you only want to allow certain fields to be visible.

So walking through it, let's say you want to save an EmployeeEntry to
the space, you have a wrapper around a space service, that intercepts
the calls from the client, munging the entry before sending the entry
to the space.
If Crypto is on, the wrapper looks for EncryptedEmployeeEntry, that
may have only the persons internal Employee ID, and name, other things
like their address, NI or social sec number need to be secure, and get
encrypted as part of the original entry, it's still a public field of
the encrypted entry, but it's unreadable. To all intents and purposes
when the code calls write(EmployeeEntry) they don't see the Encryption
and don;t care, and it's the same with read/take.

Now this could be expanded to things like Bean Creation from Entries
to bridge that dissonance from what is effectively a row of data (the
Entry) to object (the Bean).

Now to a couple of other points. Apart from other reasons stated here,
one of the reasons that an Entry uses public fields, is that it makes
it easier in the back end for matching (indexing, etc), it also causes
less security policy headaches (esp since you don;t have to download
code - only the client does). Essentially a space implementation can
send a list of the fields, and a codebase reference and it's proxy in
the space client can do all the downloading of the code and
re-initialisation there, without requiring the space to download the
class definitions, you really don't need or want static initialisers
being run in the space, if you can get away with it.

Secondly, not all space implementations will store/restore private
fields. The easiest way is to store it as a byte[] or MarshalledObject
inside the  Entry, and just restore it, using only the key fields you
need to match on.

If you want to go with the Annotation type stuff, having a proxy
wrapper that accepts a JavaSpace and intercepts the calls to and from
the space may be a good way to go. Have a look at




2008/9/3 Wade Chandler <hwadechandler-apache@yahoo.com>:
> 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
> 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
>> > > 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
>> > > > objects a bit better...more protection even in logic you intend to
>> > > 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,
>> > > > every developer thinks he knows better.... ;o)
>> > > >
>> > > >
>> > >
>> > > Thinking one knows better versus flexibility and giving the ability to
>> > > 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
>> > > 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
>> > > 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
>> > > not usable. I just want to understand it correctly, but that link, per
>> > > understanding, states: only the public fields of any entry or a fields
>> > > fields are used for the template, and this means information must still
>> > > 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
>> > > 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?
>> > > 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
>> > > 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,
>> > > 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
>> > > 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
>> > > is always a good or bad thing.
>> > >
>> > > Thanks,
>> > >
>> > > Wade
>> > >

View raw message