Jump to content

Talk:Service-oriented architecture/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

What is SOA

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

JP: As usual, you are correct. The utter shit I have witnessed on the official Wikipedia SOA page really annoyed me. The entire reason we sought in OASIS to develop an SOA Reference Model rather than a concrete definition was to allow people who have different definitions to reconcile their definitions using the model as a point of common reference. Without this, there can be no meaningful discussion. We also kept the OASIS Reference Model cleanly decoupled from all current technology families such as Web Services (as you wisely noted above) for two reasons. The first is durability - to keep SOA relevant beyond current technology fads. The second is that the A standard for architecture and if SOA is architecture, it must be express able in some normative form used by architects (an ADL) in a manner that is unambiguous and allows SOA to be explained abstract of all implementations. I am glad there are people such as yourself who see the truth to counter the others who try to hock their wares using the acronym du jure.

What has annoyed me beyond belief is the "editors" who have not bothered to even read the specs (OASIS SOA RM, OMG SOA work, W3C Web Service Architecture, ebXML, UN/CEFACT Architecture, and even CORBA etc) and pretend to be experts while the opinions of people such as you and I who have spent a good decade working on the concepts of SOA have their text deleted.

SOA: - An Architectural Paradigm for organizing and using distributed capabilities that may be under the control of different ownership domains. - A framework for matching needs and capabilities. - A view of architecture focusing on “Services” as an abstract boundary that facilitates interactions between those with needs and capabilities. - A way of thinking about problems (both business and technical realms).

Duane Nickull http://technoracle.blogspot.com

Update Sept 2009:

While the editor of this page has failed to do anything about the sad state of the wikipedia article, it is more or less moot now. The OASIS Reference Model has largely been adopted (both by name and in spirit) as the industry definition. The wikipedia page is hovering on the brink of relevancy. —Preceding unsigned comment added by Nickull (talk • contribs) 21:11, 16 September 2009 (UTC)



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.

To Bob Breedlove (author of the above): I tried contacting you to collaborate on the history of SOA, but the mail link on your site is broken (bob@bobbreedlove.com bounces), and your wiki is set read-only. I recently wrote an article about the early history of SOA (http://eriktownsend.com/index.php?option=com_docman&task=doc_download&gid=4&&Itemid=19). I'd like to figure out the appropriate way to contribute the content to Wikipedia, but it's a little confusing. The main page seems to have a very volatile edit history. ErikTownsend (talk) 17:49, 27 July 2008 (UTC)

What distinguishes SOA from SaaS or old fashioned Service Bureau? (talk) 1:54, 10 October 2008 (UTC) —Preceding unsigned comment added by Mrego (talk • contribs)

Look all:

None of the key questions that need to be answered in this article have been addressed. Here is a starter list of what a newb would want to know:

1. What is SOA? Is it a type of architecture as the "A" in the acronym surely suggests? 2. If it is a style of architecture (a definition I agree with), then what is UNIQUE about this style of architecture or what distinguished it from other forms of architecture. Conversely, it is the same as other types of architecture. Do not go about comparing it to Web Services. Web Services is not a type of architecture; it is a family of related technologies. 3. Starting with the core aspect of SOA (which surely has to the the 'service'), explain what things need to be present in a service oriented environment (notice I did not say 'within an SOA'). 4. SO what is a service? OMG, OASIS, IBM, Sun, Adobe, Tibco and The Open Group all have similar definitions yet this article meanders about without really answering that question. Perhaps at it's most simplistic level, a service is an abstract boundary between needs and capabilities. This could then be presented in contexts such as enterprise architecture whereby a "service represents a particular, described pattern of behavior..." 5. What other things have to be linked to a service for it to be used? Surely reachability and visibility need to be possible, a service description, a data model (even services with no data leaving them still have a data model), a service policy (even allowing a service to be freely accessed by anyone IS a service policy, etc.

Do you all see where I am going here? I think this article really needs to be re-written from the ground up.

Dnickull —Preceding unsigned comment added by 174.6.184.171 (talk) 01:08, 16 April 2009 (UTC)

Introduction to SOA

Lead in this article starts off with an understanding that every visitor to this article is from the programming community. I would suggest a section as 'Introduction to SOA' which starts narrating in layman 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)

From User: Nickull I agree that this article is really bad in its entirety. In fact, most industry pundits think this article sucks. The problem arises from the fact there are multiple, disparate (and worse - conflicting) definitions of SOA in the industry. BPM is NOT part of SOA (it uses SOA but at runtime, services do not know (and should not know) what they are being used for). This is a basic architectural tenet of SOA called managed transparency.

Given you have multiple disparate definitions, the best this page can do is to note them and provide a common point of reference so each disparate definition can be noted. That point of reference is called a "reference model". There is an industry standard reference model (OASIS SOA Reference Model) which is by far the most quoted artifact used today in high tech, yet explains SOA in terms of what a lay person can understand. SOA is an architectural model whereby capabilities and needs may interact via "services". Services are abstract boundaries to facilitate the interactions. In non-technical terms, a service is simply a unit of work done by one with the capability to perform the work for another who needs the functionality. In the IT world, services are implemented via an interface.

There is a white paper I wrote which you may freely use to lift words from. www.adobe.com/government/pdfs/SOA-technical-whitepaper.pdf

I would highly encourage you guys to do some research then update this page. —Preceding unsigned comment added by Nickull (talk • contribs) 15:49, 3 October 2008 (UTC)

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)

You are correct about the history actually going back to the early 80s for big tech companies. I wrote a white paper about my own experiences with SOA (going back to '82 at DEC), but my attempt to add a link to it was censored for conflict of interest (It's on my personal website). The article is at http://eriktownsend.com/index.php?option=com_docman&task=doc_download&gid=4&&Itemid=19. I am trying to figure out the politically correct way to integrate the content here, but there seems to be a lot of contention and volatility around this page… ErikTownsend (talk) 02:25, 28 July 2008 (UTC)

from User:Nickull WRONG!!!! SOA is different in that it crosses disparate domains of ownership and uses loosely-coupled protocols and standards. The evolution came from a move to distribute systems over the internet. The next main step was the advent of XML, a structured, portable data syntax. The first true web and XML based SOA was ebXML. This was quickly eclipsed by the W3C Web Services Architecture and the United Nations CEFACT eBusiness Architecture. The key statements are contained in both the ebXML and Web Services Architectures where they specifically use the terms "service Oriented" which is what caused the rise of the use of the term by press and analysts in the late 1990's and early part of this century. The evolution is simply a placement of the anonymous customer business model over the internet, although SOA does not depend on either XML or the internet.

I have worked on all of these architectures and feel compelled to write as this SOA entry in Wikipedia is inaccurate, more than likely the product of vendors trying to hawk their wares as "SOA". —Preceding unsigned comment added by Nickull (talk • contribs) 15:55, 3 October 2008 (UTC)

Pronunciation

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

User:Nickull Yes - you are correct. I speak about 50 times per year on SOA and this is a very common pronunciation. —Preceding undated comment was added at 15:57, 3 October 2008 (UTC).

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.

User:Nickull Look guys, please do some reading here. YOu are totally correct in noting the vested interested of vendors and it is quite likely that SOA can never be described in a concrete architecture that captures everyone's point of view. That is why the OASIS SOA Reference Model Technical Committee was formed to build a "model" for SOA that is completely abstract of all concrete technologies, but captures the unique aspects of SOA that distinguish it as an architectural paradigm. The advantage to this approach is that people are free to disagree with it, but at least they can use it as a common point of reference to explain what they disagree with. The OASIS Technical Committee has historically been the largest OASIS TC and has produced what has become the industry standard. It was voted by several hundred companies to be used as a standard artifact for architects. —Preceding undated comment was added at 16:01, 3 October 2008 (UTC).

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)

Michig is correct here. The biggest misperception in the industry has to be that REST=HTTP+XML and is the opposite of SOAP. Whoever is responsible for this article has done a very, very bad job of explaining what SOA or anything is. Wikipedia is not working folks. —Preceding unsigned comment added by 24.84.57.146 (talk) 17:31, 27 February 2009 (UTC)

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. — Preceding unsigned comment added by 203.9.186.133 (talk • contribs) 01:32, 10 May 2005

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

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

The "Best Practices" link seems a bit commercial… — Preceding unsigned comment added by 199.243.106.66 (talk • contribs) 19:28, 17 January 2006

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… — Preceding unsigned comment added by 199.171.212.100 (talk • contribs) 19:54, 27 October 2006

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.) — Preceding unsigned comment added by 194.138.39.53 (talk • contribs) 15:15, 3 February 2006

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… — Preceding unsigned comment added by 199.171.212.100 (talk • contribs) 19:56, 27 October 2006

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. — Preceding unsigned comment added by 165.127.247.33 (talk • contribs) 20:47, 6 March 2006 (UTC)

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)

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)

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)

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)

SOA is not linked to any one vendor, so multiple models can co-exist, however if SOA is used in an Enterprise, its practitioners(IT) needs to follow the established business semantics when dealing with customers, users and internal stakeholders.

From BPM there are usually 5 levels, if SOA is used in an enterprise, it would make sense to link the two.

Take for example, a BPM view of a Process is that it can be broken down into Actvities, Actvities can be broken down into Tasks, Tasks can be broken down into Steps. IT automation and flow begins at the Step level. Or in other words Business processes normally do not go beyond the Step level, so BPM begins there. Programming requires that the business process be mapped to at least the step level then the Business Analyst can transfer the mapping and Automation request to IT (IT Analyst, IT Project Manager, and Developers. keep it short, keep it simple (talk) 03:27, 14 March 2009 (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?

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)

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. — Preceding unsigned comment added by 194.138.127.36 (talk • contribs) 18:40, 26 January 2007

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 — Preceding unsigned comment added by 142.103.192.33 (talk • contribs) 19:34, 12 February 2007

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

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

I vote no. There is not really any litmus test as it is an "abstract" architectural paradigm. Abstract means it cannot be implemented without further specialization. As such, it would be illogical to assume any vendor can claim to be an SOA vendor unless they are selling some sort of framework for adhering to the architectural paradigm while building stuff. —Preceding unsigned comment added by Nickull (talk • contribs) 21:08, 16 September 2009 (UTC)

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)

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)

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)

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)

This last comment is mistaken. English uses "an" before a word starting with a vowel sound ("an ostrich", "an SS officer") and "a" before a word starting with a consonant sound ("a dog", "a UN officer"). The issue here surely is that sometimes SOA is pronounced as an initialism (an "S.O.A") and sometimes as a acronym ( a "So-ah" ). Therefore there is no way of standardising use of a/an without standardising the pronunciation. Merlin Cox (talk) 12:45, 2 October 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)

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)
Not that it would apply here (because the article appears to have remained IT centric), but a useful way to give understanding to business agents (in a seprate article) would be to site real world examples of SOA - solutions that have been implemented using SOA in conceptualization and design. What distinguishes this from "traditional" architecture? From the standpoint of the user, why is it a good? The word "service" connotes a good. How may it serve the user? How might another architecture or modelling scheme not serve the user as well? Serv1dan 09:48, 8 July, 2009 —Preceding undated comment added 14:50, 8 July 2009 (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)


Needs a rewrite still. 

Too many incorrect definitions in this article. Good example:predefined groups of functions known as classes.

Since when is a class equal to functions? A class is an object's blueprint that defines and specifies the operations (services) and attributes (data)(CF,June 2008) —Preceding unsigned comment added by 85.82.252.10 (talk) 00:23, 15 June 2008 (UTC)

Well, a class's methods are NOT services, (though they may be used to implement services - and that is the point I think) and many times are defacto cut & paste copies of C functions in the case of C++ and C#, so from a larger perspective it is useful to think of a class's methods as akin to a COBOL procedure, or a C function.
If you were around working in C++ in 1990 and worked with Eiffel you would know that as of then it was possible to create C++ code using a code generator that generated only C code, so other than making up a whole boat-load of new alphabet soup (more lipstick, same pig) most of the ideas around today have been around since Algol in the 1960's, and despite the billions spent by marketing departments proclaiming "This changes EVERYTHING" at every turn, there are many similarities with can be exploited to help a reader draw on their existing industry experience to help understand SOA. Beyond methods, classes also provide scope and scoped data, but again, that same ability exists in C if you know how to use it, as Bruce Eckles "Thinking in C++" argues forcefully. Since we don't want to get into a discussion of how the chosen language implements the services that comprise a SOA service, I think it better to not to discuss these implementation issues and focus on the similarities, excepting for scale, plasticity and the dynamic vs static nature of how chunks of functionality are made to work together. I agree this area could benefit from some scrutiny, but I find the class definition offered here to be still worse for the purposes at hand. Too much religion, not enough perspective.
The trick to using Compare & Contrast as a technique to illustrate a point is to choose carefully which attributes are to be included and which will only muddle the point because they are off-point or extraneous detail. Whether you call data a field, a column, an attribute, a structure member or Rumplestiltskin, a rose by any other name is still a rose and for the sake of clarity the contextual difference should be ignored for purposes of Compare & Contrast.--Solidpoint (talk) 08:25, 27 June 2008 (UTC)

Now for the point of my stopping by here at the discussion page - I changed (again) the discussion of the role of Metadata because I think the cause and effect got reversed. To the extent that an application uses metadata (XML, WSDL,SOAP, etc) to discover one or more services hosted on some "foreign" system, and incorporates those services into the current implementation of its application run-time, then it is dynamically configuring itself using metadata, and the next time that application is run it may well be connecting to a different "foreign" service provider, whose different underlying structure will be accommodated precisely because the metadata "tells" it what it must do to make that adaptation.

If someone was trying to make another point, and I have missed it, then by all means let's discuss this idea further so that it is not lost. TVMIA --Solidpoint (talk) 08:25, 27 June 2008 (UTC)

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)

Books, non-technical
  • Allen, Paul (2006). Service Orientation, winning strategies and best practices. Cambridge, UK: Cambridge University Press. ISBN 0521843367.
  • van den Berg, Martin (2007). SOA for Profit, A Manager's Guide to Success with Service Oriented Architecture. Sogeti & IBM. ISBN 978-90-75414-14-1. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Bloomberg, Jason (2006). Service Orient or Be Doomed! How Service Orientation Will Change Your Business. Hoboken, New Jersey: WILEY. ISBN 0-13-187002-5. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
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 (2006). Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap. Upper Saddle River: Pearson. ISBN 0-13-187002-5. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • 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 (2006). Service Oriented Architecture for Dummies. Hoboken: Wiley. ISBN 0-470-05435-2. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Krafzig, Dirk (2004). Enterprise SOA Service Oriented Architecture Best Practices. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-146575-9. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • 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 (2003). Executive’s Guide to Web Services. Hoboken: John Wiley & Sons. ISBN 978-0471768944. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Marks, Eric (2006). -Service Oriented Architecture: A Planning and Implementation Guide for Business and Technology. Hoboken: John Wiley & Sons. ISBN 978-0471768944. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Newcomer, Eric (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Pulier, Eric (2005). Understanding Enterprise SOA. Greenwich: Manning Publications. ISBN 1-932394-59-1. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
Articles/Papers, non-technica
Articles/Papers, technical
Standards

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)

A very bad documentation

Hi, I really think that this article is the worst documentations that I've seen about SOA. There is not real architectural documentation, no architectural diagram (only functional ones), nothing about implementation (such as ESB or SCA)… It is more focused on business than it is on architecture, and as a result, it makes this article speak about a lot of think around SOA, but not aout SOA itself. SOA is service oriented architecture, and there is nothing about "what is a service". This article makes me think that it was written by a vendor rather than an architect… —Preceding unsigned comment added by 213.162.48.17 (talk) 15:04, 24 July 2008 (UTC)

In particular, the diagram showing layers is ambiguous. What do the circles and arrows mean? The diagram should have a notation key. --Pmerson (talk) 12:32, 26 November 2009 (UTC)

Moved for discussion

I've moved the following from the article for discussion, titling it SOA. While there may be useful information here, it's all unsourced. Even if sources can be provided, it should not simply be lumped into the article without regard for the current content. Finally, it appears to be mostly copied from [2] or the sources upon which this lecture is based. --Ronz (talk) 16:10, 25 July 2008 (UTC)

SOA

Service Oriented Architecture is an architecture based on reusable, well defined services implemented by IT Components. SOA is becoming a standard approach for enterprise information systems using the Web Services standards and technologies. Web services face significant challenges because of particular requirements. When applying the SOA paradigm to real-time system, we address many problems which include response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc. In this paper, we will discuss, what SOA is, followed by detailed discussion on several issues that arise when SOA is applied to industrial systems.

A group of services ,which communicate with each other .The communication involves either simple data passing or it could invlove two or more services coordinating some activity.

Service -oriented architecture is based on request/response design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. SOA is loosely coupled in nature i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.

What is SOA? SOA represents business functions as shared, reusable services. SOA designs treat parts of business processes, and the IT infrastructure that supports them, as secure, standardized components (services) that can be reused and combined to address changing business priorities. SOA brings a new way to look at applications. SOA separates messages from processing. SOA services provide consistent results via predefined messages that might be delivered by any number of environments and mechanisms.

WHY SOA In todays's IT market each and every company has its different kind of infrastructure across operating systems,applications,system software and application infrastructure .Some existing applications are used to run the current business processes ,it is not possible to build the infrastructure from the beginning is not the correct way. We use SOA to solve this problem. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.— Preceding unsigned comment added by Ronz (talk • contribs) 17:10, 25 July 2008

Article ripped off from someone's dissertation?

See http://www.scribd.com/doc/964179/Service-Oriented-Arcitecture

It appears that chunks of it were copy-and-pasted into this article. —Preceding unsigned comment added by 216.206.250.130 (talk) 19:17, 4 August 2008 (UTC)

The paper lists wikipedia as a reference, and I'm unable to find a publication date, so it's probably just a case of the paper using this article as a ref. --Ronz (talk) 19:41, 4 August 2008 (UTC)

Comment from User:HamburgerLover

Some users (like Ronz) are continually vandalizing the main page by removing external links to such companies as Progress, which is one of the leaders in SOA technology. — Preceding unsigned comment added by HamburgerLover (talk • contribs) 17:16, 24 August 2008

No, YOU are the vandal here. You insist on spamming your link although more than one editor has removed it. An administrator must have agreed that it was spam since my request for page protection was granted. Themfromspace (talk) 16:28, 24 August 2008 (UTC)


Comment 2 from User:HamburgerLover

You simply do not know about SOA. Progress/Sonic is a leader in SOA. SOA World is a highly read in the industry. Calling this spam is ridiculous. Viewing the page history, many users disagree with you. —Preceding unsigned comment added by HamburgerLover (talk • contribs) 00:37, 25 August 2008 (UTC)

Yea… you, you, and you! Themfromspace (talk) 02:32, 25 August 2008 (UTC)

I propose deleting the External Links section altogether, which constantly attracts linkspam and serves very little purpose for anyone genuinely seeking to understand SOA. Everyone seems to have a software product or book or training course or blog to promote. The external links currently includes

  • two conferences
  • two links to a consultancy website
  • a link to another consultancy website
  • a link to a paper on a software vendor website
  • an article by the CTO of another software vendor
  • a couple of papers promoting a recent book
  • a personal blog

When people see these links, it is only natural for them to think - why not mine as well? --RichardVeryard (talk) 03:35, 25 August 2008 (UTC)

It's likely that I was the one that tagged the section for cleanup. I would have gotten around to trimming them back, but the constant disruptions here have prevented me from doing so.
I've removed them. If anyone thinks any of them should be restored, please clearly explain why and refer the criteria in WP:EL. --Ronz (talk) 15:49, 25 August 2008 (UTC)
I agree with the removal of the links. They were cruft, attracted spam, and didn't add any knowledge about the topic. Themfromspace (talk) 19:09, 25 August 2008 (UTC)

Internet of Services

I have read with interest the paragraph on the "Internet of Services". I am working as a EU official and after consultations with various experts we have also come up with the following definition of the Internet of Services: The Internet of Services describes a vision of the Internet of the future where organisations and individuals can find software services on the Internet, combine them, and easily adapt them to their specific context, so that they can use services which do exactly what they need. Technically, the Internet of Services will consist of virtualisation technology that will make network, storage and computing resources available for "cloud computing". Services use these resources and will be built using SOA principles. Through so-called service front ends the users are in control of the applications they use and they can mix services and data to compose services which are truly useful for them. More about the Internet of Services and the research that is currently done to make the vision a reality can be found on [3].

Do you agree that I add this paragraph to the Internet of Services description? Since I am a new user I need somebody to unprotect the page first. Or do you think it is better to start an entirely new page about the "Internet of Services" theme? Euofficial2005 (talk) 15:12, 25 August 2008 (UTC)

Further reading section necessary?

Last version below: --Ronz (talk) 22:19, 17 October 2008 (UTC)

Further reading

  • SOA for the Business Developer: Concepts, BPEL, and SCA -- ISBN 978-158347-065-7
  • Brown, Paul C., Succeeding with SOA: Realizing Business Value Through Total Architecture. Upper Saddle River, NJ: Addison-Wesley Professional, 2007.
  • Brown, Paul C., Implementing SOA : Total Architecture in Practice. Upper Saddle River, NJ: Addison-Wesley Professional, 2008.
  • Frank Leymann, Dimka Karastoyanova (Eds.) et al.: Service Oriented Architecture – Overview of Technologies and Standards. Special Topic Issue Journal it - Information Technology. Vol. 50 (2008)Heft 2
  • Janner, Till ; Cañas Vaz, Miguel Angel ; Hierro, Juan J. ; Lizcano, David ; Reyes , Marcos ; Schroth, Christoph ; Soriano, Javier ; Hoyer, Volker: Enterprise Mashup: Putting a face on next generation global SOA. The 8th International Conference on Web Information Systems Engineering (WISE 2007). Nancy, France, 2007.- URL http://www.alexandria.unisg.ch/Publikationen/41338
  • Schroth, Christoph ; Christ, Oliver: Brave New Web: Emerging Design Principles and Technologies as Enablers of a Global SOA. In: Proceedings of the 2007 IEEE International Conference on Services Computing (SCC 2007): IEEE Computer Society, 2007.- 2007 IEEE International Conference on Services Computing (SCC 2007).- Salt Lake City, Utah, USA, S. 8.- URL [4]

Discussion

It appears to be attracting spam. --Ronz (talk) 22:19, 17 October 2008 (UTC)

Of course further reading is needed. It already reads like a commercial for Oracle and the books and articles listed are fair. —Preceding unsigned comment added by Azambataro (talk • contribs) 18:14, 18 October 2008 (UTC)
I agree that it's too promotional. I don't agree upon adding yet more material that looks just as commercial in order to be "fair." --Ronz (talk) 02:49, 19 October 2008 (UTC)


SOA Implementation

I think the main problem with this wiki-entry is to separate the definition (explained in the very first 10 lines of the text) and the implementation/use (webservice, xml and such).

SOA in simple words CAN BE CREATED using pen and paper, or usually is written in a whiteboard.

The implementation of SOA is a different thing. The implementation of SOA is not tied to some specific paradigm (neither is a paradigm or method), the concept "loose protocol/language/system" used for SOA is loose by himself, so in a company, the concept "loose" can be defined only for the established architecture, in the case if they uses only AIX server, then the concept "loose" may not consider Windows as a potential service provider. "Loose" is not the same as "standard" or "universal", even when the ideal is to be widely supported. --200.83.2.4 (talk) 19:09, 23 March 2009 (UTC)--200.83.2.4 (talk) 19:09, 23 March 2009 (UTC)

Alternatives to SOA

Recent articles state that "SOA is dead". In which case, what are some "alternatives to SOA?"

"Web paradigm arises as alternative to SOA" —Preceding unsigned comment added by 192.174.37.50 (talk) 19:46, 21 April 2009 (UTC)

The quote was incomplete. It is actually {http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html "SOA is dead; Long Live Services"]. SOA was abused so long that something had to give. SOA as a hype IS dead. SOA as a Service-Oriented Arquitecture is well alive and kicking, thanks to the services. See the SOA Manifesto which originated partially from this blog. Yveschaix (talk) 02:17, 15 September 2010 (UTC)

This article needs a heavy rewrite

I don't want to criticize the good work and effort that wikipedians have done to create this article, but its disjointed, has inaccurate statements, a number of duplicate sections and worst of all, I don't think it actually describe what SOA does. The article focuses too heavily on the functional aspects, pro's and con's etc. If confuses the old style SOA mechanism, which was used with mainframes in the 70's and 80's with the new distributed style using service broker, service regisry, ESB and web service protocols and leaves the reader with the impression that web services aren't really the best way to do SOA, when in fact they are the most sucessfull way.

This is what I think we need to change.

1. The first paragraph, apart from 'Many commentators[who?] see SOA concepts as built upon and evolving from older concepts of distributed computing[2][3] and modular programming'.

Apologies that is incorrect. I think that is true. scope_creep (talk) 20:34, 5 May 2009 (UTC)

2. Description. Its a total mess, and fails to describe the main components of a SOA, their are different applications and design of SOA, but broadly speaking, they are much the same. This is nonsense. 'SOA's goal is to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services.' And what does this mean. 'For this to operate, no interactions must exist between the chunks specified or within the chunks themselves. Instead, the interaction of services (all of them unassociated peers) is specified by humans in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. ' It doesn't make sense. And this. 'Relative to typical practices of earlier attempts to promote software reuse via modularity of functions or by use of predefined groups of functions known as classes, SOA's atomic-level objects often end up 100 to 1,000 times larger.' The whole description section needs rewritten to describe the components of SOA.

3. SOA for Business Applications. I think it's mostly accurate, apart from the fact the SOA is an enterprise dev model, and what else is it going to be used for, so the whole article is about business applications, apart from being over edited and needs simplfied.

4. Requirements. These seem to be functional requirements only. Their should be summat about programming requirements, etc, I don't know how it will fit.

5. Principles. I think this section is good, apart from the last bullet about. EAI Enterprise Application Integration, which is a 1990's model, and is I guess now a subset of SOA, since the whole point of SOA is to build multi business applications, whereas EAI is a single company enterprise integration model.

6. Web services approach. The web services approach is really the only game in town when it comes to integrating SOA services out of silo'd apps. The article fails to provide a complimetary method for desiging SOA, so why call it that. How else would you implement SOA without web services. Sure you could do it with tcp, implement your own pub/sub framework with a lightweight object model. Apart from that the section I think is quite good.

7. SOA and Web service protocols. An redundant section as it's already been said.

8. Other SOA concepts. Good section, it describes some of the architectural components of SOA. This section needs to be expanded to explain how an web service call interacts with a service registery, a broker and an ESB. The actual mechanism of how an orchestarted web service call is made isn't described in web services or Enterprise_service_bus.

9. SOA definitions Should be at the top closer to the functional defintions.

10. Service contract. This is pretty good as well, although it seems to be more conceptual than physical. We could perhaps compare this against what is available in industry.

11. SOA and network management architecture. This should be in the network management article.

12. Discussion. This duplicates a whole bundle of stuff that has been said before, although their is some points which should be closer to the top. Its needs either rewritten or removed.

13. Challenges in adopting SOA. Some of the points in this section are clearly wrong, misinformed or out of date. 'Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture'. Their is now several tools which can do full registry testing.

14. Criticisms of SOA. Needs cleaned up and rewritten, most of it is accurate.

15. SOA, Web 2.0, and mashups and Web 2.0. Their is two sections describing both web 2.0 defintions, the second one seems to be the more accurate.

16. Digital Nervous System. This is a marketing term that was coined to sell a book. Is it really part of SOA. I don't think so.

Yveschaix (talk) 23:38, 14 September 2010 (UTC)Yveschaix This post is the best structured proposition for rewriting this article which does seem to be in a pretty poor shape (without wanting to criticize other contributions also quite useful). Just as a sample, should not the SOA page refer to the SOA Manifesto, which actually answers and clarifies a lot of points mentionned from years back and might simplify the text? after all, the manifesto has been signed to this date by over 700 SOA professionals, all over the world and translated to 9 languages already. But being new to Wiki, or rather, not being very knowledgeable of the editing policy and ethics, I do not know how to reconcile the fact that most of my knowledge and/or understanding of the issues in discussion, come from reading or studying the work of others or certifying from a specific SOA school. So my opinions are basically biased by whatever school of thoughts I chose to adhere to. If I make reference to somebody else´s work to support my argument, what differentiates this reference from an actual marketing promotion? After all, if I have chosen a certain author or a certain school on SOA, it is because I identify myself with its way of approaching the subject matter; does that inhibits me from mentionning how good the work - or the author - has turned out to be, and how well what I have learned has allowed me to be a better professional? I feel I cannot contribute fairly to this discussion unless these questions can be answered. Should I ask them in another Wiki instance?

scope_creep (talk) 20:27, 5 May 2009 (UTC)

Hi Scope creep. I generally agree with your suggestions here. If it was up to me I would restructure the whole article, making a clear division in sections such as overview, history, topics, applications and critism. This will mean a lot of work. Good luck. -- Marcel Douwe Dekker (talk) 00:38, 13 May 2009 (UTC)
The article contains some meta-discussion in the body text that needs to be moved to the dicussion page. Offending text: "This article endeavors to present SOA however, this is purely conjectural. It has been authored, for the most part, by those providing SOA products and services. The statements made below regard the conjectured Service Oriented Architecture but, talks more about the ideas it is based on than any actual implementation. A specific implementation or the requirements for implementation as a replacement to any current configuration of enterprise systems is not discussed." Stephen.andrew.lynch (talk) 00:01, 31 July 2009 (UTC)

Missing details

The last thing I want to add before I move is the fact that their is no descriptions about

1. The optimisations of proceses in a company via say six sigma, lean, cmmi etc (seperate article) which often goes hand in hand with a new SOA app, i.e. why have SOA, if your processes are gubbed.

2. The political aspects of SOA.

3. The different levels of SOA, and how it gets to mashups. Their is generally a recognised 5-7 levels between silo'd apps and say an set of apps working in a mashup or web 2 app. scope_creep (talk) 20:41, 5 May 2009 (UTC)


Mumbo Jumbo

The first paragraph in this article makes very little sense in my opinion - it's sounds like marketing mumbo jumbo to me. 195.74.69.18 (talk) 12:55, 21 July 2009 (UTC)

Not just the opening paragraph, I would suggest, but the 'concept' itself. The whole thing sounds more like the infamous Sokal Affair than anything to do with computing or software engineering.
Of /course/ a new group of words ('concepts'?!) can be invented and existing clear ideas and practices manipulated, moulded and reclassified to fit within them. It is the bread and butter of most soft subjects: obfuscate simplicity by invented terminology to create an industry. The idea that the gate-keepers of systems design should be sleeping on duty and allow such a practice to worm its way into 'respectable' software engineering is, frankly, frightening.
Fortunately, such ideas quite soon lose their naive disciples - those caught in the marketing bandwagon slipstream - as time shows even them that obfuscation adds nothing of worth to science or engineering. Meanwhile, computer scientists can, at least, smirk at the sociological tendencies of some who would enter the gate of computer land using a forged passport without understanding the language spoken therein or the way they will be perceived. —Preceding unsigned comment added by 86.176.70.30 (talk) 10:52, 28 December 2010 (UTC)

Endpoints - not mentioned in article, but mentioned throughout Wikipedia

At http://en.wikipedia.org/wiki/Endpoint endpoint is defined in terms of SOA, but it is not defined within the article. I have fixed this, but would appreciate someone checking it over. Additionally, endpoints, usually for RDF services, are mentioned at all the pages listed at http://en.wikipedia.org/wiki/Special:Search?search=rdf%20endpoint.

I'm not knowledgeable enough in SOA to know how best to treat endpoints in description, but hope that someone else here is and will do it. dblanchard (talk) 18:38, 10 September 2009 (UTC)

Endpoints are a software mechanism, and as such should be in the middle of the article, where the tech should be detailed. But for some reason the tech is discussed at the beginning. To be honest, the article is in worse state, than when I looked at it a year ago. The tech for SOA is covered in SOAP, Web Services, UDDI, WSDL and XML provide the basic infrastucture for SOA, but their is 1 or 2 articles missing in Wikipedia, which are also needed. One of these Web Registry Service, needs expanded into, or renamed in Service Registry, the fundamental component of SOA. Its curious that's not detailed anywhere in Wikipedia. Nor the fundamental service discovery mechanism. scope_creep 13:53, 5 July 2010 (UTC)

Recommendation—Opening paragraphs

There have been numerous major edits of the opening paragraphs due to the diversity of SOA definitions. Every once in a while a different editor changes the opening paragraphs to his or her opinion of what SOA is. None of these edits have had citations to authoritative sources. I suggest we use this section of the talk page to develop a consensus opening article section that includes such citations. Once this is accomplished, we can add a wikicomment that the opening section should only be changed by consensus modification. hulmem (talk) 19:23, 1 January 2010 (UTC)

I agree, it a good start. I was looking at this article this morning, and it seemed to have a better structure, and more diagrams than 6 months ago, but after reading it, I can see it is still a mess. I'm going to do a complete rewrite this year, after I finish, List of places in Highland. scope_creep (talk) 16:01, 8 January 2010 (UTC)
Also, I see somebody has added WCF as a SOA platform. It clearly isn't. MS's preferred SOA platform was Biztalk in 2008, with their SOA guidance, and is now Windows Azure AppFabric services. scope_creep (talk) 16:04, 8 January 2010 (UTC)
I've rewritten the first sentence according to Wikipedia MOS. I removed the "There are several different definitions" because 1) it doesn't belong as first sentence 2) the article does not describe how those definitions differ from one another 3) the article's introduction should describe what all those definitions have in common. Diego (talk) 17:30, 15 January 2010 (UTC)


About Gio Wiederhold as the foundation

First this article is very poor comparatively at the french version. In french we have "Architecture orientée services" IS A KIND OF "Architecture de mediation" IS A KIND OF "Architecture en flot de données". With article on "Architecture fédérée" and DARPA I3 (Only french peoples speak about the american army data architecture, strange no?) —Preceding unsigned comment added by 96.20.9.118 (talk) 22:33, 10 July 2010 (UTC)

I am reverting the text "This architecture has been created by Gio Wiederhold...". Although the text cites a reference, the reference does not state that Gio Wiederhold created Service oriented architecture. Even if it did, the cited reference was written by Wiederhold himself and is therefore a primary source, which needs a secondary source as verification (see WP:PSTS). Without such a citation, the statement Gio Wiederhold created Service oriented architecture is not an established fact and conflicts with Wikipedia's Verifiability policy. — Preceding unsigned comment added by Hulmem (talk • contribs) 06:17, 11 July 2010

Benefits

The benefits section could use a lot of work. One question to be answered: benefits as compared to what? 24.17.218.38 (talk) 08:07, 8 December 2010 (UTC)ATBS

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Service-oriented_architecture/Archive_1&oldid=1002906768"