----- Original Message ---- > From: Sean Landis <[EMAIL PROTECTED]> > To: [email protected] > 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. > Sure. > 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. Wade
