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

Re: [service-orientated-architecture] Anne on DSPs

Expand Messages
  • Stuart Charlton
    ... your ... Agreed, though method centric is a bit dangerous to use, as even a uniform interface can be method centric (and HTTP s doing OK with it). ...
    Message 1 of 40 , Feb 29, 2008
      --- Nick Gall <nick.gall@...> wrote:

      > Stu,
      >
      > Your explanation is perfectly clear and I am in complete agreement,
      > except for a what I suspect is a terminological issue. Throughout
      your
      > explanation you attribute certain characteristics to WSDL that are,
      > in my opinion, more correctly attributable to a certain style of
      > architectural, which for the sake of this discussion I will call
      > "method-centric".

      Agreed, though "method centric" is a bit dangerous to use, as even a
      uniform interface can be "method centric" (and HTTP's doing OK with
      it).

      > My point is that there is nothing intrinsic in WSDL (at least 2.0)
      > that forces an interface designer to adopt a method-centric approach
      > to interface design (ie, as you put it "every possible access path
      > is an extra operation").

      The WSDL metamodel describes components that have operations with
      certain message exchange patterns. It is designed to encourage
      service producers to expose their own specific operations instead of
      adopting or conforming to existing semantics. I don't think this is
      condusive to evolvability for data services.

      I do agree that it is possible to design such service interfaces
      properly (i.e. there's nothing intrinsic that forces you to hang
      yourself), but like predecessor component models such as EJB, it will
      not be easy or widespread.

      In the case of a DSP, the alternative that would work in WSDL, to my
      knowledge, would be to describe one's own self-describing query service
      interface. (Which is what I sometimes recommend to people using
      AquaLogic DSP). It's not perfect: it at least insulates consumers
      from changes in the physical access paths, but at the cost of a more
      complex interface.

      > So when you originally stated "Relationships can't just
      > be housed in XSD, the traversals need to be noted in WSDL", I thought
      > you meant that the syntax and semantics of WSDL itself
      > required that all traversals be realized as WSDL operations,
      > ie that WSDL requires a method centric approach.

      Not required; but encouraged, and practiced by the vast majority who
      learned web service design with WSDL 1.1. I don't see this changing
      much with WSDL 2.0 in practice, because the metamodel is very similar,
      the primary differences are in the flexibility of what it can map to.
      It still tries to map message exchanges into component operations.

      > It is possible (though by no means
      > straight forward) to realize the REST architectural style using (some
      > of) the WS-* specs in the appropriate manner.

      Sure; we could do it with Java RMI and Jini too, or CORBA IIOP.

      > The real problem is that we have no agreed upon term to describe the
      > architectural style that is method-centric, uses static interface
      > descriptions, and has stateful application sessions, et al.

      I call it "RPC", but that's because I came from the dist-obj community.
      But you're right, I've seen MOM architectures that were just as
      static.

      > Terms like "RPC", "method-centric", "OO-like", "traditional
      > distributed middleware interfaces" don't really capture it, because
      > proponents of WS-* usually claim that they do not endorse
      > such failed styles.

      Firstly, I hesitate to call them failed. There will continue to be
      important systems built on these approaches for the forseeable future.
      The RPC will likely never die.

      Secondly, I do think many proponents continue embrace those styles,
      because they think that the whole notion of architectural styles are
      irrelevant to the problems they face.

      With regards to my first claim, the root problem is that many industry
      figures are looking for the "one true style" that will be the "End of
      History" and solve all enterprise integration and agility problems,
      rather instead of learning the heuristics and measures to balancing
      tradeoffs among a variety of styles. Some enterprise architects have
      jumped ahead of due diligence and assumed that WS-* "is it",
      recognizing it has growing pains and warts currently, but believing it
      will all work out in the end.

      On the other hand, I haven't actually seen an architectural style
      articulated from this audience, beyond "stateless client server" or
      "event based integration with self-description". I've tried among
      BEA's consultants, and often gotten blank faces until I suggested that
      SOA == the "null" style, at which point they all agreed -- and many
      thought it was a good thing that SOA had no architectural constraints
      (it's the End of History, after all!). We then contrasted the
      constraints of WS-* in practice vs. REST, in order to illustrate the
      trade-offs of loosely constrained vs. tightly constrained
      architectures.

      The closest I've seen to a description of a "good WS architectural
      style" is Jim Webber's MEST, described in his well received "Skinning
      an Internet-Scale Cat" presentations:
      http://qcon.infoq.com/sanfrancisco/presentation/A+couple+of+ways+to+skin+an+Internet-scale+cat

      ...and I'd note that he rejects WSDL due to what it encourages, in
      favour of a description language (SSDL) that encourages "message
      descriptions" instead of "component operation descriptions".

      To my second point, many WS-* proponents that I know embrace WSDL
      because they believe the source of problems of integration and agility
      have nothing to do with architectural styles. i.e. "SOA was
      completely doable with CORBA and COM, if you knew better."

      From this perspective, all of our agility and integration problems have
      to do with governance -- the "missing link" from CORBA, COM, etc.

      NOw while I do agree that restricting interfaces to use common
      semantics in a federation, for example, is a governance challenge, this
      easily leads down the "SOA == governance" path, wherein all technical
      arguments merely become fodder for IT power politics. Invoking
      "Governance will save us!" is sort of like an appeal to God. It might
      work if your faith and sacrifice is sufficient. :-)

      I fear that architectural styles are often relegated as a relic of a
      bygone era, with the future of networked systems architecture being all
      about message exchange patterns, policies, and the XML Infoset. I
      fear this not because it's true, but because so much money will
      continue to be wasted chasing this belief.

      > here is that REST is not fighting against any specific
      > architectural style -- it is fighting against an always moving
      > target: the shifting, ambiguous, ad hoc set of status quo interface
      > practices that have never been formalized into an architectural
      style.

      This I strongly agree with, which is why I wouldn't call a style
      "failed" so much as "inappropriate for the desired properties". :-)

      Unfortunately, most don't even grasp what an architectural style *is*
      let alone why they would want one. FWIW, this problem was discussed in
      Mark and my OOPSLA motivational paper:
      http://www.stucharlton.com/stuff/OOPSLA_2007_Paper.html

      I would also note there are so many specialties of architecture out
      there that architectural styles wind up targeted at only the "systems
      architect" subset, a role that is marginalized by higher paying
      "enterprise architect" or easier-to-find and more hands-on "application
      architect" positions.

      Cheers
      Stu
    • Stuart Charlton
      ... your ... Agreed, though method centric is a bit dangerous to use, as even a uniform interface can be method centric (and HTTP s doing OK with it). ...
      Message 40 of 40 , Feb 29, 2008
        --- Nick Gall <nick.gall@...> wrote:

        > Stu,
        >
        > Your explanation is perfectly clear and I am in complete agreement,
        > except for a what I suspect is a terminological issue. Throughout
        your
        > explanation you attribute certain characteristics to WSDL that are,
        > in my opinion, more correctly attributable to a certain style of
        > architectural, which for the sake of this discussion I will call
        > "method-centric".

        Agreed, though "method centric" is a bit dangerous to use, as even a
        uniform interface can be "method centric" (and HTTP's doing OK with
        it).

        > My point is that there is nothing intrinsic in WSDL (at least 2.0)
        > that forces an interface designer to adopt a method-centric approach
        > to interface design (ie, as you put it "every possible access path
        > is an extra operation").

        The WSDL metamodel describes components that have operations with
        certain message exchange patterns. It is designed to encourage
        service producers to expose their own specific operations instead of
        adopting or conforming to existing semantics. I don't think this is
        condusive to evolvability for data services.

        I do agree that it is possible to design such service interfaces
        properly (i.e. there's nothing intrinsic that forces you to hang
        yourself), but like predecessor component models such as EJB, it will
        not be easy or widespread.

        In the case of a DSP, the alternative that would work in WSDL, to my
        knowledge, would be to describe one's own self-describing query service
        interface. (Which is what I sometimes recommend to people using
        AquaLogic DSP). It's not perfect: it at least insulates consumers
        from changes in the physical access paths, but at the cost of a more
        complex interface.

        > So when you originally stated "Relationships can't just
        > be housed in XSD, the traversals need to be noted in WSDL", I thought
        > you meant that the syntax and semantics of WSDL itself
        > required that all traversals be realized as WSDL operations,
        > ie that WSDL requires a method centric approach.

        Not required; but encouraged, and practiced by the vast majority who
        learned web service design with WSDL 1.1. I don't see this changing
        much with WSDL 2.0 in practice, because the metamodel is very similar,
        the primary differences are in the flexibility of what it can map to.
        It still tries to map message exchanges into component operations.

        > It is possible (though by no means
        > straight forward) to realize the REST architectural style using (some
        > of) the WS-* specs in the appropriate manner.

        Sure; we could do it with Java RMI and Jini too, or CORBA IIOP.

        > The real problem is that we have no agreed upon term to describe the
        > architectural style that is method-centric, uses static interface
        > descriptions, and has stateful application sessions, et al.

        I call it "RPC", but that's because I came from the dist-obj community.
        But you're right, I've seen MOM architectures that were just as
        static.

        > Terms like "RPC", "method-centric", "OO-like", "traditional
        > distributed middleware interfaces" don't really capture it, because
        > proponents of WS-* usually claim that they do not endorse
        > such failed styles.

        Firstly, I hesitate to call them failed. There will continue to be
        important systems built on these approaches for the forseeable future.
        The RPC will likely never die.

        Secondly, I do think many proponents continue embrace those styles,
        because they think that the whole notion of architectural styles are
        irrelevant to the problems they face.

        With regards to my first claim, the root problem is that many industry
        figures are looking for the "one true style" that will be the "End of
        History" and solve all enterprise integration and agility problems,
        rather instead of learning the heuristics and measures to balancing
        tradeoffs among a variety of styles. Some enterprise architects have
        jumped ahead of due diligence and assumed that WS-* "is it",
        recognizing it has growing pains and warts currently, but believing it
        will all work out in the end.

        On the other hand, I haven't actually seen an architectural style
        articulated from this audience, beyond "stateless client server" or
        "event based integration with self-description". I've tried among
        BEA's consultants, and often gotten blank faces until I suggested that
        SOA == the "null" style, at which point they all agreed -- and many
        thought it was a good thing that SOA had no architectural constraints
        (it's the End of History, after all!). We then contrasted the
        constraints of WS-* in practice vs. REST, in order to illustrate the
        trade-offs of loosely constrained vs. tightly constrained
        architectures.

        The closest I've seen to a description of a "good WS architectural
        style" is Jim Webber's MEST, described in his well received "Skinning
        an Internet-Scale Cat" presentations:
        http://qcon.infoq.com/sanfrancisco/presentation/A+couple+of+ways+to+skin+an+Internet-scale+cat

        ...and I'd note that he rejects WSDL due to what it encourages, in
        favour of a description language (SSDL) that encourages "message
        descriptions" instead of "component operation descriptions".

        To my second point, many WS-* proponents that I know embrace WSDL
        because they believe the source of problems of integration and agility
        have nothing to do with architectural styles. i.e. "SOA was
        completely doable with CORBA and COM, if you knew better."

        From this perspective, all of our agility and integration problems have
        to do with governance -- the "missing link" from CORBA, COM, etc.

        NOw while I do agree that restricting interfaces to use common
        semantics in a federation, for example, is a governance challenge, this
        easily leads down the "SOA == governance" path, wherein all technical
        arguments merely become fodder for IT power politics. Invoking
        "Governance will save us!" is sort of like an appeal to God. It might
        work if your faith and sacrifice is sufficient. :-)

        I fear that architectural styles are often relegated as a relic of a
        bygone era, with the future of networked systems architecture being all
        about message exchange patterns, policies, and the XML Infoset. I
        fear this not because it's true, but because so much money will
        continue to be wasted chasing this belief.

        > here is that REST is not fighting against any specific
        > architectural style -- it is fighting against an always moving
        > target: the shifting, ambiguous, ad hoc set of status quo interface
        > practices that have never been formalized into an architectural
        style.

        This I strongly agree with, which is why I wouldn't call a style
        "failed" so much as "inappropriate for the desired properties". :-)

        Unfortunately, most don't even grasp what an architectural style *is*
        let alone why they would want one. FWIW, this problem was discussed in
        Mark and my OOPSLA motivational paper:
        http://www.stucharlton.com/stuff/OOPSLA_2007_Paper.html

        I would also note there are so many specialties of architecture out
        there that architectural styles wind up targeted at only the "systems
        architect" subset, a role that is marginalized by higher paying
        "enterprise architect" or easier-to-find and more hands-on "application
        architect" positions.

        Cheers
        Stu
      Your message has been successfully submitted and would be delivered to recipients shortly.