Misplaced Pages

Talk:Service-oriented architecture

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Gavin.collins (talk | contribs) at 15:43, 5 April 2007 (The definition is truism, since it employs circular reasoning.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 15:43, 5 April 2007 by Gavin.collins (talk | contribs) (The definition is truism, since it employs circular reasoning.)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Media mentionThis article has been mentioned by a media organization:

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.


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)

Pronunciation

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

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 prioritised outcomes (e.g reduced cost, faster time to market, improved compliance, end-to-end processes, integration with busines 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 . Not really appropriate for the Misplaced Pages definition. Peter Campbell Talk! 13:27, 2 July 2006 (UTC)
Gavin Collins says: I disagree that the description of SOA at the begining 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-orietented 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)

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 Misplaced Pages 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 Misplaced Pages 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.

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.

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)

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 Misplaced Pages'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)

.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)

Commercial link

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

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

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...

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)

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)

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)

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)

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.

* ]

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

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)


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)

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)

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?

--


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)

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]]]

Removed External Link

A member of our marketing staff unfamiliar with Misplaced Pages 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

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).

Category: