Slashdot Mirror
The Zen of SOA
Alex Roussekov writes "The book "Zen of SOA" by Tom Termini introduces an original view to the challenging world of SOA. He refers to the Zen philosophy as a "therapeutic device" helping SOA practitioners to get rid of prejudices and opinions in order to apply a clear mind-set based on real-life experiences and the application of technology knowledge. Each chapter of the book is prefaced by Zen Truism that the author suggests to "revisit, reflect on it longer, and see if you are able to establish a truth from the narrative, as well as from your own experiences." In fact, the book is about a SOA Blueprint outlining a methodology for building a successful SOA strategy. The target audience is C-level Executives, IT Managers and Enterprise Architects undertaking or intending to undertake adoption of SOA throughout their organizations. I strongly recommend the book to all SOA practitioners involved in implementation of SOA." Read below for the rest of Alexander's review.
The Zen of SOA
author
Tom Termini
pages
112
publisher
BlueDog Ltd (November 21, 2008)
rating
9/10
reviewer
Alexander Roussekov
ISBN
ISBN 978-0-615-24703-8
summary
provides a clear methodology to guide SOA implementations
The author's vision is based on extensive experience in the SOA arena and he elegantly leads and prepares the reader for the introduction of his SOA Blueprint approach. I personally enjoyed reflecting on the Zen conundrums which stimulated me to focus and understand the content.
In Chapter 1 the author explains SOA as both Business and Technical Concept and the main challenges it tackles from different stakeholder perspectives. He also emphasizes some misconceptions and technology myths about Web Services and ESB which are key enablers but do not represent a holistic view of SOA.
Chapter 2 elaborates on using the SOA Best Practices as a critical success factor for maximizing an organization's potential and improving performance. The author recommends an Incremental Approach to the SOA Implementation. This is supported by a comprehensive Case Study with the US Federal Trade Commission client.
Chapter 3 gives a technology view of SOA. The author covers a number of SOA technology components, their capabilities and positioning within the SOA technology stack including Portal, ESB, Service Registry/Repository, Business Rules and Enterprise Search Engines.
In Chapter 4 — the concept of "Future-Proof" is defined by the author and his team as "architecting to be highly available, reliable, and easy to manage."
The future-proofing is an inherent quality factor with technological and cultural aspects which need to be achieved throughout the overall SOA Lifecycle. The author suggests that "a pilot, or proof-of-concept, presented in advance of implementation and deployment, can convincingly demonstrate the ability of the architecture to validate the business intent".
Chapter 5 presents the author's rationale for an incremental approach to SOA implementation. The main point is that the contemporary business dynamic creates a myriad of competitive pressures which impose significant risks, whereas an incremental approach shields the business from the SOA implementation demands and helps to accommodate the changes and utilize the benefits.
Chapter 6 "The SOA Blueprint" is the essence of the book. It is a "set of guidelines for the practical business deployment of services using SOA methods in a moderately sized, somewhat complex organization". The author has used the OASIS' reference models for SOA as a foundation framework. The Blueprint is also consistent with well defined and recognized methodologies such as TOGAF and Zachman. For example, the Blueprint artifacts fit well in the taxonomy of the Zachman Architectural Framework and they can be mapped to corresponding activities in the TOGAF ADM.
Chapter 7 provides practical guidance and recommendations related to the context of the SOA Blueprint. The author puts the focus on Standardization, Business Customer Perspective of Services, Risk Mitigation Strategy as well as technical aspects such as Data Integration, Service Orchestration, Security and Metadata.
Finally, Chapter 8 offers a checklist with a number of items required for the customization of the SOA Blueprint. The author provides both item definitions and procedural guidance.
Tom Termini shares deep expertise and knowledge gained by hard work on numerous SOA projects for government and private sector clients. His examples of real business value achieved can be traced in the case studies described in the book. Each case study is related to a particular SOA "koan" and comes with the description of the business context, approach, solution and the business benefits obtained as a result.
The Zen of SOA is a concise, readable and very well illustrated book which provides practical advice, guidance and immediate impetus for development of SOA Implementation Strategy, Vision, Roadmap.
You can purchase The Zen of SOA from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The author's vision is based on extensive experience in the SOA arena and he elegantly leads and prepares the reader for the introduction of his SOA Blueprint approach. I personally enjoyed reflecting on the Zen conundrums which stimulated me to focus and understand the content.
In Chapter 1 the author explains SOA as both Business and Technical Concept and the main challenges it tackles from different stakeholder perspectives. He also emphasizes some misconceptions and technology myths about Web Services and ESB which are key enablers but do not represent a holistic view of SOA.
Chapter 2 elaborates on using the SOA Best Practices as a critical success factor for maximizing an organization's potential and improving performance. The author recommends an Incremental Approach to the SOA Implementation. This is supported by a comprehensive Case Study with the US Federal Trade Commission client.
Chapter 3 gives a technology view of SOA. The author covers a number of SOA technology components, their capabilities and positioning within the SOA technology stack including Portal, ESB, Service Registry/Repository, Business Rules and Enterprise Search Engines.
In Chapter 4 — the concept of "Future-Proof" is defined by the author and his team as "architecting to be highly available, reliable, and easy to manage."
The future-proofing is an inherent quality factor with technological and cultural aspects which need to be achieved throughout the overall SOA Lifecycle. The author suggests that "a pilot, or proof-of-concept, presented in advance of implementation and deployment, can convincingly demonstrate the ability of the architecture to validate the business intent".
Chapter 5 presents the author's rationale for an incremental approach to SOA implementation. The main point is that the contemporary business dynamic creates a myriad of competitive pressures which impose significant risks, whereas an incremental approach shields the business from the SOA implementation demands and helps to accommodate the changes and utilize the benefits.
Chapter 6 "The SOA Blueprint" is the essence of the book. It is a "set of guidelines for the practical business deployment of services using SOA methods in a moderately sized, somewhat complex organization". The author has used the OASIS' reference models for SOA as a foundation framework. The Blueprint is also consistent with well defined and recognized methodologies such as TOGAF and Zachman. For example, the Blueprint artifacts fit well in the taxonomy of the Zachman Architectural Framework and they can be mapped to corresponding activities in the TOGAF ADM.
Chapter 7 provides practical guidance and recommendations related to the context of the SOA Blueprint. The author puts the focus on Standardization, Business Customer Perspective of Services, Risk Mitigation Strategy as well as technical aspects such as Data Integration, Service Orchestration, Security and Metadata.
Finally, Chapter 8 offers a checklist with a number of items required for the customization of the SOA Blueprint. The author provides both item definitions and procedural guidance.
Tom Termini shares deep expertise and knowledge gained by hard work on numerous SOA projects for government and private sector clients. His examples of real business value achieved can be traced in the case studies described in the book. Each case study is related to a particular SOA "koan" and comes with the description of the business context, approach, solution and the business benefits obtained as a result.
The Zen of SOA is a concise, readable and very well illustrated book which provides practical advice, guidance and immediate impetus for development of SOA Implementation Strategy, Vision, Roadmap.
You can purchase The Zen of SOA from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You are the first post. You can do it.
(-1, Raw and Uncut is the only way to read)
Scientologists of America.
SOA = Service Oriented Architecture, and is one of the big crazes in the tech world right now.
http://en.wikipedia.org/wiki/Service-oriented_architecture
because the article didn't seem to help with that.
Does anyone know WTF SOA is?
If there is an acronym that you are going to use throughout your review, and it will be senseless without THEN DEFINE IT SOMEWHERE AT THE TOP!
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
One question that recently cropped up is whether SOA makes any sense if you are only connecting with a single data provider? The idea being that the architectural and maintenance costs don't make sense in this scenario since there is just too much over heard. Once you have a requirement connecting to multiple data providers then the effort pays out. Just curious to hear what /.ers have to say.
Jumpstart the tartan drive.
Chapter 6 "The SOA Blueprint" is the essence of the book. It is a "set of guidelines for the practical business deployment of services using SOA methods in a moderately sized, somewhat complex organization". The author has used the OASIS' reference models for SOA as a foundation framework. The Blueprint is also consistent with well defined and recognized methodologies such as TOGAF and Zachman. For example, the Blueprint artifacts fit well in the taxonomy of the Zachman Architectural Framework and they can be mapped to corresponding activities in the TOGAF ADM.
I know there is that google thingumbob and all, but it might behoove one to actually IDENTIFY AT LEAST THE MAIN ACROYNYM IN ONE'S POST. Shibbolething shibbolethers! I thougth I was reading a mass email from GE again. Gave me a damned headache, it did.
Yeah, I've been doing DNS changes all day today, so when I saw "The Zen of SOA", I got really excited.
Is that a bad sign?
"Waste not one watt!" - CZ
What is the weird fascination with "eastern" stuff among upper middle management? Virtually everything seems to have had a "zen" book written about it(because the "Zen of joining the rat race and being a driven type-A" is just so Zen.) and let's not even think about the number of besuited shmucks who think that reading a bunch of translated aphorisms about medieval Chinese warfar will make them a beast in the boardroom...
They're like Otaku with 401Ks.
Standardization...
Business Customer Perspective of Services...
Risk Mitigation Strategy...
Data Integration...
Service Orchestration...
Security and Metadata...BINGO!!!
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
Am I the only one that thought SOA as in Start of Authority...as in a book about zen philosophy in your named.conf. Don't get me wrong, I think people that run BIND need as much help as we can get :D
What is this crap and why should I care? I have more books than I can possibly read in a lifetime and I would wager 90% of them have more meat on their bones than this book. This reminds me of the 90's schlocksellers like the Tao of Pooh and Physics which ruined the topics of both pooh and physics for years to come. Pastafarianism of Perl, now that is a book I would read.
By the way remember this
Circa 1999
You:
Oh, did you read they discovered the top quark at Fermilab?
Random Girl in bar:
No, what is a quark?
You:
{QED QCD explanations in a bar at 1 am. You know in your undergrad heart of hearts this is what women want to hear}
Random Girl in bar:
Sounds like Taoism to me. Have you read the Tao of Physics, it is a great book. It tells about how the Chinese knew about all that stuff thousands of years ago.
You:
What? No they didn't, the standard model of physics is not something that can be partitioned up into dualities for the purposes of serving some crackpot theory.
30 minutes later at home alone waiting for your dial up modem to get online so you can troll for porn on your isp's NNTP servers. Remember when ISP's had their own NNTP servers?
An Education is the Font of All Liberty
SOA == Safe Operating Area
Don't toast those MOSFETs
Sheldon
I was reading the SOA wiki page wonder what the hell they were blabbering about. Then I got it.
It's the old Unix ideal of having many small tools each doing a small job well, and being able to easily tie those tools together into chains (or dare I say pipes) to achieve results.
Except now instead of it being simple, there are committees, XML schemas, and trade shows. This will help it's success by allowing high priced consultants to participate.
- For the complete works of Shakespeare: cat
ive noticed when i preface my technical explanation with the words 'service oriented architecture' i am immediately rewarded with funding approval.
the only zen in this is that neither of us understands entirely why this works.
Good people go to bed earlier.
You didn't tell me anything I couldn't skim in a bookstore. You've summarized each chapter into two sentences and said you recommend the book. Spend a little more time providing a critical evaluation - it would be helpful in getting people to decide whether to read the book.
Shoes for Industry. Shoes for the Dead.
The way jobs and the economy is going into the toilet nowadays, I think this would be a much more appropriate topic.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
I can't believe all the oh so great Know-It-Alls of Slashdot don't know what Microsoft's #1 push in business architecture is right now.
You should put define the acronym!
Pull your nose out of your OSS asses and at least pay attention to what the competition is doing.
Yeah mod me troll if you want.
Structure of Arrays
music - http://www.subatomicglue.com
Society of Actuaries
Heck, I thought it meant School of the Americas. Living in Columbus, GA (USA), we get these fruitloops down here every year protesting: http://www.soaw.org/
I didn't see a section devoted to governance of SOA because without a strong IT Department your "Zen of SOA" will quickly become the "Art of Interdepartment War" as each division of the company will try to control or influence the service if they they have to connect to it. A strong IT Department can push back on the other departments for the greater good of the company and force departments with rogue apps to eventually use the services.
They can easily be accessed both from server-side code and from client-side Javascript code, allowing you to do more complicated and responsive UIs in web browsers without a lot of need to explicitly re-code things for that approach.
is competition good, or is duplication of effort bad?
localhost. root.localhost. ( 1 3600 1200 3600000 86400 ) always worked just fine for me. Why complicate things by throwing an MP3 player into the mix?
The more I read, the more glad I was that the idiot poster never defined "SOA." I still don't know what it is, and I like it that way.
It's the Dutch acronym for an STD...
what's with this slapping zen on everything? What would the koan be : What is the spec before the meeting?
The real zen would be :
write simple, small things until the form is the function.
test in reality and in imagination, until both are one.
the SOA is the illusion. There is no SOA.
Bullshit bingo ahoy!!!
Don't you just love TLAs and marketese?
Nope, I still don't know what it is.
No sig today...
You wrote 5k worth of review on a book about SOA while successfully avoiding giving the reader any clues as to what SOA might be. You even managed to avoid the trap of letting him know what the letters "SOA" stand for. Bravo, sir. Truly a Zen review.
"Service Oriented Architecture"? Really? There is a buzzword for that now?
If I spent less time writing code and more time reading about the latest trends, I'd stop to realize that I've been developing SOA for years now without ever even realizing it.
Is this that moment when I'm supposed to recognize that I'm actually standing on some type of "cutting edge" because it all just sounds like another remix of disparate systems with a client that says "make it all work together"...
Reality is prettier inside my head...
School Of the Americas
As someone who thought SOA would be a good thing (meaning SOAP and XML) I can say without a doubt it sucks.
I am working on IHE (Integrating the Healthcare Enterprise) (Electronic medical records sharing) and I hate it. We are constantly dealing with the same stupid problems time and time again: XML mismatches.
Please, anyone developing for the cloud or SOA use REST aka WOA (Web oriented architecture).
The difference is simple: Rather than use SOAP for everything, you match it to the usual HTTP paradigms (GET, POST, PUT, DELETE, with sensible URLs and HTTP headers).
The elimination of XML eliminates so many issues you will not believe. The best that I can tell is XML is a document, this document can be versioned, while HTTP is a protocol. You therefore eliminate a layer that has to be maintained.
For instance, the PirateBay uses REST-like inerface:
GET http://thepiratebay/browse/603 gives you the
whereas with SOAP you'd need to agree on a transaction name, XML schema, paramters. Then someone will decide that you need to support base64 encoded file uploads and downloads, so that'll have to go in the schema too. With REST you just use the standard HTTP headers...
Friends don't let friends develop SOAP.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
If you have no slaves, then your zone's SOA serial number, refresh, retry, expire and minimum fields don't matter.
Edith Keeler Must Die
While I agree that it is a bit like the way that UNIX tools were built, SOA deals with heterogeneous and distributed environments that are built around business function. The largest misconception I run across about SOA is that it is a technical architecture built around webservices, so in that respect the UNIX comparison holds. However, any SOA approached in this manner will fail, 100%. SOA deals not just with technical processes but also business. In that respect, there is nothing that holds the promise that SOA currently does for a large, flexible system that allows business to decide what they want to do vs being constrained by their existing technical solutions.
... that SOA stood for Start Of Authority - as in the BIND name server configuration which inidcate that the config file is for a particular 'zone' (analogous to a domain name)
How disappointing to discover it something as loame as 'Service Oriented Architecture'. Tell me, do any of you have an architecture that is not 'Service Oriented', and if so, how do you use it, if your architecture isn't designed to accommodate/enable 'services' (i.e. functionality), what is its purpose.
Sun Tzu lived long before Zen (or Bhuddism, for that matter) was invented (discovered, if you prefer).
Sun Tzu's "Art of War" has much more in common with Niccolo Machiavelli's book of the same name than it does with Zen literature.
Machiavelli is more applicable to the current business environment than Sun Tzu, though. Or Clausewitz, or Musashi for that matter.
But to those of who design/build hardware, SOA stands for "Safe Operating Area":
http://en.wikipedia.org/wiki/Safe_operating_area
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
... this. At least that's how I've been interpreting it for years.
Have gnu, will travel.
Be sure to buy the best-selling follow-up books:
The Tao of NS
Meditations on MX
The Way of the A
..what SOA means, then you don't get the satisfaction of sneering at them condescendingly.
... tells me how to fix my motorcycle.
I prefer rogues to imbeciles because they sometimes take a rest.
Yeah, in the programming world we call these things "libraries". People have been preaching componentized programming for decades. Reuse code. Use libraries. Don't reinvent the wheel. Easy, right? Nope. The problem is that most people don't have the skill to design a usable component interface, be it a library or a COM component (which is what I assume this "new" SOA thing is). Then, everyone who uses it has to write a wrapper on top of it so it would fit into their design. Then you have whole components wrapping components wrapping components, each layer written to its author's perverted taste and sucking in some particular way that the next wrapper writer will attempt to fix. Yes, I'm looking at you, GNOME... Delegating component design is always a difficult choice and when you buy from the minimum bidder, you end up with crap. Crap that fouls up your entire application by association unless you wrap it tightly into a leak-proof envelope, which kinda defeats the purpose of reusing code in the first place. Be it libraries, COM, SOA, or whatever new shiny name people come up with, the original problem remains: only a good programmer produces good code. No amount of delegation will make an army of bad programmers produce good code.
(sample wisdom: study the office floorplan carefully. Identify the employees who sit in the corners of the room. Sack them first).
Damn, that's six potential business best-sellers straight away!
Eric Baird
SOA and SOS (System of Systems) seem one in the same thing to me when also paired up with UDDI.
COTS is pronounced exactly the same way as "kots": vomit.
What does this have to do with Sony Of America?
It's a poorly written article that doesn't bother to define what the heck it's talking about.
_____ There seems no plan because it is all plan. -- C.S. Lewis
The SOA experts are known to hand around the yahoo group http://tech.groups.yahoo.com/group/service-orientated-architecture
On occasions someone ask the question and than we have a storm http://tech.groups.yahoo.com/group/service-orientated-architecture/message/4892
On other occasions their moderator is bored and he provokes the storm himself http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10322
Recently they stopped trying to define it. They just discuss if it is dead or not http://tech.groups.yahoo.com/group/service-orientated-architecture/message/12368
Ah yet another reason for executives types to go on an expensive *planning* retreat to determine what they will do instead of actually having a plan.
Execute at week long business treat:
"I know what we will do, we will restructure our business around SOA! That along with massive layoffs will keep the company sharp! Excellent, with that pesky bit of business out of the way I can enjoy remaining week in my week long retreat"
Sends layoff memo to middle management minions instructing to them to cut 5% of staff then heads off to the bar to enjoy a well-earned drink.
I like what I've read so far, but you really can't have an intelligent discussion about SOA without getting into PTK, at which point you'd be completely negligent not to address NGE as well. The "Zen" focus of this book makes it ideal even to tie in PTK, because of the elegance and simplicity with which they relate to SOA. NGE clearly makes the application of PTK as it relates to SOA, an extremely valuable yet simple vector of the overall SOA realm. Despite the relative newness of NGE I think I can go out on a limb and say that SOA would not be where it is today if it weren't for the fusion of energies between PTK and NGE having propelled it there.
This reads like a very elaborate hoax.
It seems to be gibberish.
The emperor may not be wearing any clothes.
I'm sure this fad will go the way of:
ISO
"quality"
six-sigma
Total Quality Management
etc...
What really bugs me about this article is the same thing I often see in technology - throwing around an acronym as if EVERYONE should know what you are talking about and isn't savvy if they don't.
You should ALWAYS spell out the acronym in the beginning of an article and then use the acronym as much as you want afterward. It's common courtesy and helps communicate your point to those who may not be wise to it. Sheesh!
It also scales much better, and it does matter less where the services run. As far as I know, pipes don't do that. Pipes also don't know what goes through them, and do not have management interfaces. What you are talking about is much lower level stuff than SOA's, at least as far as I have read into it.
Absolutely right. Except now it's based around a higher business level abstraction, instead of at a single operating system level.
http://ars.userfriendly.org/cartoons/read.cgi?id=20050817&tid=1758478
I just typed POA into Wikipedia and found the Prison Officer's Association. It helps if you start with the right acronym.
Rather than use web services, I rather have an agreed upon flat file feed. If it's standardized and delimited, it works for me.
If you need an on demand query, use a secured connection to the database and run a standardized stored procedure.
But I don't really have much against XML. It's just a data format. You can make any data format ugly if you want.
Here I was hoping it was about Structures of Arrays vs. Arrays of Structures. Oh well.
Now, imagine you are in charge of the entire enterprise-wide information processing activity and architecture of a very large corporation. one which is global in scale, has possibly 100's of facilities, dozens of lines of business, and 10's of thousands of employees.
Some sort of ad-hoc approach where each little department basically does its thing and maybe if they're lucky they can share some data with (only a few) other 'compatible' departments in other places, and you have to have 500 bean counters writing reports all day just to get enough visibility into your own business operations to even ATTEMPT to manage this thing is not going to cut it. Not in the 21st Century.
So, you really HAVE to come at the whole problem from an enterprise wide perspective. That means applying system architectural principles to the whole enterprise. That means the data and services provided by IT infrastructure in any and all locations need to be able to dovetail together. This is where things like SoA come in. Using web services, federated naming, ITIL, and a highly systematic set of 'meta-processes' (like the kind of thing you find in TOGAF) is what makes the difference between you and the competition. Or more likely at least keeps you at par with the competition.
From a small/medium sized business perspective it might not seem like it makes a whole lot of sense, but in reality those 'extra layers' are abstractions and services which allow this large enterprise to be knit together. Done well it is a good thing!
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
"The book "Zen of [Wicca]" by [Author] introduces an original view to the challenging world of [Wicca]. He refers to the Zen philosophy as a "therapeutic device" helping [Wiccan] practitioners to get rid of prejudices and opinions in order to apply a clear mind-set based on real-life experiences and the application of technology knowledge. Each chapter of the book is prefaced by Zen Truism that the author suggests to "revisit, reflect on it longer, and see if you are able to establish a truth from the narrative, as well as from your own experiences." In fact, the book is about a [Wiccan] Blueprint outlining a methodology for building a successful [Wiccan] strategy. The target audience is [Wiccans] undertaking or intending to undertake adoption of [Wicca] throughout their organizations. I strongly recommend the book to all [Wiccan] practitioners involved in implementation of [Wicca].
The author's vision is based on extensive experience in the [Wiccan] arena and he elegantly leads and prepares the reader for the introduction of his [Wiccan] Blueprint approach. I personally enjoyed reflecting on the Zen conundrums which stimulated me to focus and understand the content."
Fixed that for you.
In Dutch, SOA is the abbreviation for an STD. That doesn't help in taking this book seriously :)
Submitters/editors, for the nth time, please expand acronyms at least once in the summary. Most of the acronym space has been used many times over. Thank you. (SOA vs. AOS is related to data management in programming. Directly relevant to Slashdot's core audience. Not to mention that Service Oriented Architecture is more of a buzzword than a useful technical term.)
SOA strikes me as a backwards step for an IT operation, and an excuse for not consolidating and sorting out your infrastructure.
The point of OO is that you can gain the benefits of polymorphism and inheritance, the ability to reuse code and build up a modular and flexible code library. That's why the world has moved away from procedural languages.
SOA is the idea that everything can be reduced to XML being fired backwards and forwards. If it's just access to data that's the issue, use a proper RDBMS. Use views, triggers and stored procedures if you want that data presented to different people in different ways. Use networked clients - after all, most of the time SOA is used within the enterprise, and most of the time enterprises control their software stacks and networks.
SOA - Sort Out your Architecture.
As functionality changes, so does the interface. If PirateBay changed its functionality (e.g. added an "add item" command) you'd need a new interface for that. It doesn't matter if you communicate via XML or REST, if PirateBay adds a new command and you want to support it, you're going to have to program the new interface.
And the fact that system A you bought demands a certain interface (e.g. "bill the user" interface), but system B you bought exposes a different interface (e.g. accountancy system has its own way of doing billing; firstly defining products in some configuration system, etc..): this problem is also independent of any XML vs REST vs anything else debate. This will always happen. You always need to integate systems produced independently. At least with XML you have XSLT to translate between one schema and the next.
With XML it's easy to define the character set i.e. send/recieve data in UTF-8. When talking about "global enterprises" etc, one needs more than ASCII. I feel confident in relying on XML parsers/generators to respect the UTF-8 header (in langauges which can support Unicode like Java and Perl, although I would not be confident about PHP!); I do not feel confident in getting some URL-based software to accept non-ASCII characters on the URL. What's the convention? These days UTF-8 then URL-encode. That's what I use but who knows if everyone else uses that. And it's just a convention as the character set is not stated anywhere in the URL.
SoA isn't about building standardized libraries really. It is about building large scale enterprise wide distributed architectures. Remote procedure calling is only one facet of SoA.
DCOM is an RPC mechanism. The problem with DCOM is that it was designed as a platform specific mechanism. Yes, in theory you could implement it on any platform, but it is really only suitable for use on Windows and, like CORBA, it is difficult to maintain and implement code using it.
SoA's preferred equivalent to DCOM/CORBA is SOAP and the associated WS-* standard profiles built on top of SOAP. These are much more portable, standardized, and flexible, but they do essentially the same thing, and it is only a small part of SoA.
SoA also includes things like service description (WSDL) and service directories (UDDI), standardized taxonomies for data (XSD etc), message routing, distributed transactions, asynchronous services, and business process description and implementation.
So, while I could build a distributed application using DCOM, CORBA, or JRMP, with SoA I can go far beyond just that. With a properly designed SoA architecture I can construct catalogs of services, identify service instances dynamically, and build applications on top of the entire enterprise wide set of services that are reliable and maintainable. These kinds of things were simply impossible with DCOM or other RPC standards because they simply didn't address all of the necessary functionality and were too cumbersome.
SoA may be a 'buzz word', but what it represents is very real and has very real uses and benefits.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Uh, huh, sure...
I guess you'd have to explain that to the big multinational financial firms that are our clients. They are a fantasy! lol.
Beyond that though, while I make the argument in terms of very large organizations, SoA can have benefits for much smaller organizations as well. Smaller organizations may often be able to get by with the old fashioned chewing gum and duct tape sort of IT of the past, but that doesn't mean they wouldn't be more profitable and more responsive if they had better visibility into their data, etc.
Beyond that most smaller organizations are components in the supply chains of or provide services to large corporations. Those large corporations are certainly interested in being able to integrate their suppliers into THEIR enterprise systems, and that means it is an advantage to understand SoA and build your systems in an SoA fashion.
Don't assume that the rest of the world is just like your little bit of it. And don't assume that just because you do things a certain way in your little bit that it is the only way or the best way.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Whatever abstraction you use ... the marketing guys' next project will break it.
You people on SlashDot never cease to amaze me. You consider yourselves the technical elite but most of you don't know what SOA is. You rabidly hate Microsoft, but most of you don't know shit about Windows or MS products beyond "teehee, Vista is the suxx0rs bekause it has teh DRM! teehee!".
Seriously. Let's say you don't "buy into" SOA. Wouldn't you at least know at a basic level what the fuck it is if you're even remotely involved in IT or especially software development?
And no - it's not just "haha, client server with a buzzword, teehee" any more than HTTP is "the web". Idiots.
Hasn't the author been reading the latest blogosphere entries?
It's the old Unix ideal of having many small tools each doing a small job well, and being able to easily tie those tools together into chains (or dare I say pipes) to achieve results.
That is actually BPM, not SOA. Though some present those 2 as SOA. SOA - non-duplication od data/operations.
this is the single greatest comment I have ever seen on slashdot
Please, the area has considerable merit - do not be fooled by the addition of technical jargon. This is a natural step in simplifying organisations by attempting to standardise and develop common processes/system functionality into services - such as front of house operations that provide/sell services to customers.
As for Zen, whatever, it may make a technical book more interesting, but it is rather typical of the IT side of life to seek some link Zen or martial arts - well the 80's did much for influencing us all.