Re: [service-orientated-architecture] Re: Michelson on Service Re-Use et al.
- 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.
- --- In email@example.com, Gregg Wonderly <gergg@...> wrote:
>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.
> 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 technical level, those can be realized in any number of ways.
> If I have a mobile code environment where the client can downloadThere 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.
> 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 theThe 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.
> message is wide and varied, and only the "visible" parts convey
> the "content" to the user.
> message format immaterial, because the interface is executable
> code, not a message and it's structure.
> If you use particular technologies, they can present certainYes, 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.
> restrictions on how your architecture can exploit certain
> characteristics of the clients.
> Why would you ever want the "message format" to be part of yourI'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."