Sign In/My Account | View Cart  
advertisement


Listen Print Discuss
What Is Service-Oriented Architecture

What Is Service-Oriented Architecture

by Hao He
September 30, 2003

"Things should be made as simple as possible, but no simpler." -- Albert Einstein

Introduction

Einstein made that famous statement many decades ago, and it's still relevant today for building superior software systems. Unfortunately, as anyone who has been in the IT industry for long can point out, far too many software systems have failed Einstein's test. Some are made too simple to carry out the duties they are supposed to perform. Others are made too complex, and the costs of building and maintaining them have rocketed, not to mention the nearly impossible tasks of integrating different systems together. It seems that reaching the right level of simplicity is more like a dream than reality. Where have we gone wrong?

Loose Coupling

Related Reading

Web Services Essentials
Distributed Applications with XML-RPC, SOAP, UDDI & WSDL
By Ethan Cerami


Read Online--Safari Search this book on Safari:
 

Code Fragments only

We don't have to look far to find the problems. As we build more and more software systems, we see similar situations and patterns appearing. Naturally, we want to reuse the functionality of existing systems rather than building them from scratch. A real dependency is a state of affairs in which one system depends on the functionality provided by another. If the world only contained real dependencies, Einstein's test would have been satisfied long time ago. The problem is that we also create artificial dependencies along with real dependencies.

If you travel overseas on business, you know that you must bring power adapters along with you or your life will be miserable. The real dependency is that you need power; the artificial dependency is that your plug must fit into the local outlet. Looking at all the varying sizes and shapes of those plugs from different countries, you would notice that some of them are small and compact while many others are big and bulky.

The lesson here is that we cannot remove artificial dependencies, but we can reduce them. If the artificial dependencies among systems have been reduced, ideally, to their minimum, we have achieved loose coupling. In that sense, Einstein was just talking about was loose coupling. We might rework his famous principle thus: "Artificial dependencies should be reduced to the minimum but real dependencies should not be altered."

SOA Defined and Explained

Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.

The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one.

The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:

  1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

  2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

As illustrated in the power adapter example, interfacing is fundamentally important. If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications.

Since we have only a few generic interfaces available, we must express application-specific semantics in messages. We can send any kind of message over our interfaces, but there are a few rules to follow before we can say that an architecture is service oriented.

First, the messages must be descriptive, rather than instructive, because the service provider is responsible for solving the problem. This is like going to a restaurant: you tell your waiter what you would like to order and your preferences but you don't tell their cook how to cook your dish step by step.

Second, service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility.

Third, extensibility is vitally important. It is not difficult to understand why. The world is an ever-changing place and so is any environment in which a software system lives. Those changes demand corresponding changes in the software system, service consumers, providers, and the messages they exchange. If messages are not extensible, consumers and providers will be locked into one particular version of a service. Despite the importance of extensibility, it has been traditionally overlooked. At best, it was regarded simply as a good practice rather than something fundamental. Restriction and extensibility are deeply entwined. You need both, and increasing one comes at the expense of reducing the other. The trick is to have a right balance.

Fourth, an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry.

Additional Constraints

There are a number of additional constraints one can apply on SOA in order to improve its scalability, performance and, reliability.

Stateless Service

Each message that a consumer sends to a provider must contain all necessary information for the provider to process it. This constraint makes a service provider more scalable because the provider does not have to store state information between requests. This is effectively "service in mass production" since each request can be treated as generic. It is also claimed that this constraint improves visibility because any monitoring software can inspect one single request and figure out its intention. There are no intermediate states to worry about, so recovery from partial failure is also relatively easy. This makes a service more reliable.

Stateful Service

Stateful service is difficult to avoid in a number of situations. One situation is to establish a session between a consumer and a provider. A session is typically established for efficiency reasons. For example, sending a security certificate with each request is a serious burden for both any consumer and provider. It is much quicker to replace the certificate with a token shared just between the consumer and provider. Another situation is to provide customized service.

Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it may reduce the overall scalability of the service provider because it may need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.

Idempotent Request

Duplicate requests received by a software agent have the same effects as a unique request. This constraint allows providers and consumers to improve the overall service reliability by simply repeating the request if faults are encountered.

Deriving Web Services from SOA

Everyone knows roughly what a "web service" is, but there is no universally accepted definition. The definition of web service has always been under hot debate within the W3C Web Services Architecture Working Group. Despite the difficulty of defining web services, it is generally accepted that a web service is a SOA with at least the following additional constraints:

  1. Interfaces must be based on Internet protocols such as HTTP, FTP, and SMTP.

  2. Except for binary data attachment, messages must be in XML.

There are two main styles of Web services: SOAP web services and REST web services.

SOAP Web services

A SOAP web service introduces the following constraints:

  1. Except for binary data attachment, messages must be carried by SOAP.

  2. The description of a service must be in WSDL.

A SOAP web service is the most common and marketed form of web service in the industry. Some people simply collapse "web service" into SOAP and WSDL services. SOAP provides "a message construct that can be exchanged over a variety of underlying protocols" according to the SOAP 1.2 Primer. In other words, SOAP acts like an envelope that carries its contents. One advantage of SOAP is that it allows rich message exchange patterns ranging from traditional request-and-response to broadcasting and sophisticated message correlations. There are two flavors of SOAP web services, SOAP RPC and document-centric SOAP web service. SOAP RPC web services are not SOA; document-centric SOAP web services are SOA.

SOAP RPC Web Services

A SOAP RPC web service breaks the second constraint required by an SOA. A SOAP RPC Web service encodes RPC (remote procedure calls) in SOAP messages. In other words, SOAP RPC "tunnels" new application-specific RPC interfaces though an underlying generic interface. Effectively, it prescribes both system behaviors and application semantics. Because system behaviors are very difficult to prescribe in a distributed environment, applications created with SOAP RPC are not interoperable by nature. Many real life implementations have confirmed this.

Faced with this difficulty, both WS-I basic profile and SOAP 1.2 have made the support of RPC optional. RPC also tends to be instructive rather than descriptive, which is against the spirit of SOA. Ironically, SOAP was originally designed just for RPC. It won't be long before someone claims that "SOAP" actually stands for "SOA Protocol".

REST Web Services

The term REST was first introduced by Roy Fielding to describe the web architecture. A REST web service is an SOA based on the concept of "resource". A resource is anything that has a URI. A resource may have zero or more representations. Usually, people say that a resource does not exist if no representation is available for that resource. A REST web service requires the following additional constraints:

  1. Interfaces are limited to HTTP. The following semantics are defined:

    • HTTP GET is used for obtaining a representation of a resource. A consumer uses it to retrieve a representation from a URI. Services provided through this interface must not incur any obligation from consumers.
    • HTTP DELETE is used for removing representations of a resource.
    • HTTP POST is used for updating or creating the representations of a resource.
    • HTTP PUT is used for creating representations of a resource.
  2. Most messages are in XML, confined by a schema written in a schema language such as XML Schema from W3C or RELAX NG.
  3. Simple messages can be encoded with URL encoding.
  4. Service and service providers must be resources while a consumer can be a resource.

REST web services require little infrastructure support apart from standard HTTP and XML processing technologies, which are now well supported by most programming languages and platforms. REST web services are simple and effective because HTTP is the most widely available interface, and it is good enough for most applications. In many cases, the simplicity of HTTP simply outweighs the complexity of introducing an additional transport layer.

Related Reading

Acknowledgments

The author would like to thank Bill Donoghoe and Mark Baker for their valuable comments. The author is grateful to all the people who participated the SOA thread in the W3C Web Services mail list. Thanks also go to Janet Aylwin, Ian Campbell, Adam Davis and Peter Drummond for proof reading and their suggestions that have made the article more enjoyable to read.

The opinions expressed herein are those of the author and do not necessarily reflect the opinions of The Thomson Corporation with regard to this subject.

Comment on this articleAsk questions or comment on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only Titles Only Newest First
  • Webservices Bases SOA is yet to mature out
    2008-06-08 07:38:58 anusheeltandon [Reply]

    Webservices based SOA is not healthy for investment bank IT where very high performance is required. Please see the article on this


    http://hubpages.com/hub/Application-Rationalization--Modernization-Strategies-for-Investment-Bank-IT-Division


    Thanks

  • Learn About All Things SOA:: SOA India 2007:: IISc, Bangalore (Nov 21-23)
    2007-10-03 04:10:50 hinags202 [Reply]

    Aligning IT systems to business needs and improving service levels within the constraints of tight budgets has for long been the topmost challenge for CIOs and IT decision makers. Service-oriented Architecture (SOA) provides a proven strategy to clearly address both of these objectives. Creating more agile information systems and making better use of existing infrastructure are two leading factors that are boosting SOA adoption across large, medium, and small Indian industries from the BFSI, Retail, Telecom, Manufacturing, Pharma, Energy, Government and Services verticals in India. If you are an IT decision maker belonging to any of these verticals, SOA India 2007 (http://www.soaindia2007.com) (IISc, Bangalore, Nov 21-23 2007) presents a unique opportunity to gather cutting-edge business and technical insights on SOA and other related areas such as BPM, BPEL, Enterprise 2.0, SaaS, MDM, Open Source, and more.


    At SOA India 2007 (http://www.soaindia2007.com) , acclaimed SOA analysts, visionaries, and industry speakers from across the world will show you how to keep pace with change and elevate your IT infrastructure to meet competition and scale effectively. The organisers are giving away 100 FREE tickets worth INR 5000 each to the first 100 qualified delegates belonging to the CxO/IT Decision Maker/Senior IT Management profile, so hurry to grab this opportunity to learn about all things SOA. You can send your complete details, including your designation, e-mail ID, and postal address directly to Anirban Karmakar at anirbank@sda-india.com to enrol in this promotion that is open until 12 October 2007.


    SOA India 2007 (http://www.soaindia2007.com) will also feature two half-day workshops on SOA Governance (by Keith Harrison-Broninski) and SOA Architecture Deep Dive (by Jason Bloomberg). If you are an IT manager, software architect, project leader, network & infrastructure specialist, or a software developer, looking for the latest information, trends, best practices, products and solutions available for building and deploying successful SOA implementations, SOA India 2007’s technical track offers you immense opportunities.


    Speakers at SOA India include:


    • Jason Bloomberg, Senior Analyst & Managing Partner, ZapThink LLC

    • Keith Harrison-Broninski, Independent consultant, writer, researcher, HumanEdJ

    • John Crupi, CTO, JackBe Corporation

    • Sandy Kemsley, Independent BPM Analyst, column2.com

    • Prasanna Krishna, SOA Lab Director, THBS

    • Miko Matsumara, VP & Deputy CTO, SoftwareAG

    • Atul Patel, Head MDM Business, SAP Asia Pacifc & Japan

    • Anil Sharma, Staff Engineer, BEA Systems

    • Coach Wei, Chairman & CTO, Nexaweb

    • Chaitanya Sharma, Director EDM, Fair Isaac Corporation


    A partial list of the sessions at SOA India 2007 include:


    • EAI to SOA: Radical Change or Logical Evolution?

    • BPEL: Strengths, Limitations & Future!

    • MDM: Jumpstart Your SOA Journey

    • Governance, Quality, and Management: The Three Pillars of SOA Implementations

    • Building the Business Case for SOA

    • Avoiding SOA Pitfalls

    • SOA Governance and Human Interaction Management

    • Business Intelligence, BPM, and SOA Handshake

    • Enterprise 2.0: Social Impact of Web 2.0 Inside Organizations

    • Web 2.0 and SOA – Friends or Foe?

    • Achieving Decision Yield across the SOA-based Enterprise

    • Governance from day one

    • Demystifying Enterprise Mashups

    • Perfecting the Approach to Enterprise SOA

    • How to Build Cost Effective SOA. “Made in India” Really Works!




    For more information, log on to http://www.soaindia2007.com (http://www.soaindia2007.com)


  • OO
    2007-06-13 04:17:56 loukik [Reply]

    Perhaps this article is quite dated. So my comments might not make much sense..anyway..


    I think the article is excellent in defining what SOA is. The only point that I disagree with is the OO analogy. Here is why:


    It looks like the author's perception of what an object is and what procedures are allowed seems to be different for the case of CDs. As CDs are good examples to showcase OO.


    If a music CD from a particular artist is an object, the data stored by this object is the actual music (stored in any format but a well defined one). The operations allowed on this data is to only read (in case of CD-r). The input for this operation is a track number and optionally a time pointer indicating where to begin on a particular track. The output for this operation is music data streaming (in a well defined format) which is understood by the one reading it.


    Extending it further...a music CD (.wav or whatever format) uses an interface definition which can be called as CD. (actually you can see many interfaces CD-R, CD-RW, etc).


    OO concept maps entirely to the concept of life (in my opinion). It is as simple as possible but not simpler (again, in my opinion)...


    Regardless of this "different perception", even 4 years, this article makes complete sense...


    Well written. I am part of the perfSONAR project and we are making good use of these concepts

  • Different from object oriented programming?
    2007-04-10 07:20:41 pad_rag [Reply]

    Whew! SOA is about providing reusable components, and components are a collection of reusable objects. SOA is a natural extension to O-O programming, not something different.


    O-O is about loose coupling (look at articles by the best Booch, Rumbaugh, Jacobson, etc.) and you'll know what I mean. O-O is about inheritance which is about generalization, and specialization, and is very similar to the generic semantics, and extensibility talks about.


    This is, by far, one of the poorest articles that I have read online. It appears to be an article from a very poor O-O programmer who wanted to publish something.


  • Wasn't it available before
    2007-02-23 13:54:39 Vinay_Taneja [Reply]

    Hi All,


    I am very new to SOA and just have the idea of it. All the articles I read I just could understand that it is just to setup a standard and passing the data in XML format.
    But can anybody tell me why to have a new standard when we have HTTP in place to pass the same type of data. It also supports session management and security(HTTPS) in a standard way.
    Its not like I am against the SOA but I feel we already have SOA implemented everywhere but we just need to make applications more structured to generate output of different type based on request.
    I feel the basic thing we assume that normal application design will generate html(written in JSP,ASP etc.) as an output which is for browser only but isn't it possible to send same data in form of any xml or other format generated by same JSP, ASP code. Afterall whatever data is being passed will have to be parsed to proper type at consumer end, because all is just array of char. And also in both the cases we need to tell the consumer about the data format needed to be transfered. I feel in same MVC approach if we have multiple selectable views(which can be selected based on request) to generate output in different format we can obtain integration between different applications following the same http protocol standards only. I mean what is the need of converting data to xml then set in http requst then on server take it from request then again unparse the xml then parse the output again in xml then add in response then take the data out from response at client and again unparse it from xml.


    • Wasn't it available before
      2008-04-30 02:56:50 need more knowledge [Reply]

      HTML tags are predefined In XML all wil be use defined.. ultimate aim of SOA is Provide service to requested and eligibe person or organisation.
      XML is common language. if we use this world wide we can share the services. If u want more detail ask me if my answer is not enough.

  • Great article that explains SOA
    2007-02-19 06:21:32 amarakrishna [Reply]

    This is great article that gives good understanding of the concept. But, I think CD analogy to explain difference between SOA and Object Oriented needs to be changed. As an Object Oriented designer, i would not write behavior to play on CD class. That is creating other problems that you referred as artificial dependency. You should always have CD player. Object oriented design teaches to relate objects with real world, it teaches lot of reuse.


    Otherwise, Article has great information.


    Srikrishna

    • Great article that explains SOA
      2007-02-27 02:13:11 technoguru [Reply]

      Well I think you have got it wrong. The author tries to explain with the CD example that in OOPS, you have data and the code that processe the data together (fileds and methods in a class) equating this with the example you have a CD and a designated CD player. As opposed to SOA you have generic form of data and the code i.e. a CD (data) that can be played on any player (code).


      • Great article that explains SOA
        2007-05-16 00:14:52 SankDaDevil [Reply]

        When I create my CD class, I have CD related data and methods operating on that data. Essentially, I am not binding my CD to a Player!!! I am just exposing an interface for CD players to use!!!


        SO IT SEEMS, YOU MISSED THE POINT OF O-O Programming!!! OOPS rightly teaches the Generalization-Specialization mechanism of software development which is in essence the basis for SOA!!!


        Regards,
        Sank.

  • Great one
    2006-05-10 21:35:00 vamsiev [Reply]

    This is a good article for starters on SOA.What i liked the most is the how web services were categorized and presented in the context of SOA.


  • CD Analogy
    2006-04-12 17:44:41 KevinRath [Reply]

    I think he had the right idea on the CD Analogy but ended up getting a little mixed up. Sorry this is going to be long winded, but needs to be to make my point.


    A CD in its simplest terms holds data (1s and 0s). What type of data that CD holds is what defines it. Maybe it holds standard music data or maybe MP3 music or video data.


    In the OO world this "could" require several objects to in turn present the data(i.e. MP3 object, video object, music object). A big benefit of OO is the ability to use Interface Polymorphism which allows you to take seperate yet similar objects and make them look the same and expose similar methods and properties: Call this an IDataType object which exposes a Read method. Your CD Player which the CD has been inserted into can now invoke just one object of type IDataType to read the data from the CD in the CD Player(as all the datatypes will have some sort of read method to expose).


    The limitation of the above concept is you are now restricted to the platform and possibly programming language. This means the only way you can use those objects and interfaces is if your CD is being played in a CD Plyer. The interface and objects above were built to talk to a CD Player. Say you wanted to play that CD in a portable CD Player. If that Portable player is built on the same platform you can potentially reuse those objects and interfaces. But what if you wanted to play that CD in a DVD player which is a totally different platform (like comparing windows to linux).


    This is where web services come in and remove that dependency on hardware and programming languages. Web Services through the use of XML and SOAP protocols have the ability to communicate amongst any platform and programming language.


    Because the web services aren't worried about platform we have now removed that dependency meaning we are now more loosely coupled. SOA leverages the use of web services as a means of communicating with other systems so anyone can send in data and not have to worry where it is coming from.


    Hopefully I am not too confusing and I have got the right concept here.

  • Excellent Article
    2006-04-11 07:17:20 DanielR [Reply]

    This is an excellent article for understanding the concept of SOA. The difference between OOP and SOA is data encapsulation and data independence, which is a good point.

  • Defining Service Oriented Architecture
    2006-04-10 02:39:35 aksbh [Reply]

    The loose coupling between interacting software agents in order to preserve the benefits of reusability and extensibility does not come in confict with Object Oriented System design in any manner. CD player analogy used in explaining the SOA in not so comprehensible, otherwise the artical is extremely informative and useful.Creating generic interfaces as far as possible in order to channelize the distributed capabilities that may be under the control of different ownership domains in accordance to the business rules seems to be the exact idea behind SOA.


    Regards,
    Akshaya Bhatia




    • Defining Service Oriented Architecture
      2006-04-28 11:06:56 Nickull [Reply]

      There is a Reference Model for SOA available as a candidate standard within OASIS. Over 200 people worked on this - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

      • Defining Service Oriented Architecture
        2006-04-29 10:07:20 aksbh [Reply]

        What exactly will be the goal of SOA reference model?


        Will it create templates and policies on the architecture for the distinct services-- Meaning-- will it take the service or the system per-se to layout such reference model---for instance Will reservation service be the starting point or will the segment using the reservation system as the service will be reference to start with?


        What exact purpose SOA reference model serve?
        Whether it would let us comprehend the exact definition as well as approach to SOA-both in terms of design and development?


        Is this reference model an endeavor to standardize the SOA for design,development and implementation in the cross section of industry segments?


        regards
        Akshaya Bhatia


  • SOA and Object Oriented Architecture
    2006-02-14 09:32:10 Saumitra [Reply]

    I have read this article extremely keenly but I could not quite grasp the difference between SOA and Object Oriented Design.


    IMHO, OO and SOA work at a different level of abstraction so cannot be compared at all! You can obviously have SOA implemented on non OO applications, whilst you can implement the same applications using OO (with all its inherent benefits!) and confirm to SOA!


    Unless I have got this completely wrong, I think OO is at a lower level of abstraction than SOA and hence any comparisons bewteen the two will give rise to the wrong views!


    cheers


    Saumitra

    • SOA and Object Oriented Architecture
      2006-04-08 04:32:09 nboddu [Reply]

      SOA <---> OOP


      Looks like the author and some of the reviewers are missing certain some key points of discussion.


      It is obvious that SOA and OOP operate at very different levels of abstractions as well as cater for two distinct needs. Incidentally, both the service-consumer, the service-provider could built their agents entirely adhering to OO paradigms.


      Other key point missed in the discussion is that considering "passing data to a system" NOT OO. That is not true. In OO paradigm, passing data to an external system (perhaps in form of an object or in form of a primitive) is still considered perfectly OO.


      Nevertheless, it’s a good article for a beginner.


      -Navin


    • SOA and Object Oriented Architecture
      2006-04-06 13:19:29 drencrom [Reply]

      I think you are right. SOA and OOP is not comparable. I think you can compare it to CORBA or DCOM because its also the try to build flexible components only 10 years later :-). OOP is about building Software at all. I can write a SOA architecture by using OOP or procedural programming. SOA is about building interfaces or components! But still nice article!
      cu

    • SOA and Object Oriented Architecture
      2006-03-20 07:42:59 mahesh75 [Reply]

      One important difference is that in OO we abstract state as well as behaviour but SOA talks only of abstraction of behaviour through services.


      State is kept separate.


      I would say its like SessionFacade pattern

    • SOA and Object Oriented Architecture
      2006-02-26 06:08:27 vdhreddi [Reply]

      Simplest example of SOA and OOPs diiference can be explained as ...
      In OOPS we generally protect the objects Database. for that case one keep the methos Private and use interfaces to access them... where as in SOA concept to use SOAP, one need to declare a method as public so that it can be accessed over web by other apps or client. SOA intends to simplify service usages.

  • An outsider's observation on the OO issue
    2006-02-08 00:08:46 lncook [Reply]

    So is the CD analogy accurate, loosely accurate, or totally incorrect in this case? I'm not a programmer, just a marketing guy who's trying to get proper perspective on our company's technology.


    I understand the CD analogy, but some are saying it's way off base. As an outside department that just needs a bird's-eye view of the technology, does the any-CD to any-player analogy appropriately describe web services?


    Thanks for the reply.

  • Good Article
    2006-01-31 16:57:00 krector007 [Reply]

    The explanation of real versus artificial dependencies was helpful. The OO analogy was (as many people pointed out) not accurate. The concept of loose coupling has been around since the late 70's ( see Tom DeMarco's Structured Analysis) and is just as significant today as it was then.


  • 2006-01-26 00:57:24 tristram_ [Reply]

    Excellent article on SOA. Unfortunate about the poor OO comparison but nothing major. Let's face it, if the article was about cars, who cares if the author doesn't know much about bikes as long as he doesn't dwell on it?

  • very good article !
    2006-01-11 04:20:06 riad18 [Reply]

    HI ,
    I a writing a paper about SOA.May i use your article in my paper ?
    thanks & best regards


    riad


  • Poor OO analogy
    2005-12-13 13:43:33 ravs [Reply]

    "The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems"


    I would have to disagree with the author's analogy of OO programming (actually modelling). OO bind's data and its behaviour together, not its processing. They are different things. And SOA and OO techniques are not at odds at all.

  • SO and OO - In this article
    2005-12-09 00:11:43 virinchi [Reply]

    I had some mixed feelings about this article. SOA part is quite simply described and am happy for that. But the CD and CD player example, is not fairly matching good OO.It would have helped the author to win more, if he would not have given that example. Anyway, some learning is always good and no one is perfect !!!


    Karthik Banda

  • Great Article
    2005-12-02 15:10:03 Motorstreak [Reply]

    A great article that explains SOA in a very simple manner. Saw some people crib about the CD example! As Eric pointed out, you guys are mssing out the author's point of view in using such an example. No need to jump into what OO is and all the crap around it. The example is perfect for those who only need to understand what SOA is and is not.

  • Bravo !
    2005-10-27 22:12:56 RizwanNawaz [Reply]

    Hi !


    This is an excellent article which clear all of my concepts regarding Web Services,WSDL,SOA,SOAP,REST and last but not the least Loose Coupling. These are mixed into one another. So i would like to thank Hao He for writing such a superb article.


    Thanks


  • CD Analysis
    2005-08-31 06:31:19 ewhipple16 [Reply]

    I don't know what everyone's freaking out about. You're so caught up on OO definitions that you're completely missing the author's point which is from a service oriented perspective, not an object oriented one. I don't have a problem with the analogy at all.


    -Eric

  • SOAP web services
    2005-08-10 16:08:26 jeffatncx [Reply]

    Granted, I am new to all of this, but need to learn in a hurry. In this article, SOAP is broken down into two types, RPC and document centric. I am afraid I do not understand how to tell the difference.. Is there some way to determine which of these types is being used by looking at the XML or is the "type" determined by the way that the SOAP is used?
    Thanks
    Jeff

  • CD analogy
    2005-07-28 16:44:36 mmnaqvi [Reply]

    It is pretty evident that most of the readers have disagreed on the matter of CD analogy presented in this article. However what suprises me is that the author seems too knowledgeable to misunderstand (deliberately??!!) the OOP concepts.

  • Difference
    2005-07-22 04:32:39 ca0725 [Reply]

    Hi, the article is very intersting. But i'm confused with other term such EAI. What is exactly the difference between EAI and SOA?


    Thanks

  • OOPs: thats not how should CD work
    2005-06-28 13:33:25 rc_129 [Reply]

    Probably you may have define correctly OOP but the example of CD is not good. If program is design with the CD concept (Player is part of CD itself) then its not a good OOPs design. Like SOA, OOPs also define that each entity should be independent and should do only what is suppose to do. With your logic, in .Net we should not have DataGrid and DataSource separate objects.


    Anyway, overall the article gives good idea about SOA.

  • Comparison with OO-techniques
    2005-06-13 00:44:06 shOOt [Reply]

    The CD-comparison of the author just proves, that he has not understood the concepts of OO at all!!! In OO the CD and its player must not come together, the player can be coupled abstractly to the CD with an interface, which allows to bind ANY (implementing) CD-player to the CD - that is loose coupling! Additionally there exist many software developing techniques like n-tier, layering, ... and patterns widely spread in OO-projects, which allow separating data from their handling!

  • Excellent
    2005-05-31 05:00:54 ASP.NetArticles [Reply]

    Hi,
    The article is excellent.




    Regards
    R.Ramesh babu

  • Geat article
    2005-02-03 22:11:19 john_davis [Reply]

    It is great article. It put world to my thoughts. I need to write a document that explains loose coupling between components in an application. Do you mind if I use some paragraphs and analogies from the article?


    Thanks…John


    • Geat article
      2005-02-04 00:08:54 Hao [Reply]

      Of course, not. Feel free to use it but I do appreciate if you could provide a link back to this article.


      Hao

  • Nice concise definition of loosely coupled
    2004-12-20 08:56:08 spamnomag [Reply]

    I very much liked the defintion of loosely coupled stated in terms of real and artificial dependencies. I'd not heard it stated in quite that way before and I think it will be very useful in discussions with other members of our team.


    Thanks,


    Brian Horblit


  • CD analogy
    2004-11-09 13:45:40 _nyirenda [Reply]

    I dont agree with your object oriented example of a cd having to play itself. The way I have seen it done; and the way I have always done it is to seperate concerns. So I would pass my cd object to a cd player object and he does the business of playing the cd. SOA is an extension of this concept but done in a distributed and federated manner and across process boundaries.


    Joseph Nyirenda

    • CD analogy
      2004-12-20 08:26:22 spamnomag [Reply]

      I must agree. In OO objects are responsible for their own state. That does not imply that for each instance of data you wish to process, you need a dedicated instance of an object to process it. If there is some extra data the player needs to play the CD (like track number, position of read head, etc) the player is responsible for maintaining that data and it should not be directly manipulated by external objects. The CD itself, which is the payload of a "play" message to the player, could be considered transient state for the player, and (typically) should not be manipulated by external objects while it is being played by the player. So in a sense OO says objects "encapsulate data" as apposed to the data being permanently bound to the object.


      • CD analogy
        2005-11-22 03:00:10 MuhammedShakir [Reply]

        Excellent explanation defending OO approach. You have perfect knowledge of OO

      • CD analogy
        2005-02-23 16:19:06 idol [Reply]

        Maybe I'm missing the point here about OO but I thought there was a clear seperation between the Class (the code, the player) and the instance (the data or CD). There is only 1 class and 1 copy of the code, but there are many sets of data. You can serialize the data out (take the CD out of the player) and transfer it to another player that accepts the serialized stream (put the CD in a DVD player or another brand) I will agree that there has not been a lot of work on standardizing the serialized stream of objects but that is the same as the RPC argument around SOAP. The implementation of OO in Java and C++ is only very basic compared to the original OO architecture and languages like SmallTalk. History repeats itself and we are re-inventing some of the original principles of OO just using XML to serialize data. The fundamental problem that we don't understand the meaning of the data outside of the object is not solved by SOAP but hinted at with REST: include a description of the data in the message. However we will overlook that feature since we all now what the data means.... have another Tui (Which here in NZ means Yeah Right! See it does help to explain.)

  • SOA article
    2004-06-18 20:45:26 oobie [Reply]

    Excellent. Very pertinent to current inet tech trends.


    Tony

    • SOA article
      2005-03-21 04:44:24 agrawal [Reply]

      hi,
      i am Arpit i m computer science student in BANGLORE,INDIA
      i went through artical and i went to use it for my academic seminar.
      can i use it and if you have more matarial on SOA
      plz mail me

      Thanks and Regards
      Arpit Agrawal


  • Best Practices
    2004-05-17 13:52:33 Backbone [Reply]

    Can you point me in a direction to acquire some SOA best practices? I am particularly intrested in the security aspects associated with SOA.


    • Best Practices
      2004-08-15 23:30:07 Hao [Reply]

      I just wrote this article: http://www.xml.com/pub/a/2004/08/11/rest.html , which might be helpful.

    • Best Practices
      2004-08-15 23:29:34 Hao [Reply]

      I've just wrote this article: http://www.xml.com/pub/a/2004/08/11/rest.html , which might be helpful.

    • Best Practices
      2004-07-04 09:13:37 Titi [Reply]

      A nice paper on different views on Service-oriented desing can be fount at http://sky.fit.qut.edu.au/%7Edumas/MultiViewpointSoD.pdf
      I hope it helps...

  • Very Good article
    2004-03-12 04:56:44 Chethan Sharma [Reply]

    The analogies provided are excellent in understanding the fundamental need for services.

  • Alternative Definition of Services
    2004-01-23 09:02:21 Carlos Perez [Reply]

    Here's an alternative definition of "Services" that I came up with: http://www.manageability.org/blog/stuff/what-is-a-web-service/view




    • Alternative Definition of Services
      2005-09-03 05:36:09 Fatal_Error [Reply]

      cheers
      the article is good
      but as with some of the others i must disagree with the CD player analogy
      I agree with shOOt's reply on this