RE: Application design & architecture

>From this point of view, as opposed to building my own atomic clock, I
can just connect to a government time server and use NTP to get the
time, and that is an example of SOA?

-----Original Message-----
From: midrange-l-bounces+cpayne=thecrowngrp.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+cpayne=thecrowngrp.com@xxxxxxxxxxxx] On
Behalf Of Chris Payne
Sent: Tuesday, May 09, 2006 1:43 PM
To: Midrange Systems Technical Discussion
Subject: RE: Application design & architecture

LOL and now it finally makes sense to me, SOA is the division of labor,
except for computer programs instead of individuals or business. If I am
understanding correctly, it would also be perfectly reasonable to call
it modularization, except that what people usually mean when they say
modularizing is splitting up a program or group of programs that will
run within a given organization, and "SOA" can cross organizational
boundaries.   

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, May 09, 2006 1:28 PM
To: Midrange Systems Technical Discussion
Subject: RE: Application design & architecture


> Let's say I have some sort of problem, and I say to myself "Gosh I
wish
> I had some SOA" what sort of problem do I have? These "Best Practices"
> are the best practices for what exactly? It sounds sort of like what
is
> being described is either the internet, or EDI.

(I really don't know that I want to stick my neck out and get involved
in 
this rather nasty thread, but...)

To me, SOA is more of a way of thinking than anything else.  Let's step 
outside the world of computer programming for a minute.

When I'm hungry, I can pick up a telephone and order food.  An expert at

preparing that food cooks it for me and has it delivered to me.  I pay 
him.  They have provided me with a service.

When I plug up the pipes in my house (possibly as a result of the food, 
heh) I call a plumber.  He comes to my house and fixes my pipes.  I pay 
him, he has provided me with a service.

When I'm not feeling well, I call a doctor.  I go to his office and he 
provides me with medicines or whatever sort of gear is needed to make me

feel well.  The doctor has provided me with a service.

That's what SOA is about -- an architecture where we use "services" as
our 
paradigm for programming.

If I am writing an order entry program, what do I need to do?  I need to

ask a user to key in the items and quantities that he wants to order. 
Then I have to find out the prices for those items. And I have to find
out 
if I have enough stock, or can make enough stock, to fill the order.
Then 
I have to figure out when/how it'll be shipped and how much that costs. 
Then I have to get payment from the customer.  And deposit that payment 
somehow into my bank account.

Rather than write one big monolithic program that does all of these 
things, in an SOA paradigm, I might do this:

a) I might have my own service that looks up the prices for items.  This

service might be a procedure in a service program.  Or it might be a 
stored procedure called through SQL.  Or it might be a web service.  SOA

isn't specific about which technology you use -- just that it's using
the 
"service" paradigm.

b) I might have my stock stored at a separate warehousing facility -- 
possibly one that's run by a 3rd party.  So I'd use one of their
services 
to see what I have in stock.  This might be a web service that I call
and 
pass an iten number as input, and get the amoutn of stock as output.  Or

it might be an FTP process where I upload the item numbers in a file,
then 
call a program to process that file, then get back another file with the

results.  The point is that it's a service -- I somehow run a program on

that warehouser's computer, somehow pass it input, and it somehow 
provides output.  It provides me with a service.

c) When it's time to ship it, I might call a program running on United 
Parcel Service's computer to find out when it'll be shipped, 
time-in-transit, and the charge for shipping.

All of these different pieces, some internal to my company, some
external 
are services that I can call.  When I'm developing an application, I
don't 
have to write every component myself, I can call existing ones.

That's all SOA is.  It's just an architecture where software is written
as 
services that can be "consumed" (or "utilized") by other software.

It's not a new idea.  It's nothing particularly revolutionary.  They've 
just created a term for it -- instead of "modularization", which seems
to 
mean something different to each person, or "encapsulation" which is 
close, but not precisely the same, they came up with the term "SOA".

But, it's certainly not new.  Indeed, I've come across quite a few S/36 
programs that were designed in a service-oriented approach, broken into 
lots of little re-usable OCL procedures. (Of course, I've also come
across 
100 times as much S/36 code that wasn't service oriented, but anyway...)

In a *good* SOA implementation, those services are also "loosely
coupled" 
meaning that you can effortlessly change from one service provider to 
another.  For example, if I decided to switch from UPS to FedEx, all I'd

have to do is provide a different Internet location (URL) that points to

FedEx's service instead of UPS's, and my program would use FedEx for 
shipment without changing any code.   But I don't think this loose 
coupling is actually part of the definition of SOA.

But, SOA is more of a general idea than it is anything else.  It's not 
really anything specific, and that makes it very hard to explain.  Plus,

since everyone uses Web Services as an example, it's hard to separate
the 
sample implementation from what SOA really is.  Hopefully I've done a 
decent job of that in this message.

By the way, if you ever have a chance to talk to Trevor about SOA at 
COMMON, make sure you pronounce it "SOW-UHH".  He hates it when you 
pronounce it "Ess-Oh-Ayy".  (Yes, I'm kidding.)