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 03:23:15 GMT
----- Original Message ----

> From: Sean Landis <sean.landis@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Monday, September 1, 2008 12:40:04 PM
> Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development issues
and ideas.
> Hi Wade,
> See in-line.
> >> So I don't think the transparency of JavaSpace entries is a problem
> >> from an OO design perspective.
> >>
> >
> > Yes, but this argument makes a lot of assumptions. Most importantly, it 
> assumes that all objects belong to the client.
> I don't have this assumption. The situation I was describing happened
> to be related to a service object. More fundamentally, there is
> usually mismatch in how a client and service desire to view a certain
> object. I see this all the time in non-Jini applications.
> > In many circumstances domain specific objects need to perform checks on types 
> of data, and be used in multiple situations yet remain solely in their domain; 
> think back end processing systems and clustering.
> This is exactly what I am talking about. I don't want back end objects
> escaping to the client for many reasons. I've mentioned a few. Here
> are more. The BO is a DB backed entity; what will the client do with
> that? Another is business logic. I don't even want that visible to
> clients for security reasons. Another is class loading independence. I
> don't want my clients to have to load my service object model just to
> access a silly field in a BO. Jini enables me to do that but I don't
> necessarily want to just because I can.

If we are in the "back end" there should be no reason for any thing to escape to a client.
I am simply talking about systems where multiple systems supporting something like a cluster
or even different code in similar server side or back end domains have the same transfer and
business objects within that back end or server side logic which just access the same server
side data in different manners, and do this over and over in logic. So, basically this similar
yet different use of the same data by different objects and services in back end systems are
locked in to running over and over the same boiler plate code which pulls out the transfer
data into business objects.


> > Along with the use of transfer data comes the burden of having code move the 
> values into other objects for use in a particular domain:
> >
> > 1) Take domain object
> > 2) Create transfer object
> > 3) Move data from domain to transfer
> > 4) Save transfer through steps which most probably require moving transfer 
> again to domain
> >
> > and
> >
> > 1) Pull transfer object
> > 2) Create domain object
> > 3) Move data from transfer to domain
> > 4) Use domain
> >
> Yep. Our staff bemoan this ALL THE TIME. There is no good answer in sight.
> > Where as were the specification to simply use the beans specification the 
> domain object could be the transfer object in the cases it makes sense, and it 
> could be used as needed versus being forced down a perceived path of best 
> practice.
> And this is absolutely NOT A GOOD ANSWER. It is easy but fraught with
> problems in environments where performance, scalability, security,
> etc, are critical.

I don't see where this becomes an issue when dealing with similar systems which should never
be sending these other objects to any other logic on the client. So, using a bean versus pure
public fields really has nothing to do with a comparison of performance, scalability, security,
or anything else. The main difference is that those property methods can handle different
things and you can kill two birds with one stone in the situations it makes sense. Methods
are not serialized the state is, so I don't see a valid argument for one over the other except
for the beans give you more freedom as a developer when needed and can simply do more.

> > In many cases pure transfer objects are themselves forcing a lot of overhead 
> from code complexity to extra classes and logic which must be executed when in 
> reality they are not necessary until they are actually required.
> I disagree. You should hide any complexity and you actually can gain
> efficiency by sending a TO vs. the entire bean. Marshaling cost is
> more expensive than the copying cost. Plus with certain technologies -
> such as JAXB, you can avoid the copy step and marshal only a subset.
> The TO is XML, if you will. You can apply the same concept for other
> representations.

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.

> > It is the same philosophy that logic doesn't need to be refactored or 
> performance tuned to the Nth degree until it is necessary as attempting to do so 
> before it is known to be necessary can introduce just as many issues as having 
> done nothing at all.
> I don't think it is the same. The choice of entries for JavaSpaces, as
> I understand the history, was one of convenience as much as
> performance. It is unfortunate it has been left this way for so long,
> but again, I don't see it as such a big issue. One can arrange
> transfer of objects in all sorts of ways through this mechanism as
> Gregg demonstrated.


> Maybe the problem is one of perspective. I do not view JavaSpaces as a
> communication mechanism like RMI or CORBA. I think it is more similar
> to JMS although it's pattern matching makes it much more useful for
> loosely coupled collaboration.
> With this view in mind, if one just wants point to point communication
> with coupled endpoints, JavaSpaces is a poor solution as that is not
> its purpose. But JavaSpaces is great for collaborative computing.

Yes, collaboration between the different server side or backend systems used as a shared memory
is what I'm talking about. I'm just saying certain business objects with limited scope, state
management through properties versus public fields, can help reduce a bunch of boiler plate
code which doesn't seem to give any extra benefit in many cases.

> You might look at other Space solutions that do support sending beans
> if you feel it is necessary. They are out there. I used to use IBM
> TSpaces. Like JMS, there are challenges in sending beans across the
> wire.

Sure, I just think it would make more sense for this to be supported at the specification
level is the point I'm making. Flexibility to get the best design for a given task is very
important, and this has always been an issue with JEE which is why EE5 and 6 are doing some
of the things they are doing now, and everything needs less in the way of adoption, and certainly
this seems to be the case with Jini. Not saying Jini isn't workable, just saying that it could
use any leg up it can get in adoption and ease of use, and flexibility to do things as needed
when needed helps with that. Which would help your folks not have to *always* bemoan the TO
BO mismatch in the situations it makes sense.

Anyways, the important part to keep in mind is there is always room for intepretation as to
why this or that should not happen on the surface of an idea when speaking in generalizations
and without direct examples to support the given arguments, and we could go round and round
as to why this or that high level generalisation is good bad or indifferent, but there are
perfectly good uses of different methods in many different situations. Flexibility of the
technologies to be used helps with those different situations and necessaties as they arise,
and help the technologies themselves.


View raw message