Chris Craddock wrote:
Unlurking for a moment...
[snip]
On Thu, Jul 9, 2009 at 6:50 AM, Steve Comstock <[email protected]>wrote:
Timothy Sipples wrote:
I'm also observing more and more organizations finally figuring out that
dis-aggregating existing architectures is exactly the wrong direction to
head. The management costs and service quality dimunition, in particular,
are just not worth it, and they're getting more costly every year. I find
I'm getting more and more enthusiastic about not making things more
complicated than they need to be, as a general rule -- indeed, to seek
opportunities for simplification. And more and more people seem to be
coming to the same conclusions nowadays.
You seem to be presuppose some innate rightness of having all of the work in
one big box, when in fact, there are huge benefits in scalability and
managability from breaking up and distributing work. That's pretty much the
point of sysplex after all. You're also presupposing that there are inherent
service and quality impacts when you disaggregate. That may often be true in
practice, but there's no underlying law of nature that makes it so. To-wit,
the previous point about sysplex.
Rather than adopting a "complexity is bad" position, it would be more apt to
paraphrase Einstein... "A system (theory) should be as simple as possible,
but no simpler." Sysplex is more complex than single instances of plain old
MVS, but the benefits far outweigh the complexity. The same is true of
distributed systems. Not all complexity is bad.
Well, yes. That's why I have trouble getting excited about Web
Services. Talk about complicated.
Write the service code
Describe in WSDL
Register in some repository
When someone looks for the service, negotiate a price
Once accepted, let the requestor run the service
Bill me later
For goodness' sake: write your own subroutine and be done with it.
well in fairness, only the first two are actually requirements for a web
service. The first one you have to do no matter whether you're doing web
services or CICS/Cobol so I don't see it being relevant to complexity and
the WSDL-related tasks are largely done by tools, not by humans.
Publishing web service endpoints in a registry is a good thing to do because
it allows for run-time binding which makes the applications a lot easier
(not harder) to manage and makes them more resilient and flexible. You can
move application parts around without changing any code or parmlib-like
configuration data.
I don't know of anyone doing the "negotiate a price/bill me later" thing
with web services but I guess in theory it could be done. So boiling the
meat off the bones here, the only real extra work is the (tool-assisted)
WSDL processing and service registry stuff. I will admit they can look a bit
intimidating but, in return you get flexibility that you can't even dream
about if you "just write your own subroutine and be done with it".
If what you're trying to accomplish looks like a simple subroutine call,
then it probably is simple enough to be one. OTOH if you're trying to juggle
data from multiple places to buy stuff online, pay for it, arrange shipping
etc. then it would be the height of insanity to just write your own. Those
tools have not become pervasive because they are complex and hard to use.
They are pervasive because they are powerful and useful.
Well, that brings up the old "build or buy" conundrum. But either
case, if you have a tool to do multiple pieces, whether you purchased
it or built it yourself, I still don't see a case for setting it
up as a Web Service. That was what I was driving at before. You
don't need to set up WSDL and register the service, then use UDDI
to "discover" the service. You have it, just use it.
I don't think it's "the height of insanity to just write your own";
depending on the service, it might be a strategic way to get some
competitive advantage (provide additional features and services
that only your company offers). (Of course, if you decide to build
your own, it might end up being inferior to the one your competitors
use, then you're up a creek. An excellent reason to hire competent
people and keep them updated with training. Ahem.)
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
