RE: Application design & architecture -- MIDRANGE-L

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 inthis rather nasty thread, but...)

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

When I'm hungry, I can pick up a telephone and order food. An expert atpreparing that food cooks it for me and has it delivered to me. I payhim. 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 payhim, he has provided me with a service.

When I'm not feeling well, I call a doctor. I go to his office and heprovides me with medicines or whatever sort of gear is needed to make mefeel well. The doctor has provided me with a service.

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

If I am writing an order entry program, what do I need to do? I need toask 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 outif I have enough stock, or can make enough stock, to fill the order. ThenI 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 paymentsomehow into my bank account.

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

a) I might have my own service that looks up the prices for items. Thisservice might be a procedure in a service program. Or it might be astored procedure called through SQL. Or it might be a web service. SOAisn'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 servicesto see what I have in stock. This might be a web service that I call andpass an iten number as input, and get the amoutn of stock as output. Orit might be an FTP process where I upload the item numbers in a file, thencall a program to process that file, then get back another file with theresults. The point is that it's a service -- I somehow run a program onthat warehouser's computer, somehow pass it input, and it somehowprovides output. It provides me with a service.

c) When it's time to ship it, I might call a program running on UnitedParcel 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 externalare services that I can call. When I'm developing an application, I don'thave to write every component myself, I can call existing ones.

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

It's not a new idea. It's nothing particularly revolutionary. They'vejust created a term for it -- instead of "modularization", which seems tomean something different to each person, or "encapsulation" which isclose, 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/36programs that were designed in a service-oriented approach, broken intolots of little re-usable OCL procedures. (Of course, I've also come across100 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 toanother. For example, if I decided to switch from UPS to FedEx, all I'dhave to do is provide a different Internet location (URL) that points toFedEx's service instead of UPS's, and my program would use FedEx forshipment without changing any code. But I don't think this loosecoupling is actually part of the definition of SOA.

But, SOA is more of a general idea than it is anything else. It's notreally anything specific, and that makes it very hard to explain. Plus,since everyone uses Web Services as an example, it's hard to separate thesample implementation from what SOA really is. Hopefully I've done adecent job of that in this message.

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