coarse-grained object and fine-grain object

[gk]

what is coarse-grained object and fine-grain object ? I find this
references in HTTPSession context.

(1)what are they ?
(2) why/how such peculiar varbiage ?

 

[Eric Sosman]

what is coarse-grained object and fine-grain object ? I find this
references in HTTPSession context.

(1)what are they ?

See this page for explanations:

http://www.google.com/search?q=coarse+grain+object

(2) why/how such peculiar varbiage ?

Just the prafarance of whoaver invanted the tarminology.

 

[Arved Sandstrom]

See this page for explanations:

http://www.google.com/search?q=coarse+grain+object


Just the prafarance of whoaver invanted the tarminology.

The Stan James comment in
http://www.coderanch.com/t/99845/patterns/Coarse-grained-fine-grained-objects
is how I usually see it. I got there by following your link.

AHS

 

[Lew]

There's absolutely nothing peculiar about the terminology. It is utterly
standard English and utterly common.

<http://en.wikipedia.org/wiki/Granularity>

Why? Because the term accurately describes the usage.

How? By typing "coarse-grained" or "fine-grained".

 

[gk]

The Stan James comment inhttp://www.coderanch.com/t/99845/patterns/Coarse-grained-fine-grained...
is how I usually see it. I got there by following your link.

Not yet clear. I found the following text from the link you posted.

It says...

Coarse grained is often better in distributed systems because calls
between distributed components can be expensive and time consuming.
Fine grained might be better in a very flexible system because clients
could invent new combinations of calls to do new tasks.


Not happy yet. Could you please provide EXAMPLE which could illustrate
the things better way.
I'm talking about coarse-grained *object* and fine-grain *object* in
HttpSession context. Looks like they are talking about something else.

 

[gk]

There's absolutely nothing peculiar about the terminology.  It is utterly
standard English and utterly common.

<http://en.wikipedia.org/wiki/Granularity>

Why?  Because the term accurately describes the usage.

Ok. I have gone through that link . I find these texts interesting...

it says ...

"...For example, a yard broken into inches has finer granularity than
a yard broken into feet.
The terms granularity, coarse, and fine are relative, used when
comparing systems or descriptions of systems. An example of
increasingly fine granularity: a list of nations in the United
Nations, a list of all states/provinces in those nations, a list of
all counties in those states, etc...."

OK...so far the definition looks nice.

However, we are talking about coarse-grained objects and fine-grained
objects in HttpSession context ?

SO, Can we map this way that fine-grained objects holds more detailed
information properties of the object ? and coarse-grained objects are
less informative ?

In other words if I write two classes as below

class USA1{
private String[] states

}


class USA2{
private String[] states
private String[] city
private String[] mayor

}


Is not objects of class USA2 are finer grained objects now ? I say so
because they are holding much detailed information than objects of
class USA1) ?

So, In my understanding objects of class USA2 are finer grained
objects relative to objects of class USA1.

Correct me if my understanding is wrong.

Thanks

 

[John B. Matthews]

Could you please provide EXAMPLE which could illustrate the things
better way. I'm talking about coarse-grained *object* and fine-grain
*object* in HttpSession context.

This article discusses granularity as it relates to the performance of
HTTPSession state persistence:

<http://www.theserverside.com/news/1364410/Under-the-Hood-of-J2EE-Clustering>

 

[Lew]

There's absolutely nothing peculiar about the terminology. It is utterly
standard English and utterly common.

<http://en.wikipedia.org/wiki/Granularity>

Why? Because the term accurately describes the usage.

Ok. I have gone through that link . I find these texts interesting...

it says ...

"...For example, a yard broken into inches has finer granularity than
a yard broken into feet.
The terms granularity, coarse, and fine are relative, used when
comparing systems or descriptions of systems. An example of
increasingly fine granularity: a list of nations in the United
Nations, a list of all states/provinces in those nations, a list of
all counties in those states, etc...."

OK...so far the definition looks nice.

However, we are talking about coarse-grained objects and fine-grained
objects in HttpSession context ?

SO, Can we map this way that fine-grained objects holds more detailed
information properties of the object ? and coarse-grained objects are
less informative ?

In other words if I write two classes as below

class USA1{
private String[] states

}


class USA2{
private String[] states
private String[] city
private String[] mayor

}


Is not objects of class USA2 are finer grained objects now ? I say so
because they are holding much detailed information than objects of
class USA1) ?

So, In my understanding objects of class USA2 are finer grained
objects relative to objects of class USA1.

Correct me if my understanding is wrong.

Eric and Arved already answered that question.

 

[gk]

This article discusses granularity as it relates to the performance of
HTTPSession state persistence:

<http://www.theserverside.com/news/1364410/Under-the-Hood-of-J2EE-Clus...>

Thanks. I have gone through that link . I did a quite R&D on this
stuff once upon a time in fact...Weblogic clustering and session
replication and load balancer.

But I could not get you . Which section is discussing about coars-
grained and fine-grained objects ? Is there any specific section you
are talking about ? could you please paste that relevant part if I'm
missing. I'd like to re-visit that part once again if I'm missed.

Thanks for your time.

 

[John B. Matthews]

But I could not get you. Which section is discussing about coars-
grained and fine-grained objects ? Is there any specific section you
are talking about? could you please paste that relevant part if I'm
missing. I'd like to re-visit that part once again if I'm missed.

Searching the page cited for the keyword "granularity", this
observation seemed relevant: "Some J2EE vendors ... provide [a]
fine-granularity distributed-object sharing mechanism to improve
cluster performance." The section entitled "Backup granularity"
elaborates further.

For the connection among the terms granular, granularity, fine- and
coarse-grained, see

<http://en.wiktionary.org/wiki/granular>

 

[gk]

But I could not get you. Which section is discussing about coars-
grained and fine-grained objects ? Is there any specific section you
are talking about? could you please paste that relevant part if I'm
missing. I'd like to re-visit that part once again if I'm missed.

Searching the page cited for the keyword "granularity", this
observation seemed relevant: "Some J2EE vendors ... provide [a]
fine-granularity distributed-object sharing mechanism to improve
cluster performance." The section entitled "Backup granularity"
elaborates further.

For the connection among the terms granular, granularity, fine- and
coarse-grained, see

<http://en.wiktionary.org/wiki/granular>

I did some R&D and have found my answer . Posting here if someone find
this useful later....this is very simple .

coarse-grained business objects, such as those that provide complex
behavior beyond simply getting and setting field values. These coarse-
grained objects typically have *dependent objects*. A *dependent
object* is an object that has no real domain meaning when not
associated with its coarse-grained parent.

coarse-grained methods are those that provide significant behavior
whereas fine-grained methods are typically low-level getters and
setters.

Example:
---------
an Order entity could take an OrderItem value object in an
addOrderItem method. That would be coarse-grained.


This is very nice. I was looking for this....we could close the
discussion now.
Thanks for the all the time.

 

[Lew]

Lew:

gk:
Yes. I read and posted the summary  after reading from there also.
However,that was not exactly what I wanted to know. Please see my
latest post , I found my answer and just posted the answer. You will
get a feel what I was asking.

Your summary substantially restates what they told you.

 

[Tom Anderson]

Your summary substantially restates what they told you.

That's what a summary is, isn't it?

I have to say, i've been following this thread, and i've realised i don't
have a very good grasp of what coarseness of grain means when applied to
objects. I can tell you what it means for locks - row vs table vs database
locks, for example, or device vs subsystem vs kernel - or access control,
but not really for objects.

I have a gut feeling for how it applies to distributed object systems,
which roughly boils down to whether you end up making lots of little
calls, or a few big ones. For example, a mortgage application processor
that looked like:

interface MortgageApplication {
void setProperty(Property house);
void addApplication(Applicant app);
void apply();
boolean hasBeenProcessed();
boolean accepted();
}

interface Property {
void setPostcode(Postcode pc);
void setValuation(int valuation);
}

// etc

Would be fine-grained. Whereas one which looked like:

interface MortgageApplicationProcessor {
boolean apply(Property house, List<Application> apps);
}

class Property implements Serializable [
}

// etc

Would be coarse-grained. But really, that's more about a sliding scale
between classical early-90s distributed-object style and a good old
fashioned RPC. I don't think the *objects* involved in either mode are
more fine-grained; after all, i have exactly the same set of types!

The problem with objects is that big ones are made of smaller ones. How
can you have anything other than fine-grained objects?

Perhaps coarseness of grain isn't about what the objects are, but what you
*do* with them - whether you lock one at a time, or hundreds; whether you
allow access to one at a time, or hundreds; whether you send one at a time
over the network, or hundreds. Maybe the objects are the ruler with which
you measure the grain.

tom

 

[markspace]

Perhaps coarseness of grain isn't about what the objects are, but what
you *do* with them - whether you lock one at a time, or hundreds;
whether you allow access to one at a time, or hundreds; whether you send
one at a time over the network, or hundreds. Maybe the objects are the
ruler with which you measure the grain.

My understanding (and I could be wrong about this) is the grain is about
designs and interfaces, not objects per se. Of course, objects
implement the design, so you do have objects eventually, but it's more
about the intent and the way objects are used.

Here's a coarse grained interface for an HTTP Request:

public interface HttpRequest {
OutputStream handleRequest( Request r )
throws HttpException;
}

That's it. There's really only one way to use this API. It does
everything you want, is almost impossible to configure incorrectly
(there's no configuration!) and high level code way up in the design
hierarchy will have no problem using this because there's only one way
to use it. No matter what happens, it's very unlikely that changes to
the implementation will affect the way that high level code uses this
interface because it is so simple. This is an advantage for interfaces
that are designed to be extended and then used by library code or
frameworks or applications like JEE containers, since it's easy to
predict what the user is going to do and handle all possibilities correctly.

Now fine grained APIs would be more like Swing, where you have a
configure this and a configure that for every conceivable option. And
sometimes Swing does interact weirdly with its sub-components because,
well, there's a lot of ways those components can be used and it's not
always clear how they do interact.

These ideas ignore the concept of network latency, which got brought up
earlier. Clearly, trying to run Swing objects remotely is likely to
involve far too much overhead, whereas HTTP is ubiquitous and works well
for many situations.

Just my two nickels.

 

[Tom Anderson]

My understanding (and I could be wrong about this) is the grain is about
designs and interfaces, not objects per se. Of course, objects
implement the design, so you do have objects eventually, but it's more
about the intent and the way objects are used.
Aha.

Here's a coarse grained interface for an HTTP Request:

public interface HttpRequest {
OutputStream handleRequest( Request r )
throws HttpException;
}

That's it.

Instinctively, i agree. And i think i can fit this into my theory: there
may be small objects in the request, but the operation we're looking at
here deals with them en bloc, taking a large aggregate of objects, the
Request, and producing a large output, in the form of a load of bytes.

There's really only one way to use this API. It does everything you
want, is almost impossible to configure incorrectly (there's no
configuration!) and high level code way up in the design hierarchy will
have no problem using this because there's only one way to use it. No
matter what happens, it's very unlikely that changes to the
implementation will affect the way that high level code uses this
interface because it is so simple. This is an advantage for interfaces
that are designed to be extended and then used by library code or
frameworks or applications like JEE containers, since it's easy to
predict what the user is going to do and handle all possibilities
correctly.

Now fine grained APIs would be more like Swing, where you have a configure
this and a configure that for every conceivable option. And sometimes Swing
does interact weirdly with its sub-components because, well, there's a lot of
ways those components can be used and it's not always clear how they do
interact.

That's very interesting. That's a whole angle i hadn't thought about.
Coarse grain as a kind of simplicity, which gives robustness.

tom