coarse-grained object and fine-grain object
gk
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.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Arved Sandstrom
> On 9/6/2010 8:30 AM, gk wrote:
>> 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.
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
--
Before a man speaks it is always safe to assume that he is a fool.
After he speaks, it is seldom necessary to assume it. -- H.L. Mencken
Lew
gk wrote:
>>> what is coarse-grained object and fine-grain object ? I find this
>>> references in HTTPSession context.
>>>
>>> (1)what are they ?
Eric Sosman wrote:
>> See this page for explanations:
>>
>> http://www.google.com/search?q=coarse+grain+object
gk wrote:
>>> (2) why/how such peculiar varbiage ?
Eric Sosman wrote:
>> Just the prafarance of whoaver invanted the tarminology.
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".
--
Lew
gk
> Eric Sosman wrote:
> > On 9/6/2010 8:30 AM, gk wrote:
> >> 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.
>
> 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
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
<e2d4ce43-e0b2-48aa...@b4g2000pra.googlegroups.com>,
gk <src...@gmail.com> wrote:
> 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>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lew
Eric and Arved already answered that question.
--
Lew
gk
Did you read what I posted ? That is not the answer to what I posted .
I posted two class USA1 and class USA2 and asked whether can we say
those are instances of coars-grained *objects* or fine-grained
*objects*. I made those because there were no examples . I have gone
through what Eric and Arvid posted links and put down the summary
also.
an Example would be better to get this concept.
gk
> In article
> <e2d4ce43-e0b2-48aa-ad4f-e054ec051...@b4g2000pra.googlegroups.com>,
>
> gk <src...@gmail.com> wrote:
> > 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:
>
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
<620963d5-44f2-4f55...@h40g2000pro.googlegroups.com>,
gk <src...@gmail.com> wrote:
> On Sep 7, 5:16 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <e2d4ce43-e0b2-48aa-ad4f-e054ec051...@b4g2000pra.googlegroups.com>,
> >
> > gk <src...@gmail.com> wrote:
> > > 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>
[...]
> 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>
Lew
>> Eric and Arved already answered that question.
>
gk wrote:
> Did you read what I posted ? That is not the answer to what I posted .
>
Yes, I did, O Snarky One. Did you read what they posted?
--
Lew
gk
> In article
>
> gk <src...@gmail.com> wrote:
> > On Sep 7, 5:16 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > > In article
> > > <e2d4ce43-e0b2-48aa-ad4f-e054ec051...@b4g2000pra.googlegroups.com>,
>
> > > gk <src...@gmail.com> wrote:
> > > > 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:
>
> [...]
>
> > 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.
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.
Regards
Lew
>>>> Eric and Arved already answered that question.
>
gk wrote:
>>> Did you read what I posted ? That is not the answer to what I posted .
>
Lew:
>> Yes, I did, O Snarky One. Did you read what they posted?
>
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.
--
Lew
Tom Anderson
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
--
As far as I can tell it's a mixture of stream-of-consciousness writing,
random mathematical formulae, and half-crazed references to sex.
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
> On 9/7/2010 3:58 PM, Tom Anderson wrote:
>
>> 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.
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
--
If you're going to print crazy, ridiculous things, you might as well
make them extra crazy. -- Mark Rein