[Tfug] OT - WAS Re: Cyber War -oh noes | Now H1B Visa Rant

[Bexley Hall]

Hi, Cara,

--- On Sat, 1/10/09, cara <pinkgranite at gmail.com> wrote:

> My computer science career has led me to the study of
> Service-Oriented Architectures (SOA). On two of my jobs so
> far, programmers have been super threatened by any talk
> of SOA. "Oh my god, you autogenerate code?!" Programmers
> assume it's another big threat to their jobs. But, it is
> pretty obvious that these SOA projects need people with
> business smarts and if the people have technical skills,
> well, that's an added bonus. I'm still mystified why so
> many programmers are threatened by the increasing amount of
> autogenerated code for client-server components ...
> components using axis projects, xerces, castor, embedded 
> xdoclet ... whatever. In my opinion,
> getting the plumbing in place, could help you focus on the
> fine-grained problems.

I don't think the "appeal" of SOA is "automatic code generation".
Nor do I think the (imagined?) "threat" is "being replaced by
a machine/piece of code".  :>

The appeal of SOA is that it (tries to) decomposes *everything*
into co-operating (and, hopefully COOPERATING!  :> ) services
instead of traditional "libraries", etc.  This takes encapsulation
to its ultimate (?) extreme -- you throw data at a *real* black
box and get results *back* from it.  *Outside* the scope of your
application's execution domain.

It's a win (conceptually) because it makes the interface a true
"contract" and completely (theoretically) isolates the (ahem)
"client" from the "service" (i.e., the service could crash,
gobble up all the memory available to it, etc. and the client
remains intact -- by contrast, a library that misbehaves takes
your application down with it!)

It's also a potential performance win as it encourages
parallelism (if your services support asynchronous calls
and notifications).  Of course, the perfromance *hit*
is the overhead of the RPC/IPC in the first place
(the call into the RPC library, marshalling arguments,
moving up and down the protocol stack(s), transport delays,
etc. -- a considerable hit especially if client and service
are on different machines!)

The systems I am working on currently use this approach.  In my
world. EVERYTHING is a service.  Even the "math library".  This
lets me provide the same level of support to each aspect of the
application(s) and results in a more consistent design.  You
approach each part of the design as requests for services
instead of opting to "do some things for yourself".  (of course,
you could also exercise discipline and get these results with
a conventional approach but you are often tempted to "cheat"
and cut some corners "locally")

For example, you don't have five different pieces of code each
deciding how big a megabyte is (refering, by way of example, to
Windows' brain damage in which a *local* file's size is reported
differently than if viewed over a WWW/FTP connection to that same
machine!  Two different pieces of code each deciding how to
compute/display file sizes *differently*)

It's also a big win in that it naturally lends itself to
multiprocessing (loosely coupled) *and* fault tolerance
(if a service dies, another process/host can come online
to replace it "automatically").  E.g., in my case, I
*start* with three *heterogeneous* CPUs in the box and
this quickly increases as functionality is added.  Note
that I am free to use different processors, even different
OS's on those CPUs so long as I satisfy the contractual
obligations the services running *on* those individual
CPUs advertise!

But, I argue, *this* is the more threatening aspect of SOA.
Traditional sequential programming models no longer fit.
And, even folks who are used to working in multithreaded
environments -- even multiPROCESSING environments -- now
have to learn how to address a whole new class of potential
problems.  E.g., what if the RPC stalls/crashes?  What if
my code has to roll-back to a checkpoint to retry the
last operation (in the event of a server failure), etc.

If you're designing a traditional "distributed" and/or
client-server application, these transactions are usually
(relatively) few and quite well defined.  For a (lame)
example, an FTP session:  if the connection crashes or
stalls, you can always just restart the transaction and/or
*push* the error into the user's face and let *him* deal
with it.

Now, consider when *everything* (in my case -- or, "lots of
things" in the SOA case) has this level of uncertainty.
You do a call to get the time of day... and, you never know
if that call will complete or if the time-of-day service
will *die* in the middle of that!  Where do you want to roll
back your code to (argh!  dangling preposition!)?  I.e.,
you are facing this decision *all* the time, not just in a
few "big places" (like the FTP client/service)

Also, this extreme form of encapsulation means there are much
tighter constraints provided on the interfaces between those
services and their clients.  You can't just "wing it" and
hope the data in/out is more-or-less correct.  You have to
*know* what you are saying to each other and how you expect
to interpret each of those "messages".  So, your interface
documentation has to be impeccable.  Or, at the very least,
rigidly define all those circumstances that you will refuse
to work in (argh).

Lastly, it is much harder to test code in this sort of
environment *unless* you are just adding a (single) service
or designing a (single) client with all the required
services already in place.

> Along with communication being more important at times than
> technical skills, solving business problems seems more
> important than too much worry about shipping the techical
> app work to India. I would hope that American programmers,
> esp. those who grow and learn beyond just programming, will
> always have good jobs available. Yeah, our entire economy
> looks like a giant ponzi scheme ... maybe we will start 
> making useful things and actually have some business 
> problems to solve in 2009, eh?

If you want job security, become a plumber (hard to
outsource fixing pipes!) -- or, a MORTICIAN!  ;-)

--don