Imar! I was just thinking about you! Hit a glitch of the 'way over my head' variety. But I should probably start a new thread for it. So it'll be on this forum called "Wrong Principal Object." Its CSLA related. Sure'ld appraciate any thoughts.

Bob

Hi Peter,

I had a chance to read the Fowler article and just have a couple of comments I’d like to share. Frameworks like CSLA built over the .NET framework provide several possible solutions to a few of the primary object design issues Fowler addresses.

His essential objection to the design of the types of distributed objects he discusses seems to be the:

"…essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

Not so when you implement serializable, CSLA style mobile objects. When you do, you end up with a very different picture. You end up with:

- a distribution strategy based on classes and

- mobile objects that fully encapsulate all their business logic and data access logic, and can be passed by value (via serialization) to a remote process, and do their work in that process

- which limits remote calls

- to the four standard CRUD methods implemented in an elegantly designed, course-grained data portal router object anchored (MarshalByRefObject) to either a local or application server process (as determined by a configuration file setting).

That’s a mouth full!

This logical architecture can support any physical architecture you like. Hope I can clarify it a little.

The fine-grained, “normally” designed business objects are used remotely via serialization. If a client wants to, say, update a mobile business object it is working with, and the course-grained data portal object is anchored in a remote process, when the client requests the update by calling the data portal Update method, the edited mobile object is serialized and passed by value to that process. The remote process now has a copy of the edited business object it can work with locally, calling properties and methods (like an Update method) of the “smart” business object with no performance overhead. The anchored object instructs the mobile business object to update itself by calling the business object’s Update method (all data access code is encapsulated in the business object). The updated object is then serialized and returned - again by value - to the client. The client now uses the new copy of the updated mobile object.

The only performance hit was in copying the object across the network - using binary transfer which is 30% faster than transferring, say, a DataSet. Doing this of course requires that both machines have the .NET assembly containing the objects code installed, which can be accomplished by a variety of deployment strategies, including .NET deployment strategies.

Fowler states that a “…fine-grained interface doesn’t work well when it’s remote.” This is true only when the fine-grained interface is called from another process. The situation changes completely when the interface is transferred to the remote process, and does its work in that process, which is what .NET technologies enable. A course-grained, anchored interface running in a process with access to the database server still exists (the data portal) for minimizing calls from the client, but now the anchored object and the mobile object run in the same process, and the anchored object can invoke the data access methods encapsulated by the mobile object.

Another problem Fowler mentions that is overcome by .NET serialization is:

“You usually can’t send the domain object itself, because it’s tied in a web of fine-grained local inter-object references.”

When a .NET object is marked as [Serializable()] it and any other object referenced by it is serialized into the byte stream that gets transferred to the remote process. Problem solved (except for certain issues surrounding event handlers which are easily resolved).

The whole remote facade and data transfer object issue is also resolved, because a DOT is no longer required. A copy of the smart business object itself (actually its serialized state data) is sent to the remote process.

Thanks again for the article reference. I hope some of this is intelligible. I'm just thinking through CSLA and distributed programming issues a lot recently, and writing helps a great deal.

Best,

Bob

Then again, Fowler's remarks apply to CSLA and .NET to a degree, as well. The anchored object in the remote process is still a course-grained interface required by the system, and is really the only object that is called remotely by the client. And, yes, I suppose it is a little awkward in certain respects. And the fine-grained interfaces of the business objects aren't "used" remotely, in the sense of being called by the client. Technically, they are "used" locally by the anchored object, and in a process that is remote only relative to the client process. So Fowler is perfectly correct when he says that a "…fine-grained interface doesn’t work well when it’s remote", if this is taken to mean: doesn’t work well when its called directly by the client, which is, I think, how it should be taken.

What .NET introduces is the concept of designing business objects with "normal", fine-grained interfaces that can do there work in a remote process without the client having to know about them "by reference", with all the performance overhead and network latency that arrangement would entail. Or something along those lines.

Bob

Last thought and I'll give it a rest.

In the final analysis, I'd have to say the three statements of Fowler's I was consideriing:

"…the essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

“…fine-grained interface doesn’t work well when it’s remote.”

can all be fairly asserted of CSLA. Even though the objects copied to the remote process may have a fine grained interface, the anchored remote object, the course-grained data portal, can only call the mobile object's create, read, update, and delete methods anyway, leaving one with the course-grained remote interface Fowler is describing.

Anyway, it has been helpful to think this stuff through out loud.

Bob

Bob,

I'm glad you followed up with yourself, LOL :). I was formulating questions as I read the first longer post, then you pretty much answered them.

Yes, I agree with you. To reiterate, as it helps me understand it as well: The problem is not when we use objects the way you describe, where an object is wired across and a single (possibly complex) operation happens in the remote process (this being essentially a coarse-grained interface). The problem is when we use the members of the fine-grained interface across the process boundaries. What we use will depend entirely on the class design. So, yes, if your objects naturally have a course-grained interface, they are much easier to move out-of-process (given other conditions). Fowler's main point though on that is that in-process classes should be fine-grained and thus not so portable.

This is a very interesting topic. I haven't really worked with remoting a whole lot, so I can't say much from experience. I've been dabbling with it but I'd like to get more proficient. This will certainly help.

-Peter

LOL. :) Just a little recursive posting.

One caveat. In finally asserting that CSLA fits Fowler's "local fine-grained object interface/remote coarse-grained object interface" model, I am in no way implying that CSLA is an "Errant Architecture" (Fowler's title). I actually have no idea how it, or frameworks like it, perform in a physically distributed environment. I've also only dabbled with this stuff, on a laptop using a local installation of IIS as a remoting host. I've made processes - not machines - swap objects. Can't say enough, though, about CSLA as a tool for learning the .NET "subsystems" (remoting, serialization, threading, reflection, security, COM+ serviced components). There's really no way to grasp how seamlessly these technologies support and collaborate with one another short of diving into a .NET distributed application framework and poking around.

Best,

Bob