> But things have moved on. If we can properly describe a service in
> terms of it's externally
> observable behavior then we can start to classify services as offering
> the same behavior
> and this way we can understand how one service can be a substitute for
> another or how
> the combination of two or more services can be a substitute for
> another. Without a precise
> description of the "externally observable behavior" reuse is always
> going to be in the world
> of fiction rather than fact.
This reminded me of a blog post I keep meaning to write, extending
upon my discussion of what it means to be a service provider. I was
working with a colleague recently who was defining some new services,
and this was a first attempt to define the service contract. What
came out of this, which was somewhat unexpected, was a document that
was much better suited as a design specification for someone building
the service than it was a document for use by a service consumer.
This was something that I hadn't thought about, but made perfect
sense when it happened. Most designers/developers are used to
creating interface specifications for the purpose of creating an
implementation, not for the purpose of describing the externally
observable behavior, as you put it. Yet another example of the
culture change that must happen to adopt SOA in the enterprise...
-tb
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
