Talk:Service-oriented architecture

From Wikipedia, the free encyclopedia

News This page has been cited as a source by a media organization. The citation is in:

While I believe that there are vast differing beliefs on what SOA is, can we all agree to refrain from making direct programming or software-related definitions. SOA has nothing to do with software or programming in the least. The 'A' in SOA stands for architecture. An architecture is a blueprint. In this case a blueprint for a system. -- JP Morgenthal


What are the issues encountered whilst transforming an existing 3-tier architecture to SOA?

Some info on who developed SOA would be good. I cannot seem to find this anywhere on the web. How old is the concept and when did the term come into existence. Was it a concept used to describe web services or did web services get developed to implement this architecture idea.

I believe that this is something worth tackling, but I believe, because SOA is an ARCHITECTURE, it may be a difficult proposition. I have started an SOA History Page on my own site to put down my ideas so I won't clutter up these pages while I am working out the concepts. I have established a simple Wiki to act as a sandbox for my thoughts on this subject. Feel free to jump over and add YOUR thoughts to the pages.

Contents

[edit] Introduction to SOA

Lead in this article starts of with a understanding that every visitor to this article is from the programing community.I would suggest a section as 'Introduction to SOA' which starts narrating in lay man terms and then takes to the core of the topic.I started this section(version dated 04:27, 25 July 2007 Techwonder ) with the intention that subsequent additions will shape the 'Introduction...'.Techwonder

I actually feel that the introduction is overly definite about what SOA is. In my opinion a better introduction would be more more like that currently used for Web 2.0 which is up-front about the term being heavily overloaded. The present SOA introduction contains a number of very specific statements about how services should function that are debatable but, even if conceded, should not be in an introduction. TwistedFool 20:48, 16

September 2007 (UTC)

I find it strange that part of SOA's description in the article says it should incorporate "Clear and unambiguous description language" - under "Requirements for SOA", yet the introduction is anything but clear and unambiguous. It may be that the system is too ambiguous in its nature for it to be briefly defined (or described, if a definition is inappropriate). This is not a criticism, simply a notice--that I came to this page to discover what the IT people are on about SOA, and I can't make head or tails of the introduction. It might be worth working on a very tight, succinct description--perhaps with examples--so that the uninitiated can grasp the basics of the concept before being plunged into the requirements etc...

Regards, Zach Beauvais Talk! 10:06, 17 October 2007 (UTC)

[edit] History of SOA

Is there an article for the history of SOA somewhere? SOA has been around now for years, since early 80's, the usual practice in the software industry being to take an old idea, and see how it worked in the present. The software behemoths of the 80's, DEC, IBM, HP, tried this before, but it only recently became fashionable when web service came along, and people realised that the internet cloud could be used to link trading companies and drive business efficiences. scope_creep 19:47, 23 January 2007 (UTC)

[edit] Pronunciation

SOA is also pronounced so-ah. However I don't know IPA to add this, very common, alternative.

[edit] Conflicting definitions and bloated content

It is inappropriate for every organization involved with SOA to publish their definitions and glossary terms on this article. We need to ensure that the content remains concise and does not conflict, especially with the official article definition. Some of the definitions and glossary-related content has therefore been removed and replaced with links to the appropriate external pages. Let's please all make an effort to not use this page as a means of self-promotion.

The opening definition also sounds like marketing-speak: "business-driven approach", "integrating the business", "horizontal business processes" and most of all "SOA helps businesses innovate by ensuring that IT systems can adapt quickly, easily and economically to support rapidly changing business needs" tell me nothing about SOA. It just tells me that proponents are making the same claims for SOA as have been made for every other methodology, architecture or development process in the history of commercial software. ChrisFCarroll

I agree. There is some hype in the definition. SOA is not always business driven, and can yield benefits within the technology domain. I think SOA is actually meaningless from a business point of view - which should focus on prioritized outcomes (e.g reduced cost, faster time to market, improved compliance, end-to-end processes, integration with business partners etc). Selling SOA to "the business" is like trying to sell a road standard to a car buyer - the only things drivers are interested is that their car complies to the relevant standards, how well it drives, its capacity etc.
I have restored text from an earlier definition and edited the introduction. The business architecture benefits are under a sub heading. Peter Campbell Talk! 02:23, 1 July 2006 (UTC)
The source of the text:
"Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps users build composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes" is [1]. Not really appropriate for the Wikipedia definition. Peter Campbell Talk! 13:27, 2 July 2006 (UTC)
Gavin Collins says: I disagree that the description of SOA at the beginning of the article is actually a definition at all. I would suggest that the statement "service-oriented architecture ... is an architecture that relies on service-orientation as its fundamental design principle" is actually a Truisim, since the statement uses the circular reasoning. I would propose a more correct definition to state that "service-orientated architecture is the name given to a Enterprise resource planning system that uses Web Services to provide integrated computer software and hardware to store data and retrieve information used in business applications." However, I cannot substantiate this definition from an external source at this time. Gavin Collins 14:42, 2 April 2007 (UTC)
It would be useful to explain what 'services' mean in this context, i.e. as self-contained network-accessible modules performing some sort of defined functionality, which are combined together to build a system, although there's probably a better-worded definition around somewhere. There's no reason SOA needs to be limited to ERP, and SOA does not need to be based on Web Services. --Michig 15:56, 5 April 2007 (UTC)
I also believe that SOA does not need to use any particular bit of alphabet soup, such as WSDL, XML, Java or any web services to qualify as SOA. In fact, I think it very likely that ESP-derived protocols will replace many of the current protocols used to implement SOA because XML and a lot of the web services are just ridiculously bloated for moving large amounts of data - even over the backplane of a single mainframe computer. It is worth noting that the basis of IBMs offering, was at lest in the beginning, was NOT a web-based protocol at all, but their MQ data-switch product. Ditto for the Java data switches. With 25 years of DP background to inform my observations, I see the current implementations of SOA as absurdly bloated, overly intellectualized constructs, devised by people who think that the more cycles something sucks the more clever they are proved to be.(Of course, the exact opposite is true) These constructs will never scale well, were not designed to, and no amount of brute force will make them economical enough to run an entire enterprise on. In time, the rigors of performance attendant with ESP will likely drive the standards it comes to be based on ahead of those of SOA as the two worlds are destined to collide/merge. Given this, it would be better to define SOA in a more generic way and leave out the current obsession with web standards as being critical. One could certainly put together a SOA system without using any web standards (perhaps in a MSFT .NET environment...uuugh) and that would invalidate the current definition. At its core, SOA is, on a larger scale, what modular code is to an application. The orchestration process is the same process (although much more loosely bound) a linker goes through at compile time when one builds a static executable by culling functions out of a library. --Solidpoint 19:35, 3 August 2007 (UTC)
Thinking about it, what is critical to SOA is the use of metadata to enable data and logic to be congealed dynamically to form what we had previously thought of as applications.--Solidpoint 19:41, 3 August 2007 (UTC)
This page might be useful in tidying up the definition.--Michig 15:59, 5 April 2007 (UTC)

The text says: "SOA is usually based on Web services standards (e.g., using SOAP or REST) that have gained broad industry acceptance." The definition of the term "Web service" in Wikipedia cites the W3C definition, which builds a strong relationship to the SOAP protocol, and not to REST. Therefore, I would wipe out the brackets in this particular sentence. Of course, we could also modify the Wikipedia definition to include REST, which is a legitimate web service standard as well, or we could modify the statement so that REST is not implied to be a web service while including it as an implementation alternative. SOAP and REST are both popular vehicles for implementing SOA.

REST is not, strictly speaking, a Web Services standard. It is a style of delivering 'web services'.--Michig 15:56, 5 April 2007 (UTC)

[edit] Original Wiki

On the original wiki there is an SOA page with references to its many facets, such as "enterprise service bus". C2 Wiki on SOA MicrosoftSlave is the person who is most interested in the topic over there.

[edit] More Collaboration?

I am a new wikipedia user interested in improving this page. Read a bit on this subject but without practical experience. I am looking for wikipedians who would like to revisit this topic again at end 2005. Is Breedlov (a coauthor of this page) still about? I went to his wiki and its SOA page is severely defaced. You can leave me a message here. Dlwl 04:49, 26 September 2005 (UTC) দ

[edit] Page move

This page was just moved from Service-oriented architecture to Service Oriented Architecture, without explanation or discussion. As I feel the former title (with hyphen) is grammatically correct, and is the way the term is used in the article; and because the latter title does not comply with Wikipedia's naming conventions, I have moved it back. If any disagree with me, please leave a comment here. Thanks! — Knowledge Seeker দ 03:27, 22 Jun 2005 (UTC)

[edit] .NET?

Shouldn't there be discussion of .NET somewhere in here? Friday 17:50, 15 July 2005 (UTC)

I don't think soo. .NET should be (and is) referenced from within the article. But since SOA's are supposed to be platform independent, none of the specific technologies should be discussed. Ziroby 22:26, 15 December 2005 (UTC)

[edit] Commercial link

The "Best Practices" link seems a bit commercial...

I thought the whole article reads like an infomercial. At least Wikipedia hasn't degenerated to the level of PBS where sponsors get "commercials" thanking them for their support...

[edit] TXMLS?

What does this acronym stand for? I never heard of it. Can't find anything sensible about it on google related to SOA. Did someone add this as a joke? The user who inserted this, introduced other errors in the text. I'll remove it. If anyone has a different opinion, please give me a note.

--MauriceKA 13:57, 29 January 2006 (UTC)

maybe Tax XML ?

(Tax XML, developing under the auspices of the Organization for the Advancement of Structured Information Standards (OASIS), provides standard definitions and schemas that governments, businesses and individuals can use when creating, sending, receiving, maintaining, storing and retrieving data that's relevant to the life cycle of tax information.)

Maybe the 'T' stands for temporary. You know, the kind of mock up language you use to build a presentation to win a contract without being able to actually implement the application...

[edit] SOA Methodology?

I noticed that in the overview for the article it is mentioned that "SOA provides a methodology and framework for documenting enterprise capabilities and can support integration and consolidation activities."

I'm curious what "methodolody" is provided by SOA? SOA is rather a perspective and arguably an approach to Software Architecture, but not a methodology.

Thoughts? Jame 09:06, 22 February 2006 (UTC)

I agree. I see SOA not even as an architecture... I see it more as an implementation of distributed processing. If I have an application that only relies on one service, and that service provides all of the necessary information for my application to work, how is this different (other than the connection method) from Client Server type apps? Can I not program my consumer with Object Oriented methods? I don't get it.

I don't think this statement is correct either - it should be removed. SOMA is an example of a methodology supporting SOA, but SOA does not specify either a methodology or framework for documenting enterprise capabilities. However, SOA does enable/support integration and consolidation activities. Peter C Talk! 12:02, 4 April 2006 (UTC)

The best characterization of SOA I have seen was in a white paper comparing it to Object Oriented design. In OOD, data and processing are encapsulated in the object. In SOA, processing is provided as a service and the client sends data to the service and receives the results. SOA certainly implies nothing about methodology.

The article as written, provides a perspective which is slanted towards software, when in fact SOA is a business platform, first and foremost. It's true that SOA does have a core architecture component, how else would it be developed and implemented, but its primary function, which not mentioned in the article at all is to drive business effeciency. There is a whole series of skills associated with SOA, that is outside code development. Implementing SOA using .net or WCF or Websphere, is right at the bottom of that stack. The article needs to be comprehensivly updated and rewritten. scope_creep 19:31, 23 January 2007 (UTC)

[edit] SOA as a noun?

SOA is used as a noun in several places, yet the article states that is an architectural style rather than a product or an actual entity. This is contradictory. I think this grammar should be changed, e.g to "SOA-compliant systems" or "SOA style applications" or such like. Peter C Talk! 12:17, 5 April 2006 (UTC)

[edit] SOE

Edits from an IP address have included mention of "SOE" under the "SOA and network management architecture" heading. What does SOE refer to? I have removed it pending clarification. Peter C Talk! 12:31, 11 April 2006 (UTC)

[edit] Is SOA only a software architecture?

The SOA Article describes SOA specifically as a software architecture, which is not how we think of it. The SOA architectural style can be applied to any system of collaborating entities - including the design of a business or supply chain without any software considerations. It is, in fact, good management to separate concerns for agility in the business and then have the software reflect this design. SOA is this design pattern.

The application of SOA to software is fine and should be enumerated, but we would suggest making the definition of SOA independent of software (as do the definitions of both OMG and Oasis).


CBC 19:20, 5 May 2006 (UTC)Corycasanave

I agree Corycasanave, I've just completed my fist SOA project, the code implementation is at the bottom of the stack. scope_creep 19:34, 23 January 2007 (UTC)

I've been reading a lot about SOA in terms of airline business. Can we have a subsection on generic SOA as a principle, rather than as a specific application? Jddriessen (talk) 22:25, 30 January 2008 (UTC)
Just saw the detail at the top. Looks like it's being sorted out Jddriessen (talk) 22:27, 30 January 2008 (UTC)

[edit] Service-oriented design and development

This section contains the following statements that are not referenced, don't make much sense, and have poor grammar. It has had recent edits, but it needs a thorough re-edit or content removed.

The modelling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SODA. The SOA functions as much as a software development framework as it does as a delivery framework. In order for a firm to incorporate SOA in their environment successfully, the services that firm render must be identified. These services become candidates of the integral service components. Development of services and systems that use/reuse service requires a long-term commitment by both business sponsors and I.T. staff. As a new paradigm, the service model must be employed in all phases of planning to execution.
Services that are available at the business can be used to orchestrate the business process. Having loosely coupled and fine grained services help this by creating the processes on the fly. This alleviates the need or redoing the service each time process changes. Therefore it is required to differentiate the processes and the services that business perform.

--Peter Campbell Talk! 11:17, 4 September 2006 (UTC)

I have removed the above content and the following link from the article pending clarification and some keen editing.

* [[Z++|Abstract Programming]] [http://www.zhmicro.com/Service.pdf Delivery of C++ Services(PDF)]

--Peter Campbell 13:20, 17 September 2006 (UTC)

[edit] Different maturity models ?

The maturity model listed under external links points to a 3-level model from soablueprint.com. There is a more detailed and I believe more complete SOA maturity model from Sonic Software. Olivier101 16:36, 22 November 2006 (UTC)


[edit] Articles

I have tried to tidy up the articles and other external links, but the list is still much too long - or too short, given that I could easily produce another list of relevant articles ten times as long as this one. I think we need the external sites, reference models and blogs, but keep the articles only if they specifically substantiate some claim in the article itself. --RichardVeryard 14:41, 7 December 2006 (UTC)

[edit] Removed unreferenced content from "Why SOA?" section

The following content does not read like an encyclopedia and has no citations:

If SOA is successfully adopted and implemented in an organization, the net result it will leave behind is, information systems, whichever platform or technology it might have been developed on, will have the capability to interact with each other. This sparks the following benefits: information asset reuse, less or no redundancy in information across the organization, no tight coupling among systems either within the organization or even across partnering organization. Key benefits to the business: IT will not be a hindrance to making strategic moves in market which often results in breaking or making new relationships, expansion; doing more with less - reuse provides option to optimize IT investments; no need for that separate projects and applications that do nothing but synchronize, mirror data from one system to another system just becase the systems involved cannot interact directly.
Benefits are the ones every organizations look for, but pitfalls are the ones drown the ship. Execution matters in order to realize the true benefits from SOA.

This needs a rigororous edit prior to inclusion.

Peter Campbell 01:38, 22 December 2006 (UTC)

[edit] This entry needs some plain english

I understand and respect that this is a fairly "vertical" topic, but I find it very difficult to wrap my head around what is going on here. Is it possible for someone to simplify the introduction just a bit and provide a more real-world example of an SOA?

If it were written in plain English it would be more obvious what a load of baloney it is. —Preceding unsigned comment added by 69.244.5.30 (talk) 20:59, 25 September 2007 (UTC)

--


You're not going to find it: SOA is buzzword engineering of a high order, invented by a clerisy of self appointed "experts" for the sole purpose of enriching those experts because they are the only people who truly understand it. At the core of SOA is a good idea: that network services should provide independent and easily parseable interfaces that allow more complex applications to be built up without any concern for the underlying implementation of those services. It's such a good idea that it gets invented roughly once every five years. On top of this simple idea the SOA definers have added so many unnecessary layers of legalistic specification that it's almost impossibel to develop a compliant application without years of Ninja-level training.

The Web 2.0/Mashup entry is the closest you're going to get to a real world implementation, but Web 2.0 is most definitely not SOA as far as this article is concerned. It follows the SOA pattern in the broadest sense, but uses none of the technology.

--Jim68000 16:17, 16 January 2007 (UTC)

If this is true, shouldn't this be what the wikipedia article states? In more neutral language of course, but still. We can't just give up and say that since others cloud the issues, wikipedia has to follow. Do you know of any sources that talk about the buzzwordness of SOA? W 12:33, 15 May 2007 (UTC)

[edit] Removing bogus reference

I am removing the "reference" "According to www.xml.com, ..." (added 24.Nov.2006 13:12) because it is not a quotable reference; it links to a portal where the topic the editor had in mind can be found nowhere, even if the notion being discussed ("stateful service") is submitted to the search function. For proper quoting of some opinion or article (maybe a blog?), a working reference is appropriate, e.g. a link leading to the specific article or an instruction how to find it. A link to a portal site is really not sufficient to find the piece of information intended to be quoted.

Italic textBold text[[Media:#REDIRECT [[<s><sup><sub>oioijojoj;oji</sub></sup></s>]]]]

[edit] Removed External Link

A member of our marketing staff unfamiliar with Wikipedia mistook it for a means of promoting one of our seminars delivered by SOA author Thomas Erl. At Mr. Erl's request the advertisement was promptly removed. We apologize for introducing inappropriate content. - University of British Columbia

[edit] Criticisms of SOA

Most of this section is not a criticism of SOA as such. A service-oriented architecture need not include XML and need not be stateless, thus however valid the criticism of those technologies may be it cannot be levelled at SOA itself.

The paragraph about evolving standards may be valid, but it's a bit nebulous. In large part it seems to be saying "if you don't manage your project well it will be at risk", which is hardly news.

The final two points (despised buzzword and reinvention of existing good practice) are fair though. —The preceding unsigned comment was added by 80.47.174.182 (talk) 22:47, 7 March 2007 (UTC).

[edit] SOA Vendors?

Should this page list major "SOA vendors" even if it is an architectural term? —The preceding unsigned comment was added by Jopo (talk • contribs) 19:38, 25 April 2007 (UTC).

[edit] Added some beef

I hope this will at least be a useful addition and will serve as a departure point for a more thorough fleshing out of the SOA concept. --Solidpoint 08:58, 4 August 2007 (UTC)

Most of the introduction is now my work. I think I am making some progress in expressing the key points of SOA in a technology neutral language. This is actually turning out to be much harder than I expected and I suspect that is because the SOA concept is still rather nebulous. Whoever wrote the Other SOA Concepts section I hope will write more. It is very well done. The two sections before it are pretty weak and could use some work. I tried to help the first of those two by making what I thought were the points more clear, but others should judge my success there. I think the entire contents of Service-oriented architecture is now likely obsolete, but perhaps not. Please sign your additions if they are significant. This page is getting quite long and the discussion does not reflect the number of items that are potentially contentious.

--24.23.45.169 11:35, 14 August 2007 (UTC)Sorry, I didn't realize I was not logged in under my user name. My bad. For reference purposes I have signed in and signed this discussion. --Solidpoint 11:37, 14 August 2007 (UTC)

[edit] Explain that people use "SOA" to mean two different things

The single greatest challenge I see in improving this article is that the term SOA means one thing to one group of people, and another thing to another group of people. One group takes SOA to mean roughly a style of design, without implying anything about the technologies or infrastructure used to implement it. The other group takes SOA to mean roughly implementing a system as a collection of Web Services. Currently this article has a lot of conflicting claims reflecting the two camps.

Is one group just plain wrong? Yes and no. In human language, if enough people use a word in the same wrong way for long enough, then the language has changed, and that usage of the word has become correct (without necessarily having eliminated the previous meanings).

I strongly suggest that this article should start by explaining that the term "SOA" is commonly used in two different but related ways, and then go on to explain each of the two and how they are related. I'd be happy to take a crack at it if people like the idea.

MarkAb 03:59, 1 September 2007 (UTC)

See my comments below, under "A serious rewrite is needed" Gabhala 22:36, 8 October 2007 (UTC)

[edit] Security

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

The Web Services Security specification (WS-Security) provides a set of mechanisms to help developers of Web Services secure SOAP message exchanges. Specifically, WS-Security describes enhancements to the existing SOAP messaging to provide quality of protection through the application of message integrity, message confidentiality, and single message authentication to SOAP messages. These basic mechanisms can be combined in various ways to accommodate building a wide variety of security models using a variety of cryptographic technologies.

WS-Security also provides a general-purpose mechanism for associating security tokens with messages. However, no specific type of security token is required by WS-Security. It is designed to be extensible (e.g. support multiple security token formats) to accommodate a variety of authentication and authorization mechanisms. For example, a requestor might provide proof of identity and a signed claim that they have a particular business certification. A Web service, receiving such a message could then determine what kind of trust they place in the claim.

Additionally, WS-Security describes how to encode binary security tokens and attach them to SOAP messages. Specifically, the WS-Security profile specifications describes how to encode Username Tokens, X.509 Tokens, SAML Tokens , REL Tokens and Kerberos Tokens as well as how to include opaque encrypted keys as a sample of different binary token types. With WS-Security, the domain of these mechanisms can be extended by carrying authentication information in Web services requests. WS-Security also includes extensibility mechanisms that can be used to further describe the credentials that are included with a message. WS-Security is a building block that can be used in conjunction with other Web service protocols to address a wide variety of application security requirements.

Message integrity is provided by leveraging XML Signature and security tokens to ensure that messages have originated from the appropriate sender and were not modified in transit. Similarly, message confidentiality leverages XML Encryption and security tokens to keep portions of a SOAP message confidential. —Preceding unsigned comment added by Gnanaguru (talk • contribs) 08:06, 12 September 2007 (UTC)

[edit] A Serious Rewrite is Needed

In my opinion, this article is a mess. The intro is completely at odds with the rest of the article, which is rife with POV statements. The intro itself does not take into account the full scope of the article, and is, in my opinion, in itself cruising extremely close to POV. Taken in its entirety, this article more closely resembles an argument than an encyclopedic entry.

SOA is granular - it means different things at different levels of abstraction. It can be applied at a business process level, a user experience level, and a systems design & development level - each with their own definition of the concept, as defined in 'vernacular' terms.

I think the article needs to reflect this, while at the same time providing an entry point for newcomers to the subject without drowning them with the jargon of any one particular level.Gabhala 00:30, 6 October 2007 (UTC)

I have to agree, this article is a prototype example of a wikipedia article gone mad. My problem was that reading the article simply didn't prove useful. There are a number of reasons for this:
  1. The content is vague and wandering, as often happens in wiki articles. Many of the paragraphs seem to be "blobs" rather than a sequential series of sentences that crystallize a central point, which is really a paragraph's job.
  2. The sentence structures of many of the sentences are technically valid but so complicated that they leave the reader to say "Huh? What was that?"
  3. Many, many sentences have grammatical problems. I was going to start to correct some of the plural conflicts (things like "the man throws a ball, men throw a ball") but I found so many of them that I decided I didn't have that kind of patience tonight.
This article reminded me of one of those product manuals that is translated from another language into English through a literal, word-for-word translation. Mroesler 04:03, 12 October 2007 (UTC)
The intro is very poor and seems to reflect one person's POV - SOA *is* primarily a distributed computing paradigm, as the rest of the article reflects. If SOA is used in areas other than computing, some examples (with references) would be helpful. There are enough books and articles out there that virtually every statement in this article could either be backed up by a reference or removed.--Michig 09:22, 19 October 2007 (UTC)

[edit] Can we reach a consensus on "A SOA"/"An SOA"/neither?

All three variants are used within the article. Personally, I think "An SOA" is correct, as is "A Service Oriented Architecture", but I will go with the consensus on this. Gabhala 22:36, 8 October 2007 (UTC)

If the next letter in a sentence is a vowel, one should use "an", otherwise "a". For instance, "A dog jumped into the pool", compared to "An ostrich jumped into the pool". While the article should be uniform, what 'sounds right' isn't always correct. Tinkertim (talk) 12:20, 17 January 2008 (UTC)
The correct form is surely "The SOA" or just "SOA". This is because SOA is defined in this article as a particular architectural style. There is only one such style (although there may be variations). Therefore it doesn't make sense to say either "a SOA" or "an SOA", because that suggests (wrongly) that you could have lots of SOAs. (You don't say "A Post-Impressionism" unless you want to refer to multiple post-impressionisms.) Most uses of the term "SOA" in the article refer to it as a unique thing (an architecture, a design, a paradigm). However, there are some plural forms of SOA in the article. For example "SOAs build applications out of software services." This doesn't make any sense if we understand SOA as a style - it starts to make sense only if we understand SOA as an artefact possessing this style. --RichardVeryard (talk) 19:50, 18 January 2008 (UTC)

[edit] A rewrite

I reverted to something which can at least be a good departure point. What was there was very poor at best. What I attempted to do in writing about SOA is compare it and contrast it to things that are familiar to typical readers of the entry. I also wanted to describe the essential characteristics of SOA in general terms before engaging in a discussion of implementations. It is not at all unusual for architectures to have many implementations, just as it is not unusual to have a notion like an associative data structure have many implementations.

I have read a great deal of the literature on SOA and think I understand its essential characteristics, and believe I have expressed them well in the intro section. Substantial changes to these ideas should be vetted via this discussion page, not changed wholesale with no discussion by someone who demonstrates a very limited knowledge of the subject. I would welcome a discussion, but an informed one. If you are a vendor pushing a POV please do us all a favor and stick to writing more marketing gibberish for your firm and leave it to others to provide a generic explanation of what the salient features of SOA are.

With this caveat I welcome discussion and revision.

--Solidpoint 08:48, 29 October 2007 (UTC)

Trying to fix this article seems a lost cause unless we can find a small group of experts (2-5) and lock the page from other "contributors". It's very clear to me that employees of vendors feel entitled to come here and dump their marking crap on the page and expect that to be accepted as encyclopedic. It isn't, and the page is so incoherent as to border on pure gibberish. Anyone else want to volunteer to be an expert? Task one would be to make some decisions on scope as this mess wanders all over the place.

--Solidpoint 09:13, 29 October 2007 (UTC)

The current intro, while better than before, is still lacking something. The intro text in itself is fine, but it doesn't cover the full scope of SOA. Part of the problem with defining SOA is that it applies both to business and IT, and holds slightly different meanings in each. An SOA should be implemented as a business process management strategy first, and as an IT design paradigm second (see Service Orient or be doomed!, Jason Bloomberg & Ronald Schmelzer).
The intro needs to reflect both the business process and IT contexts equally, and the article as a whole needs more work on the business process side of things.Gabhala 09:31, 1 November 2007 (UTC)
I don't think it's helpful to try to cover the business process aspects of service-orientation, and the IT-related Service Oriented Architecture in the same article. Why can't the non-IT part be in a separate article? We already have articles for Service-orientation and Service-oriented analysis and design - I don't see why we can't leave this article as IT-centric. Having articles focused on a more specific topic would be a great help in making them understandable and useful.--Michig 10:23, 1 November 2007 (UTC)
You may be right in that the business and IT aspects of SOA should not be discussed in the same article. However, the term "Service Oriented Architecture" has application in both those areas. After all, the whole point of SOA is to facilitate the elusive alignment between business goals and IT. To my mind, keeping this article IT centric renders it useless to a reader who has encountered the term in a business process context. I believe the article entitled "Service Oriented Architecture" must provide information on the entire scope of the term, with separate articles for the business and IT contexts, if necessary (though I also think that separating the contexts may perpetuate the type of confusion that already surrounds the term).Gabhala 16:08, 1 November 2007 (UTC)

This page has improved markedly, and I wish to thank everyone for making what must have been a huge effort to produce something worthy. At long last my professional interest has allowed me to focus on SOA again and I am happy to find others have been hard at work here creating something special. It might be helpful to review references more than 3-4 years old to decide whether they are still relevant, but otherwise this page is really looking good. Again, kudos for those who took up the challenge. --Solidpoint (talk) 07:45, 25 February 2008 (UTC)

[edit] Literature

I have removed the Literature section as it seemed a slightly arbitrary collection of the sources available on this topic. Some were already referenced in the article. I would suggest that the others could be used as sources within the article and should be added back in only when used as references. The list is below.--Michig 14:10, 12 November 2007 (UTC)

Some of them appear to have been added by the authors of the papers/publications concerned (see the article's history), so there is an obvious Conflict of interest in having those articles linked. If anyone feels strongly that there should be a list of publications in the article that are not referenced within the text, you are of course free to add them back in.--Michig 14:35, 12 November 2007 (UTC)

[edit] Books, non-technical
  • Allen, Paul (2006). Service Orientation, winning strategies and best practices. Cambridge, UK: Cambridge University Press. ISBN 0521843367. 
  • van den Berg, Martin; Norbert Bieberstein and Erik van Ommeren (2007). SOA for Profit, A Manager's Guide to Success with Service Oriented Architecture. Sogeti & IBM. ISBN 978-90-75414-14-1. 
  • Bloomberg, Jason; Ronald Schmelzer (2006). Service Orient or Be Doomed! How Service Orientation Will Change Your Business. Hoboken, New Jersey: WILEY. ISBN 0-13-187002-5. 

[edit] Books, technical
  • Barry, Douglas K. (2003). Web Services and Service-Oriented Architectures: The Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers. ISBN 1-55860-906-7. 
  • Bieberstein, Norbert; Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah (2006). Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap. Upper Saddle River: Pearson. ISBN 0-13-187002-5. 
  • Erl, Thomas (2007). ServiceSOA Principles of Service Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-234482-3. 
  • Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0. 
  • Erl, Thomas (2004). Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-142898-5. 
  • Hurwitz, Judith; Robin Bloor, Carol Baroudi, Marcia Kaufman (2006). Service Oriented Architecture for Dummies. Hoboken: Wiley. ISBN 0-470-05435-2. 
  • Krafzig, Dirk; Karl Banke, Dirk Slama (2004). Enterprise SOA Service Oriented Architecture Best Practices. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-146575-9. 
  • Linthicum, David (2003). Next Generation Application Integration: From Simple Information to Web Services. New York: Addison-Wesley Professional. ISBN 978-0201844566. 
  • Margolis, Ben (2007). SOA for the Business Developer: Concepts, BPEL, and SCA. Mc Press. ISBN 978-158347065. 
  • Marks, Eric; Mark Werrell (2003). Executive’s Guide to Web Services. Hoboken: John Wiley & Sons. ISBN 978-0471768944. 
  • Marks, Eric; Michael Bell (2006). -Service Oriented Architecture: A Planning and Implementation Guide for Business and Technology. Hoboken: John Wiley & Sons. ISBN 978-0471768944. 
  • Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0. 
  • Pulier, Eric; Hugh Taylor (2005). Understanding Enterprise SOA. Greenwich: Manning Publications. ISBN 1-932394-59-1. 

[edit] Articles/Papers, non-technica

[edit] Articles/Papers, technical

[edit] Standards

[edit] Is it a good idea?

I think it would be helpful to add external links to articles describing success stories or failures, preferably written by users not vendors. I think that such articles can help one to understand where a technology might fit. I looked at the references and external links and did not find a concrete example e.g. "Here's how XYZ solved their yada yada problem with SOA and here are some lessons learned".

Also, I personally am struggling with the idea of using SOA as described here for systems integration of legacy systems. It appears to me that it would be better to push the data from these systems into a common, integrated relational database, where it's easy to join data. Trying to aggregate data that comes from lots of isolated services would not be fun, nor efficient. Maybe you solve this by calling the utilities that push data into an RDB an SOA? So I turn to the wikiP for some answers.

Some of the SOA stuff I've read reminds me of the early days of objects. People were trying to "discover" objects. After discovery they were then going to figure what to do with them. Solutions looking for problems instead of asking "How can I apply this nifty technology to solve some concrete problems?". Now it's if you provide the service someone will use it. If you build it they will come.

So back to my original thought. What is the appropriate use of the technology and where can you go to find out how it's being used by real people and organizations. Links are one of the great advantages of a web based encyclopedia and one of the things I love about the wikiP.

--cheers H.E. Hall (talk) 16:59, 6 March 2008 (UTC)

  • Found some interesting sites and added them to the external links.

H.E. Hall (talk) 13:48, 7 March 2008 (UTC)