Distributed Programming Boot Camp
by Michael Ernest
Five words on distributed programming; done right, it ain't easy. And
by "done right" I do not mean program code that compiles and runs;
rather, that the programmer understands what their code does, and
can apply their understanding to reading exception dumps correctly
and fixing problems and, more importantly, knowing when there's
nothing to fix.
So let's first talk about what is not, in the fullest sense of the
word, a distributed program. The term we often use for examples like
the one below is network programming. You'll see why very soon.
Applets are a good example of what we do not mean by distributed
programming. Applets download from an HTTP server to a browser. The
browser runs a local JVM to 'execute' the applet. On one hand, there
are context-sensitive hooks an applet can use to point to the web
server (getDocumentRoot()) and the enclosing browser (getParameter()).
On the other hand, none of these hooks point to an active process, just
files/directory locations or environment variables.
In a "true" distributed program, two or more processes interact; they
share data (and possibly code) in such a way as to "distribute" the
work that needs to be done. In this sense, applications that follow the
client-server model don't "truly" qualify, although the semantics are
often the same. If you really want to get snooty about it, you would
even say that web servers and browsers aren't "true" client-server
roles, but rather a "request-response" model -- in short, "network"
Imagine instead a program running on your machine that takes on a large
job that can be broken down into chunks; it's primary purpose is to
determine how long it will take to process the job, based on how many
compute servers are available at the time. It then submits the chunks
to each server, one at a time, requests updates on the chunk (or just
waits on the result), and provides regularly updated estimates of
completion time to the user. That's distributed work -- several
computers working together on a common task.
Or imagine a program that tracks company purchase requests. Many such
requests have to be checked against inventory, an approved vendor list,
purchase amount, and finally management approval. An application that
expedites such a request, known as a workflow application, must also
reduce the overall metadata for purchases down to a view that each
party (store manager, contract manager, purchase officer, division
vice-president) cares about. It must also ensure the request doesn't
fall through the cracks or sit in an indefinite holding pattern.
That's also distributed work, in that the overall product (an approved
request) relies on the individual work of several other processes.
You may surmise that neither of these examples needs a distributed
architecture. The job chunker could be written as a batch program, for
example, and email often suffices for workflow for tasks with many
responsible parties. Both of these are better understood and simpler
than a distributed solution, but need people to serve as the knowledge
base or "glue" between pieces. It's the need for better efficiency and
consistency that drives people to for a distributed approach --
business people, anyway. You geeks probably just think it would be
"cool." Seriously, though, for some companies only this kind of
architecture allows them to manage complex work acceptable and stay
What distributed programs benefit from is the asynchronous nature of
complex, interrelated work. Many related but separate activities run at
their own pace. To link them together, you need a rendezvous scheme
that doesn't force one activity to halt progress while waiting for
another activity to finish. The notion of de-coupling, a benefit of
good object-oriented design, is critical to distributed systems.
What distributed systems suffer from is the unreliability of networks.
By this term, we do *not* mean that networks fail anytime, all the
time. Of course they can fail, as can anything else. Unreliability in
this context is relative, in this case relative to the likelihood that
a CPU instruction will fail.
The system I'm on now, a SPARC Ultra 1 running at 167 MHz, runs a
potential 167 million cycles (instructions) per second, or about 600
billion possible instructions per day. How many of those fail,
affecting program operation? Don't know -- it's been quite a while
since I've had that happen. Compared to that, networks fail a lot, to
such a greater degree that we can't write distributed programs with the
same level of comfort that we write local, single-process programs.
So how does this manifest itself in the form of working code? In the
simplest terms, make a method in one program call a method in another
program. "But wait a minute," you OS-savvy types will say, "isn't that
kinda sorta what any process does when it talks to the kernel of our
operating system? Isn't our program a process that is communicating
with another process, the kernel?" Well, yeah, but kernels only emulate
asynchronous contact with user programs. And, if they were unreliable,
we wouldn't use them for any reason (in the Unix world, anyway. You may
feel differently, depending on your current Service Pack).
To work effectively together, two programs have to
a) be able to find each other and connect
b) talk to each other correctly
c) take network unreliability into account
Of course, you don't have to go through Uncle Mike's boring old lecture
on the Way All Things Are Done Right if you haven't got the time,
patience, or respect for an old man in his last few years of good
health. You can, if you like, dive right in with RMI tutorials, only
they won't tell you why you want distributed programs to plague you for
the rest of your life; they'll only show you how to invoke the plague.
Talk back to the Newsletter editor; if you'd like to hear more about
the foundations of distributed programs, I'll say more. If not, I'll go
back to flirting with Map all day long. Your call, readers!
If you're willing to listen but still want to do something, check out
this "live tutorial" that we started building in the Distributed Forum
some times ago. It's in need of more stuff, but I'm in need of more
read input to write. Let's help each other out, ok? Here's the link:
Thanks for reading!
Return to Top
Cindy's Segment - a Whimsical View of the World
When relatives move in
Surviving your sub-classes
Kids these days!! I tell you , they are spoiled rotten. Look around and you will see what I mean. You would think that those sub-classes would be happy that they have their very OWN classfile at last, where they can express themselves as they see fit. But NO. That is not enough for them. When they go out to build their Classfile Castle, not a one of them can get along without an umbilical cord back to their Dad. Well, OK - it is more like a tunnel back to Dad's Classfile Castle "just in case" they have to lean on Dad. And boy do they use that tunnel.
Static Stuff in the Castle
Check it out. When Junior goes to build his Classfile Castle, he makes sure that he builds in storage for all the Elite Static Variables that he wants, but then if someone asks Junior about one of Dad's Static Variables, Junior just runs down that tunnel and gets the value from Dad's Classfile Castle and presents it as though it were his own. Heck he will even update the value of Dad's static variable - mind you - the one that is sitting in Dad's Classfile Castle, just as though it were his own. So then when Dad goes to use his very own Static Variable, well . . . you KNOW there is going to be trouble.
Of course, every so often Junior gets gutsy and builds a Static Variable in his Castle with the same name as one of Dad's Static Variables. Since he never confessed that he was getting the value from Dad, as far as all his friends know, Junior's Static Variable is the only one there. He just hides the fact that Dad has one with the same name. Heck - he often isn't so respectful as to even use the same TYPE for his Static Variable. Anyway - you have to be on to his tricks and know to use the magic words (that would be to say "super dot" ) before you request a Static Variable from Junior, to insure that you are getting at Dad's Static Variables for sure. Then again, you could do what the rest of the world does, and just request Dad's Static Variables directly from Dad by using his Classfile name in front of the variable, like "Dad.var" or whatever.
When Junior is being especially difficult he will intentionally pull rank with his Static Variables. So if Dad has blueprints for his subjects object houses on the heap that call for a variable closet with a particular name, Junior may just decide that he has to use that EXACT name for his Static Variable. Well, that means that every single one of Junior's objects that might have inherited a small closet from his Dad, well, it gets its meager closet hidden, just so some Royal Variable can use that name. It is bad enough when his Castle Variables go around hiding Dad's Castle Variables, but to hide the variables of the poor of his kingdom, this is difficult to put up with.
Same thing for his behavior. If Junior's Classfile just does not know how to do something, even after he has looked through ALL of his Royal Static decrees, he just runs down that super tunnel and finds the Royal Static decree that his Dad is keeping in Dad's method area, and follows those instructions.
Yes, he often hides Dad's Static behaviors that he should have learned with his own childish Royal Static behaviors. Royally rotten, that's what he can be. At least he can't use his Royal Static behavior methods to hide any of the behaviors that his objects might learn from his Dad (from his Dad's regular method decrees), like he can with variable closets. If he tries that the Justice Department would come down on him big time at compile time . Houses are one thing - but education for the masses is quite another thing.
Of course the reverse is true also. Junior's regular methods are way too feeble to override or hide one of Dad's Royal Static Methods. It can be good to have the Justice Department working for YOU.
Building bigger and better
So what happens when it is time to build an instance of Junior's out in the "Heap" suburbs? Not only do kids these days feel that their Classfile Castle has to outdo Dad's and all his static stuff, but all of Junior's object houses have to outdo Dad's too. FIRST Junior gets the complete blueprint for how to build one of Dad's houses on the heap, complete with all of Dad's variable storage closets, neatly labeled as having come from Dad's blueprint, and then Junior has to make HIS subjects houses bigger and better by adding his own variable storage closets labeled as having come from Junior's blueprints.
All of this wouldn't be all that difficult if Junior always showed some creativity and used his OWN names for his objects variables. But no, once again sometimes Junior thinks he knows better than Dad. Out of rebellion he sometimes uses the exact same variable name that Dad did and builds HIS subject's variable closet right in front of the one that came from Dad's blueprint. Of course to us innocent guys looking in, that effectively hides the variable from Dad's blueprint from sight, and Junior likes to say that his subjects didn't inherit such a variable from Dad. They simply couldn't have, because you can't refer to it with it's simple name can you?. But believe me, BOTH variables' closets are still built in there. Let's say that again - Yes, each and every subjects object home has a variable closet for both the Dad::var and Junior::var with the same name!! What a waste of floor space! And now if you want to look into the closet that came from Dad's blueprint you have to get FIRM and say that you insist on seeing the "super.var"!
I have already mentioned how important education is here in JVMLand. But I have to let you know that Junior seems to have found a loophole. The problem is that behavior is not built in stone like object houses with their variables are. Behavior is something that you have to DECIDE to do. And simple objects are always swayed by the last one to give them a good sales pitch.
So even though Dad has laid out some very good regular method decrees, and even though left alone, the masses would benefit from inheriting this knowledge of how to behave, and even though Junior can not hide those methods with his own Royal Static methods, he CAN invent his own regular method decrees and give them the same method names. AND since Junior is the last one to talk to the objects of his kingdom, yep - you got it, they always decide to override good common sense - with Junior's version of how they should behave in case that method is called. You know - Junior is shaping up to be a heck of a politician.
Moving in on Dad
Now comes the difficult part. Sometimes Junior crowds in on Dad's space. Well, we have already described how he can mess with Dad's Royal Static Variables, and play all sorts of hide and seek games, but he also sometimes abuses the hospitality of Dad's friends.
You know about TYPEs don't you? You know how all variable closets are stamped with a type which directs them at the Classfile to get directions from?
That is great if all of the variables with Dad's Variable types are holding objects that are subjects of Dad. You know:
Dad dadCloset = new Dad();
Well, when that variable is asked for the value of any other variable that is in it's object, FIRST the variable has to run to the Classfile for his type, and get the OK to give out that information. Since Dad's Classfile knows all the variables in his objects, Dad hands out the OK to get a "Dad::var" from the object and all is good. It even seems a bit of a waste to have to go get that OK from Dad. The same thing for Junior. Junior hands out OKs for "Junior::var" information.
As long as everyone sticks to variables that are stamped with their own type, there is no confusion.
But, if Junior's subjects have a hidden Dad:X and also have a Junior::X they will give out whichever one that they get the OK for. If a Junior type is asking, then that type will go to Junior's Classfile and get the OK for a Junior::X. But when Junior butts in like:
Dad dadCloset = new Junior();
The type gets the OK from Dad for a Dad:X, (Junior's subjects HAVE a Dad::X built in and hiding behind the Junior:X), and the subject gives out the HIDDEN variable Dad::X. Go Dad!!! Suddenly it becomes clear why Dad enforces those rules.
Too bad it doesn't work that way with behavior. But like I already said, behavior is not built into the object houses, it is decided on at the last minute. If a Junior object is sitting in a Junior type and a method is requested, the type runs to the Classfile and finds the behavior for the method in Junior's Method area. If it can't find it there, it sneaks down that tunnel and gets the behavior from Dad's method area.
If the Junior object is sitting in a Dad type and a method is requested, the type goes to Dad's Classfile to get the OK for the method. If Dad HAS that method, he will give out the OK, and THEN Junior will convince the subject to use HIS version instead. Unless of course you use the magic words "super dot" when calling the method.
Well, at least if one of Junior's subjects can not GET the OK for a method from Dad's Classfile, Junior can't use his own methods, even if he has them, until he gets his butt into his own darn variable type.
Did I mention that that tunnel is one way. Too bad Dad can't sneak down and swipe whatever behaviors he wants to learn from Junior.
Dare to discipline
Well, you can see that Junior could turn out to be a problem. It takes a firm hand to guide him properly. So there are some things that you just MUST make sure that you enforce.
Do NOT let them get at your private Stuff! Your privates are your own business and that is that!
You must be Firm and INSIST that they use the return type that you have used if they insist on overriding your methods. It really is not so bad if their behavior strays from the path, as long as they return correctly.
NO WAY that they should be able to throw extra exceptions in their methods after they have overridden Dad's, and expect Dad to pick up the tab! Just say NO.
If you just be sure to add these elements of discipline to your relationship with the kids, and try to understand them - well, you will just LOVE them - in spite of their wayward ways.
Copyright ? 2002. Cindy Glass. All rights reserved.
Graphics by Pauline McNamara and Stephanie Grasson
Next month - "Stereotyping and pidgeon -holing" - or "When is an Interface too tight"
Return to Top
Movin' them doggies on the Cattle
It's where you come to learn Java, and just like the cattle drivers of the
old west, you're expected to pull your weight along the way.
Drive forum is where the drivers get together to complain, uh rather,
discuss their assignments and encourage each other. Thanks to the enthusiastic
initiative of Johannes
de Jong, you can keep track of your progress on the drive with the Assignment Log. If you're tough enough to get through the nitpicking,
you'll see your name on the Graduation Log.
Gettin' them doggies...
It's been a relatively quiet month over at the Cattle Drive forum, but we
know (fer sure) that the drivers and nitpickers are all busy behind the
scenes working on their assignments and pickin' those nits. The list of
active drivers shows around 18 drivers lately, the majority kickin' up dust in
the OOP, Servlets and JDBC corrals. Those doggies are the tough 'uns, so
writin' em up and cleaning out the nits takes a bit longer.
And a shiny spur goes to...
Hold on to yer spurs a minute there... Haven't had any Cattle Drivers movin' on to graduate
this month - y'all better get a move on thar, we got some right nice spurs
all polished up and ready for the next lucky graduates.
Back from being out on the range...
A trio of rugged riders made it back to the drive: Josue Cedeno, Greg
Harris and Joe McGuire came moseyin' back to get at it agin'.
Welcome back to the hardy ones!
Two advanced Cattle Drivers, Daniel Olsen and Jason Adam,
have been achin' to get their sorry butts out of their JDBC saddles and
onto a comfy barstool in the saloon. Jason and Daniel have just been joined by Lance Finney. Way to go Lance! Hang in there, guys, rumors at the watering hole say that you're not far off.
Nitpicking is hard work too...
We know they're workin' reeeeeally hard, after all we've seen what those assignments look like once the nitpickers have combed through 'em. Hats off to Marilyn deQueiroz and Jason
Adam for their dedication and patience with the pesky vermin that always manage to make their way into those assignments.
Tips for the Trail
Variable names: it may sound trivial, but if you're wantin' your code to get the stamp of approval from the nitpickers, take a minute to give those variables nice, full-size, meaningful names. Yup, those nitpickers are pretty darn serious about the three most important things about Cattle Drive code: readability, readability and readability!
Written by Jason
Adam and Pauline
Return to Top
Book Review of the Month
Chosen by Cindy Glass and Madhav Lakkapragada
Agile Software Programming
by Alistair Cockburn
Like so many blind men around an elephant, we each have views of
Software Development based on our own limited experiences. In this one of two
anchors to the Agile Software Development Series, Alistair Cockburn presents his
view: Software Development is a cooperative game.
From this perspective, Cockburn builds a vocabulary that we can use to identify
with and learn from experiences and observations that he and other practitioners
of agile methodologies such as XP, Crystal, Adaptive, Scrum, and FDD have shared
throughout their careers. He shares these experiences and his thoughts about
them and how they support his view.
Written for experienced developers and managers, the book makes you reflect on
what should be valued for any software development effort to be successful.
Still, less experienced developers would do well to read it if only to gain the
vocabulary. The vocabulary will help you see things that you would have
otherwise not noticed. And if you don?t notice something, you can?t learn from
The appendices are particularly interesting. One discusses the Agile Manifesto
and the values it sets forth. Cockburn adds his own reflections on those values.
Another presents three articles that have influenced Cockburn?s view and
includes, of all things, the writings of a 17th-century samurai.
This book has me convinced that Cockburn?s view comes very close to describing
the true nature of the huge and complex beast that is Software Development. This
book should prove useful for many years to come.
(Junilu Lacar - Bartender, March 2002)
More info at Amazon.com ||
More info at Amazon.co.uk
Return to Top
For more information on JavaRanch's Giveaways see Book Promotion Page.
Return to Top
JavaRanch to remain JavaRanch!
Sun will be "...structuring a free licensing agreement with the site..." for "...managing the brand/trademark in a way that is positive and open - in the spirit of the technology itself...."
I for one salute Sun's actions on this topic. This truly shows the dedication and spirit that I have come to expect from the Javatm community and from the Sun itself!
Thank You Sun!!!!
JavaRanch has added a new forum to better assist people in their hunt for information.
As always JavaRanch is dedicated to providing you with the best source of information on Java Programming and Engineering.
by Carl Trusiak
Return to Top
Managing Editor: Carl Trusiak
Comments or suggestions for JavaRanch's NewsLetter can be sent to the NewsLetter Staff
For advertising opportunities contact NewsLetter Advertising Staff