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

Re: [service-orientated-architecture] Re: Michelson on Service Re-Use et al.

Expand Messages
  • Michael Poulin
    Very good points, Gregg! However, as Dennis has noticed, OASIS SOA RM defines service interface including its messages. I think this is what Rob meant. -
    Message 1 of 9 , Jul 1, 2009
    • 0 Attachment
      Very good points, Gregg! However, as Dennis has noticed, OASIS SOA RM defines service interface including its messages. I think this is what Rob meant.

      - Michael


      From: Gregg Wonderly <gergg@...>
      To: service-orientated-architecture@yahoogroups.com
      Sent: Tuesday, June 30, 2009 8:15:43 PM
      Subject: Re: [service-orientated-architecture] Re: Michelson on Service Re-Use et al.

      Rob Eamon wrote:

      > The message format is part of the interface, but yes, it is that part
      > that needs to be stable.

      I still find this to be an interesting statement to hear. This is a technology
      issue, not an architectural issue. If I have a mobile code environment where
      the client can download the code that will receive and process the message, then
      the message provides not requirements to the "interface", because the interface
      is the "code" that the client downloads, not the "message".

      Web clients do this all the time with HTML, where the format of the message is
      wide and varied, and only the "visible" parts convey the "content" to the user.
      Even Javascript inside of web pages such as google maps, make the message
      format immaterial, because the interface is executable code, not a message and
      it's structure.

      If you use particular technologies, they can present certain restrictions on how
      your architecture can exploit certain characteristics of the clients.

      Why would you ever want the "message format" to be part of your interface?

      Gregg Wonderly


    • Rob Eamon
      ... At the architecture defintion of a service component, what makes up the interface definition of that component? IMO, operations and the data/messages
      Message 2 of 9 , Jul 3, 2009
      • 0 Attachment
        --- In service-orientated-architecture@yahoogroups.com, Gregg Wonderly <gergg@...> wrote:
        >
        > Rob Eamon wrote:
        > > The message format is part of the interface, but yes, it is that
        > > part that needs to be stable.
        >
        > I still find this to be an interesting statement to hear. This is
        > a technology issue, not an architectural issue.

        At the architecture defintion of a service component, what makes up the interface definition of that component? IMO, operations and the data/messages supported by those operations.

        At the technical level, those can be realized in any number of ways.

        > If I have a mobile code environment where the client can download
        > the code that will receive and process the message, then the
        > message provides not requirements to the "interface", because the
        > interface is the "code" that the client downloads, not
        > the "message".

        There are two interfaces here. One is the interface permitting download and installation/execution of code. The other is the interface of the code itself. Both interfaces define what is acceptable in terms of what is exchanged.

        > Web clients do this all the time with HTML, where the format of the
        > message is wide and varied, and only the "visible" parts convey
        > the "content" to the user.

        The format is defined by HTML, which is quite robust. The "backend" core interface of a browser is HTTP and HTML, though modern browsers obviously support other protocols and formats. One without the other renders the browser useless.

        > Even Javascript inside of web pages such as google maps, make the
        > message format immaterial, because the interface is executable
        > code, not a message and it's structure.

        Again, I think this is two different interfaces for two different components. The first is the interface and supported content types of the the browser. The second is the interface and message exchange of the script component.

        > If you use particular technologies, they can present certain
        > restrictions on how your architecture can exploit certain
        > characteristics of the clients.

        Yes, an architecture must consider the technical feasibility of a particular design. SO architectures define services that have explicitly defined interfaces and those interfaces define what the accepted/expected content is.

        > Why would you ever want the "message format" to be part of your
        > interface?

        I've never considered message format to be separate from the interface. It is a key part, IMO. Specifying that a service supports, say, HTTP is insufficient. I can do an HTTP get, but now what? I have to know what to do with what I just got. Similarly, if I post something the recipient must know what to do with it.

        Undoubtedly this is a terminology issue--that hardly ever happens here! ;-) Perhaps you can expand on what exactly you mean by "interface."

        -Rob
      Your message has been successfully submitted and would be delivered to recipients shortly.