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

Re: [service-orientated-architecture] SOA Pizza Order Surprises

Expand Messages
  • Mark Baker
    ... It s not just you. In my estimation, the uniform interface is the greatest advance in the history of large scale distributed computing ... well, in
    Message 1 of 100 , Feb 24, 2007
    View Source
    • 0 Attachment
      On 2/23/07, Eric Newcomer <e_newcomer@...> wrote:
      >
      >
      >
      > It seems like on this thread, whatever the question, the answer is "uniform interface."
      >
      > Maybe it' just me.

      It's not just you. In my estimation, the uniform interface is the
      greatest advance in the history of large scale distributed computing
      ... well, in conjunction with standardized identifiers I suppose. So
      it's really no surprise that it's the answer to many questions. 8-)

      But FWIW, the uniform interface isn't the only way to get
      self-descriptive messages. If the interface is standardized then it
      is self-descriptive. That's why SOA/WS (and ONC, DCE, CORBA, DCOM,
      RMI et al) - which unapologetically do *not* constrain the interface -
      never had, and will never have, self-descriptive messages in the
      general case. It's the main reason we don't see those systems on the
      Internet.

      *ALL* Internet based systems have standardized operations. This is
      not a coincidence.

      Mark.
      --
      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
      Coactus; Web-inspired integration strategies http://www.coactus.com
    • Gregg Wonderly
      ... The HTTP operations, GET, PUT and DELETE do have more exact descriptions than POST. This is just an simplification of the interface that an HTTP client
      Message 100 of 100 , Apr 8 11:08 AM
      View Source
      • 0 Attachment
        Jan Algermissen wrote:
        > In RMI, I belive the client has very detailed expectations beyond
        > 'invoke' and it would lead to
        > many surprises if INVOKE( foo.getStockQuote) launches a missile, or?
        >
        > In fact, when you POST your order to e.g. Amazon, it would be perfectly
        > fine (from an HTTP POV)
        > for the server to launch that missile.

        The HTTP operations, GET, PUT and DELETE do have more exact descriptions than
        POST. This is just an simplification of the interface that an HTTP client would
        deal with. It indicates a more focused application group that HTTP can be used
        from. POST represents the generic "punt" that creeps into software when
        developers decide that they can't provide some needed functionality in an
        existing implementation. It's a very pervasive thing.

        The RMI INVOKE operation, as I said, is what allows the Java programmer to
        access remote objects with the same programming paradigms as they do local
        programming.

        I'm not sure that the 'launch a missle' example really applies here. Unless you
        wrote the software on the other end, you don't really know what happened. Even
        with GET, PUT and DELETE there's no guarantee about anything, we just have, as
        the greater software development society, largely been truthful, trustworthy and
        faithful, recognizing the benefits of that premise.

        > That is (and this is how this thread started, BTW) why it is so
        > important that what the client says
        > is self describing. - It keeps you from being responsible for that launch.

        The Java progamming language provides as much self description in the
        specification of an API design as any other textual representation of similar
        information. Developers describe their intent with software in whatever
        language they use. Currently, we don't have a silver bullet language that can
        provide any real guarantees about what happens remotely.

        However, the JERI stack, does include the ability for the client to assert
        contstraints that the server must meet. Those constraints are validated by the
        ProxyPreparer. The ProxyPreparer can be told to perform proxy verification.
        The existing implementation of this knows how to validate that the proxy
        verification is happening with the appointed classes from the desired class
        loader. Once the validation occurs, then the client can assume that the proxy
        preparation included validation of the specified constraints which includes
        thigns like server authentication (Kerberos or X.500 types of things), proper
        integrity of the downloaded classes (httpmd: protocol handler), proper integrity
        of the data path (SSL vs TCP endpoint) etc.

        HTTP and web clients don't really allow users to specify this kind of fine
        grained control in the typical installation. Instead, we rely on the browser to
        tell us when a form is being submitted on a non-https connection etc.

        I think that there's a much bigger picture than just the HTTP protocol.

        Gregg Wonderly
      Your message has been successfully submitted and would be delivered to recipients shortly.