river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Landis" <sean.lan...@gmail.com>
Subject Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.
Date Mon, 01 Sep 2008 16:40:04 GMT
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.

> So, yes, forcing transfer objects to require public fields ensures those objects will
only be used as purely transparent objects as they can introduce system instability if used
in any other manner, and also can not be used to detemine how the values are set or if set
consistently with state patterns of the object as encapsulation is not possible with required
public fields, but to what specific end as there are many possible use cases.

If protecting the client of a JavaSpace is your concern, i.e.,
preventing them from sending invalid state in a TO, then simply wrap
access with an abstraction layer. I would recommend this in any case.
First, Jini/JavaSpaces is difficult to swallow 'raw' and needs a
framework around it. This is not a failing of the technology but
merely a fallout of where Jini sits in the abstraction continuum. It
is closer to Socket programming than application programming and a
framework will help the app developer immensely. Additionally, anytime
object transformation is necessary, tools should be used (think
factory or builder pattern).

> 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.

> So, the need for developer choice and flexibility is still necessary from my perspective.
In other words, it makes no sense to force a development model based on the notion of a better
way of doing something when in many cases this wouldn't really be the best model.

And this is why Gregg extended JS the way he did. I don't disagree
with your argument. I am just saying that passing beans from VM to VM
is not as helpful as one might think and thus the complaints about
transfer objects are diminished.

> 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

> 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.

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


View raw message