Common Myths about SOA [Service Oriented Architecture]
-
So exactly what is SOA anyways? Is there something about it I should know? For example, I have a client app that talks to a bill acceptor and a touch panel via USB. I implemented those as services. There's other services in my app too? Does that make it SOA? Isn't anything that communicates between an application and a "service", via some defined interface using some defined protocol, an SOA? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
So exactly what is SOA anyways
Well SOA can be seen as the conceptualization of software as a service John Evdemon says its an Expose, Compose and Consume model here[^] is the keynote You might get some more answers here[^] and here[^]
Marc Clifton wrote:
Isn't anything that communicates between an application and a "service", via some defined interface using some defined protocol, an SOA?
IMHO i think a service oriented is more of a , when two or more services communicates or have the ability to communicate via standard protocols. An application - Service communication is also a part of SOA
Omit Needless Words - Strunk, William, Jr.
Web based Project Management
Universal DBA | Ajax Rating | ExplorerTree | Globalization in 20 minutes -
So exactly what is SOA anyways? Is there something about it I should know? For example, I have a client app that talks to a bill acceptor and a touch panel via USB. I implemented those as services. There's other services in my app too? Does that make it SOA? Isn't anything that communicates between an application and a "service", via some defined interface using some defined protocol, an SOA? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Isn't anything that communicates between an application and a "service", via some defined interface using some defined protocol, an SOA?
I would say no. I do say NO :) Generally SOA compliant implementations are those that expose business functions (not programming functions) as reusable entities. So a study of the core business processes is the first step. Then you define core required capabilities as services with the request and response messages needed to supply the business needs. Lastly you implement with your chosen solution based on those requirements.
-
:confused: :confused:
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
-
:confused: :confused:
Chris Meech I am Canadian. [heard in a local bar] Nobody likes jerks. [espeir] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
-
Myths about SOA (Service Oriented Architecture) 1. SOA is a technology 2. SOAs require Web Services 3. SOA is new and revolutionary 4. SOA ensures the alignment of IT and business 5. A SOA Reference Architecture reduces implementation risk 6. SOA requires a complete technology and business processes overhaul 7. SOA requires an army of consultants 8. We need to build a SOA Facts 1. SOA is a design philosophy independent of any product, technology or industry trend 2. SOAs may be realized via web services but using web services will not necessarily result in a SOA 3. EDI, CORBA and DCOM were conceptual examples of SO 4. SOA is not a methodology 5. SOAs are like snowflakes – no two are the same. 6. SOA should be incremental and built on your current investments 7. Tools, not consultants 8. SOA is a means, not an end Deliver a solution, not a SOA This was somewhat an eye opener to me , since in my company , there had been a lot of discussion of creating a service oriented archtecture * by John Evdemon Architect, Architecture Strategy Microsoft
Omit Needless Words - Strunk, William, Jr.
Web based Project Management
Universal DBA | Ajax Rating | ExplorerTree | Globalization in 20 minutesThis reminds me of a small article i once wrote trying to make my boss (one of many i had) understand that ?.R.P is not a program but a procedure and that implementing such a software to a production is devastating if you expect the lifeless bunch of ones and zeros to magically put order into the chaos. Anyway, my conclusion is that ignorant people (all non IT related managers included) will always think that any acronym with words that imply organization, planning, decision refer to magic tools that do the job by themselves whether they're software or not. I still get a kick of listenning people with grease in their hands and a wrench in their back pocket talk about software and Information organization philosophies. PS: I quit from that company shortly after ... and recently found that the '?.R.P' software was uninstalled !!!
-
Myths about SOA (Service Oriented Architecture) 1. SOA is a technology 2. SOAs require Web Services 3. SOA is new and revolutionary 4. SOA ensures the alignment of IT and business 5. A SOA Reference Architecture reduces implementation risk 6. SOA requires a complete technology and business processes overhaul 7. SOA requires an army of consultants 8. We need to build a SOA Facts 1. SOA is a design philosophy independent of any product, technology or industry trend 2. SOAs may be realized via web services but using web services will not necessarily result in a SOA 3. EDI, CORBA and DCOM were conceptual examples of SO 4. SOA is not a methodology 5. SOAs are like snowflakes – no two are the same. 6. SOA should be incremental and built on your current investments 7. Tools, not consultants 8. SOA is a means, not an end Deliver a solution, not a SOA This was somewhat an eye opener to me , since in my company , there had been a lot of discussion of creating a service oriented archtecture * by John Evdemon Architect, Architecture Strategy Microsoft
Omit Needless Words - Strunk, William, Jr.
Web based Project Management
Universal DBA | Ajax Rating | ExplorerTree | Globalization in 20 minutesOh yeah, And ask me how the bozos who [still] contend "tightly coupled statically bound classes is the only way to build efficient robust software" responded when we refactored their code into loosely coupled distributed and got a SERIOUS performance increase.
-
It's a lie. No SOA is special. None of them are beautiful or unique snowflakes. They are the same decaying organic matter as everything else.
-
i'm glad somebody got that :)
-
Marc Clifton wrote:
Isn't anything that communicates between an application and a "service", via some defined interface using some defined protocol, an SOA?
I would say no. I do say NO :) Generally SOA compliant implementations are those that expose business functions (not programming functions) as reusable entities. So a study of the core business processes is the first step. Then you define core required capabilities as services with the request and response messages needed to supply the business needs. Lastly you implement with your chosen solution based on those requirements.
Michael A. Barnhart wrote:
I do say NO
Thanks Michael. Your description of SOA is the most succinct and clearly understandable description that I've ever come across. I'm going to quote you in my blog simply so I can bookmark and share your description with other, if you don't mind. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Michael A. Barnhart wrote:
I do say NO
Thanks Michael. Your description of SOA is the most succinct and clearly understandable description that I've ever come across. I'm going to quote you in my blog simply so I can bookmark and share your description with other, if you don't mind. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
if you don't mind.
I would be honored. Thank you.