Loading ...
Sorry, an error occurred while loading the content.
 

SOA: a Software AG perspective

Expand Messages
  • Gervas Douglas
    Message 1 of 9 , Aug 1, 2003
      <<SOA will likely prevail because it is based upon Web services, and
      the primary technology standard supporting Web services is XML. Even
      Microsoft recently proclaimed that XML is the most important standard
      in the next 10 years. Every document created in .NET is in XML. And
      major vertical industry data standards are also now organizing around
      XML: HL7 in healthcare, SWIFT in banking, CIDX in chemicals and
      Rosettanet in high tech, among others.>>

      Is this yet another case of confusing SOA with WS?? To be fair to
      Bill Ruh of Software AG he does start the article by writing:

      <<The organization able to correctly identify the winners and losers
      among evolving technologies will benefit from lower cost of
      operations, reduced complexity of the computing environment and
      improved readiness to respond to new business requirements. What
      characteristics make Service Oriented Architecture (SOA) one of those
      technologies destined to survive, and how can SOA be successfully
      implemented?

      <<Technology pundits like to talk about SOA as if it were a new idea.
      But seasoned technology practitioners know better. SOA is really the
      latest stage in a gradual evolution of ideas that began in the early
      1980s within the Object Oriented Programming community, and continued
      into the 1990s in other communities such as DCE, COM/DCOM, CORBA and
      J2EE.>>

      So he obviously realises SOA predates WS unlike many early WS
      proponents. However, there is yet again this assumption that SOA
      will ineluctably go down the WS/XML route. Personally I feel WS will
      succeed eventually at least for certain applications if only because
      the Big Boys are investing so much money, effort and credibility in
      it. XML is looking increasingly like the lingua franca of data.
      That stated, this does not logically exclude other future SOA
      implementations.

      You can find the article at:

      http://zdnet.com.com/2102-1107_2-5058101.html?tag=printthis

      Gervas
    • Steve Craggs
      Gervas, I agree entirely. To suggest that Web Services and SOA are the same thing is not true. There are plenty of people with SOA implementations today (for
      Message 2 of 9 , Aug 1, 2003
        Gervas,
         
        I agree entirely. To suggest that Web Services and SOA are the same thing is not true. There are plenty of people with SOA implementations today (for example Enterprise Service Bus (ESB) solutions) who are quite happy with what they have.
         
        Web Services are fine for what they are. A set of services that make it easier to find and connect to a service. There are other aspects of SOAs that web services specs do not cover in themselves.
         
        Steve Craggs 
        ----- Original Message -----
        Sent: Friday, August 01, 2003 4:54 PM
        Subject: [service-orientated-architecture] SOA: a Software AG perspective

        <<SOA will likely prevail because it is based upon Web services, and
        the primary technology standard supporting Web services is XML. Even
        Microsoft recently proclaimed that XML is the most important standard
        in the next 10 years. Every document created in .NET is in XML. And
        major vertical industry data standards are also now organizing around
        XML: HL7 in healthcare, SWIFT in banking, CIDX in chemicals and
        Rosettanet in high tech, among others.>>

        Is this yet another case of confusing SOA with WS??  To be fair to
        Bill Ruh of Software AG he does start the article by writing:

        <<The organization able to correctly identify the winners and losers
        among evolving technologies will benefit from lower cost of
        operations, reduced complexity of the computing environment and
        improved readiness to respond to new business requirements. What
        characteristics make Service Oriented Architecture (SOA) one of those
        technologies destined to survive, and how can SOA be successfully
        implemented?

        <<Technology pundits like to talk about SOA as if it were a new idea.
        But seasoned technology practitioners know better. SOA is really the
        latest stage in a gradual evolution of ideas that began in the early
        1980s within the Object Oriented Programming community, and continued
        into the 1990s in other communities such as DCE, COM/DCOM, CORBA and
        J2EE.>>

        So he obviously realises SOA predates WS unlike many early WS
        proponents.  However, there is yet again this assumption that SOA
        will ineluctably go down the WS/XML route.  Personally I feel WS will
        succeed eventually at least for certain applications if only because
        the Big Boys are investing so much money, effort and credibility in
        it.  XML is looking increasingly like the lingua franca of data. 
        That stated, this does not logically exclude other future SOA
        implementations.

        You can find the article at:

        http://zdnet.com.com/2102-1107_2-5058101.html?tag=printthis

        Gervas





        To unsubscribe from this group, send an email to:
        service-orientated-architecture-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Jeff Schneider
        ... I would disagree. SOA has been well defined long before web services - from a technical perspective. What is wrong with the traditional triangle
        Message 3 of 9 , Aug 2, 2003
          >Anyway, both SOA and WS are primarily marketing terms rather than technical
          >terms at this point.
          I would disagree. SOA has been well defined long before web services - from
          a technical perspective. What is wrong with the traditional triangle
          definition:
          (Producer, Consumer, Directory)? Seems like a pretty traditional
          architectural
          pattern to me.

          >I spent most of this week working with the Web
          >Services Architecture group at W3C trying to distill out the technical
          >essence from the hype-speak to rigorously define what a "service" and a
          >"web
          >service" really is. It's not fun.

          This is one problem with the w3c. The fact that the w3c can't figure it out
          means very, very little to me. As the members of the w3c stumbles over their
          egos, Microsoft and IBM will give you nice definitions. You will be able to
          look
          them up at http://www.ws-i.org It is August of 2003, many of the base
          web service specs are already in 2nd or 3rd versions. Does it seem like an
          odd time for the w3c to be determining the 'essence' of web services?

          >Someone quipped that a "service" (in the
          >SOA sense or the web service sense) is like pornography -- you know it when
          >you see it, but it's pretty hard to define.

          Perhaps you should eject this person from future meetings - sounds like you
          could
          have more productive conversation without this individual. It is sad when a
          person
          uses the pornography opt-out. It is a bullshit cry - what it really means
          is: "I'm
          a moron, and I haven't bothered to figure it out." Eject this person and you
          will
          likely have more productive meetings.

          Perhaps I'm in a bad mood and shouldn't be so harsh. Many of my customers
          have already rolled out service networks and have web services as a
          important
          piece of their architecture. Thus the questions you pose seem a bit *late*.

          _________________________________________________________________
          Add photos to your messages with MSN 8. Get 2 months FREE*.
          http://join.msn.com/?page=features/featuredemail
        • Jeff Schneider
          ... Agreed. Let s go with the standard definition then - the architectural pattern - which was defined a long, long time ago. SOA = Producer, Consumer,
          Message 4 of 9 , Aug 3, 2003
            >But that's the problem illustrated by this very thread: you can't beat up
            >on
            >someone for using terminology in a non-standard way unless there is a
            >standard definition.
            Agreed. Let's go with the standard definition then - the architectural
            pattern -
            which was defined a long, long time ago. SOA = Producer, Consumer,
            Directory.


            >Consider the various definitions of "SOA" -- is a service a "component" or
            >"object" with a coarse-grained, business-level interface? a vendor of
            >distributed object software and SOA is just a best practice
            >guideline, but this is problematic if you are a RESTifarian. Does it
            >imply
            >XML or Web standards compliance? Sure, if you're an XML or Web vendor, not
            >necessarily if you are an ORB vendor. Does it imply flexibility in the
            >face
            >of loose or evolving definitions of the service interface? Sure, if you're
            >the developer of a tool that uses XPath or some other flexible
            >pattern-matching / query / transformation language, probably not if you
            >have
            >a schema-based databinding technology. Does it imply loose coupling in
            >time
            >as well as space? Sure, if you're the vendor of a tuplespaces-like
            >technology that allows producers and consumers to find each other even if
            >they are not online simultaneously... etc. etc. etc.
            >
            >So sorry, but one person's "stumbling over egos" is another person's
            >principled argument based on obvious realities.

            We'll have to agree to disagree. The obvious realities that you are speaking
            about are legacy companies inability to move into service oriented world and
            their desire to resurface their company to 'look' service oriented. This is
            a marketing problem and shouldn't leak into the technical discussion.

            What is SOA? It is an architectural pattern defined many years ago.
            Does it have to be coarse grained? Nope, but it may help performance.
            Does it have to use XML? Nope, but it may help interoperability.
            Does it imply loose coupling? It makes the attempt, but a bad design can
            screw it up.

            SOA = Producer, Consumer, Directory.

            I'm on the record for *my definition*. I wrote it down a long time ago:
            http://www.serviceoriented.org/service_oriented_architecture.html
            Feel free to pull it apart. If I missed something, I'll gladly change it.
            Until then, Producer, Consumer, Directory. Producer, Consumer, Directory.
            :-)

            Jeff

            _________________________________________________________________
            Protect your PC - get McAfee.com VirusScan Online
            http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
          • Jeff Schneider
            ... I just ran into this definition of SOA. You might like it since it is from the W3C. http://www.w3.org/TR/2002/WD-ws-arch-20021114/#basic So, if you d
            Message 5 of 9 , Aug 3, 2003
              > >But that's the problem illustrated by this very thread: you can't beat up
              > >on
              > >someone for using terminology in a non-standard way unless there is a
              > >standard definition.
              >Agreed. Let's go with the standard definition then - the architectural
              >pattern -
              >which was defined a long, long time ago. SOA = Producer, Consumer,
              >Directory.

              I just ran into this definition of SOA. You might like it since it is from
              the W3C.
              http://www.w3.org/TR/2002/WD-ws-arch-20021114/#basic

              So, if you'd prefer, we could call it: Provider, Discoverer, Requester.
              It's the same triangle. I'm happy either way.

              _________________________________________________________________
              The new MSN 8: advanced junk mail protection and 2 months FREE*
              http://join.msn.com/?page=features/junkmail
            • Sean McGrath
              [Jeff Schneider] ... And the normative reference for this definition is? At least if we all agree where there authoritative definition is, we can tear apart
              Message 6 of 9 , Aug 4, 2003
                [Jeff Schneider]

                >What is SOA? It is an architectural pattern defined many years ago.

                And the normative reference for this definition is?

                At least if we all agree where there authoritative definition is, we can
                tear apart
                the same carcas.

                Life is too short to read everything produced by analysts but I'd be pretty
                confident that
                even at this early stage, there are multiple, conflicting definitions from
                analysts.

                Many successful acronyms develop a set of 'strange attractors' and commentary
                that revolves around each of them.

                An unfortunate side-effect of coalescing on a single definition is the
                tendancy towards
                semantic entropy death. i.e. a 'definition' that is nothing but a bunch of
                'may or may not'
                statements that is essentially meaningless.

                Sean
              • David Forslund
                This has been updated with the latest WebServices document. on w3c, and has been further refined. Basically the SOA definition is very old. It is the core of
                Message 7 of 9 , Aug 4, 2003
                  This has been updated with the latest WebServices document. on w3c, and has been further refined. 
                  Basically the SOA definition is very old.  It is the core of the ISO RM-ODP effort and is the fundamental
                  business model of the OMG in the development of all of their various services.   WebServices is just the
                  latest incarnation of this idea.  The SOA design pattern is really ubiquitous.

                  You might also note in this W3C document the description of where REST fits in.

                  Dave

                  Jeff Schneider wrote:
                    
                  But that's the problem illustrated by this very thread: you can't beat up
                  on
                  someone for using terminology in a non-standard way unless there is a
                  standard definition.
                        
                  Agreed. Let's go with the standard definition then - the architectural
                  pattern -
                  which was defined a long, long time ago. SOA = Producer, Consumer,
                  Directory.
                      
                  I just ran into this definition of SOA. You might like it since it is from 
                  the W3C.
                  http://www.w3.org/TR/2002/WD-ws-arch-20021114/#basic
                  
                  So, if you'd prefer, we could call it: Provider, Discoverer, Requester.
                  It's the same triangle. I'm happy either way.
                  
                  _________________________________________________________________
                  The new MSN 8: advanced junk mail protection and 2 months FREE*  
                  http://join.msn.com/?page=features/junkmail
                  
                  
                  
                  ------------------------ Yahoo! Groups Sponsor ---------------------~-->
                  Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
                  http://www.c1tracking.com/l.asp?cid=5510
                  http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/NhFolB/TM
                  ---------------------------------------------------------------------~->
                  
                  To unsubscribe from this group, send an email to:
                  service-orientated-architecture-unsubscribe@yahoogroups.com
                  
                   
                  
                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
                  
                  
                    
                • Jeff Schneider
                  ... Agreed. You re hitting a great point. Most people that use services tend to use only two nodes of the three node triangle. Thus, if only two nodes are
                  Message 8 of 9 , Aug 4, 2003
                    >The problem I have with this (after listening to people argue about it for
                    >a
                    >year) is that the "Directory" leg of the canonical triangle is a bit vague.
                    >AFAIK there are very few real-world services in which the Consumer
                    >dynamically or automatically discovers the Producer. The "Directory" is in
                    >fact an abstraction for all sorts of things that ensure that producers and
                    >consumers agree on service interfaces, especially including phone calls,
                    >exchanges of documents via email or sneakernet, etc. I have been assured
                    >by
                    >the Big End-User Companies on the W3C WSA WG that the very idea of finding
                    >a
                    >service producer via an automated means is absolute anathema to their legal
                    >and business people. Those EDI, B2B, and Web services interactions that
                    >they do are in a very real sense an implementation of SOA, but the
                    >consumers
                    >and producers generally have a long-standing and/or human-defined business
                    >messaging relationship. Thus, I believe that it's hard to make the
                    >Directory
                    >a part of the core definition of SOA without either making the term
                    >"Directory" so vague as to be meaningless or by making SOA's that meet a
                    >rigorous definition an extreme rarity in the business world.
                    >
                    >Thoughts?

                    Agreed. You're hitting a great point. Most people that use services tend to
                    use
                    only two nodes of the three node triangle. Thus, if only two nodes are
                    *needed*,
                    then can we scope down the definition? My answer is, you could, but then it
                    wouldn't be a service oriented architectural pattern. You would be closer to
                    a
                    pipe & filter pattern. Nothing wrong with that - just a different term &
                    meaning.

                    "Service Oriented" is a broad term - in the web service implementations that
                    we
                    have been doing, we use a combination of patterns, including:
                    - SOA (Directory, Producer, Consumer)
                    - Pipe to Pipe (Service to Service, no directory, no filter)
                    - Pipe & Filter (Service to Transform to Service)
                    - SOA Pipe & Filter (Directory gets Service, Directory gets Transform,
                    Directory gets Service)

                    We also see various physical topologies:
                    - Centralized orchestration (bpel-ish)
                    - Point-to-Point (or peer to peer, if you prefer)
                    - Combinations, hybrids... (super-peer, etc.)

                    As we (OpenStorm), begin writing more complicated bpels, we are seeing
                    combinations of
                    every pattern mentioned here - a single orchestration that leverages a
                    directory for some
                    services, while not for others - ones that just pipe data from one service
                    to the next,
                    steps that perform transforms - sometimes the *logic* is centralized other
                    times it is
                    decentralized.

                    If I understand your point, you are saying - "I could design an entire web
                    services
                    architecture and NEVER come across the SOA pattern" - This, I would have to
                    agree with. (Not that it SHOULD be this way, but in some cases it just
                    might)

                    So, my earlier problem was in the loose terminology related to SOA. Perhaps
                    we
                    could re-spin the problem? Instead, does it make sense to aggregate the
                    architectural patterns that are 'service based'. Thus, knock out a list of
                    'GOF like' architecutral patterns dealing with the different patterns found
                    in
                    architectures that highly leverage services?

                    _________________________________________________________________
                    Tired of spam? Get advanced junk mail protection with MSN 8.
                    http://join.msn.com/?page=features/junkmail
                  • Steve Craggs
                    I must admit, the Directoty bit is rather frightening when u think of SOAs beyond the corporate boundary. Actually, I am unfamiliar with this abstract way of
                    Message 9 of 9 , Aug 4, 2003
                      I must admit, the Directoty bit is rather frightening when u think of SOAs beyond the corporate boundary. Actually, I am unfamiliar with this 'abstract' way of looking at SOAs so I am learning a lot. I always look at SOAs as practical implementations of the business service model of operations, usually (in fact in my own experience almost exclusively) used by companies internally. Also, the Directory concept is weak in an internal case - often people use publish/subscribe as a way of being triggered when the service they want is available - this is not what most people think of as a Directory.
                       
                      I wrote a paper about 6 years ago about SOAs in praqctical terms, but in the light of these complex discussions it seems a bit naive now :-)
                       
                        Steve Craggs
                       
                      ----- Original Message -----
                      Sent: Monday, August 04, 2003 4:28 PM
                      Subject: RE: [service-orientated-architecture] SOA: a Software AG perspective

                       
                      -----Original Message-----
                      From: David Forslund [mailto:forslund@...]
                      Sent: Monday, August 04, 2003 10:44 AM
                      To: service-orientated-architecture@yahoogroups.com
                      Subject: Re: [service-orientated-architecture] SOA: a Software AG perspective


                      Basically the SOA definition is very old.  It is the core of the ISO RM-ODP effort and is the fundamental
                      business model of the OMG in the development of all of their various services.  
                       
                      I'd appreciate a specific citation of this.  Wearing my W3C hat, it would be GREAT to have an authoritative definition of "service" to point to.
                      Agreed. Let's go with the standard definition then - the architectural
                      pattern -
                      which was defined a long, long time ago. SOA = Producer, Consumer,
                      Directory.
                           
                      The problem I have with this (after listening to people argue about it for a year) is that the "Directory" leg of the canonical triangle is a bit vague.  AFAIK there are very few real-world services in which the Consumer dynamically or automatically discovers the Producer.  The "Directory" is in fact an abstraction for all sorts of things that ensure that producers and consumers agree on service interfaces, especially including phone calls, exchanges of documents via email or sneakernet, etc.  I have been assured by the Big End-User Companies on the W3C WSA WG that the very idea of finding a service producer via an automated means is absolute anathema to their legal and business people.  Those EDI, B2B, and Web services interactions that they do are in a very real sense an implementation of SOA, but the consumers and producers generally have a long-standing and/or human-defined business messaging relationship. Thus, I believe that it's hard to make the Directory a part of the core definition of SOA without either making the term "Directory" so vague as to be meaningless or by making SOA's that meet a rigorous definition an extreme rarity in the business world. 
                       
                      Thoughts?
                       
                       
                       


                      To unsubscribe from this group, send an email to:
                      service-orientated-architecture-unsubscribe@yahoogroups.com



                      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                    Your message has been successfully submitted and would be delivered to recipients shortly.