The promise of reuse goes back a long long way of course. I well
remember sitting on a panel in
London at an OO conference with Martin Fowler debating this issue. Not
that either of us came
up with a solution and no one else did that day either.
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.
Now what does "externally observable behavior" mean? We need to
understand this and
define it carefully because it forms the basis for any technical
contract that a service offers.
It does not mean WSDL. It does not mean Java interfaces. These are not
enough. The
description must be able to describe the functions offered and the way
in which they may
be used (the ordering rules and dependencies if you will). For example
if I have a service
that has the following functions:
Service S ::=
Document open(Document)
Document print(Document)
Document close(Document)
It is unclear what the call sequence should be or even if there is any
sequence or ordering at all.
We need to say something akin to:
S ::= open.S'
S' ::= print.S' + close.S
read as
S is defined as accepting "open" and then behaves like S'.
S' is defined as accepting "print" and then behaves like S' again OR
it accepts a "close" and behaves like S
What we describe here is only externally observable behavior. We do not
describe how open, close or print are
implemented.
It turns out that the work of Honda, Yoshida, Milner and Carbone can
indeed describe behavior in this way. It is
more-or-less the pi-calculus (see the formal semantics of WS-CDL). What
makes this interesting is that we can
describe services in this way directly (on a per service basis) or
derive them from a WS-CDL description. We can
determine that a set of services when composed (that is they
communicate with each other) are well formed,
that is they are free from livelocks, deadlocks and so on. We can also
take a service T or a composition C and
determine if it provides the same behavior (is bi-similar to) another
service S. This enables us to meet the
substitutability test. And once you can meet that goal then you have a
means by which you can classify
services in terms of behavior and that can drive reuse.
You still need sound methodologies. You can reuse in poor ways just as
you can join any two table in a RDMS
based on non-sensical columns (like street name of employee with
department name). But at least we have the
basis for understanding when things are the same which is the basis for
any reuse decision.
Comments?
Cheers
Steve T
On 9 May 2006, at 23:55, Gregg Wonderly wrote:
> Steve Ross-Talbot wrote:
> > So I guess I am saying that if you go into SOA in order to get
> reuse do
> > not expect direct help in determining what to reuse from any tools
> such
> > as UDDI repositories/registries/ESB's or indeed anything that I have
> > seen (and I have seen quite a lot). Perhaps the assembled masses
> have
> > some suggestions, but I think it is likely that it is a
> methodological
> > approach supported by the right tools and languages that is
> required to
> > help us get reuse in any sensible fashion.
>
> My years of software development and design have taught me that its
> very hard,
> if not impossible to create the perfect architecture the first time.
> So, you er
> need to have software platforms and design architectures, at your
> disposal
> (through your knowledge base or tools at hand) that allow you to
> manage the
> versioning of your system effectively. You need to be able to reuse
> your
> services in one form or another. Some of the most difficult to solve
> problems
> come about from the attempt to make everything fit into one container.
> Sometimes that is important, other times its detrimental.
>
> You have to be prepared to tackle reuse and versioning in effective
> and
> intelligent ways. Some tools provide such features inherently.
>
> The XML/document model provides the opportunity to add document
> elements/attributes and to copy document trees with variations so
> that you can
> adjust the available structure of the document for applications that
> need
> different features. If this creates a large replication of content,
> you can
> either live with it (and risk dependency on the old content expanding
> without
> your knowledge), or you can create a new service that provides the
> new document
> content. If your lucky, you might just rev the document and force
> the clients
> to change.
>
> In platforms, such as Java, which provide mobile code capabilities,
> you can
> utilize the mobile code features to provide a client side conversion
> of the
> servers API into the interface that the client understands. If the
> client is
> not Java based, then you can utilize server side invocation layer and
> endpoint
> conversion to make sure the client only sees the content that it
> needs.
>
> One of the key mechanisms for enabling just-in-time content is
> authentication
> and explicit version negociation in your API/transport.
>
> Gregg Wonderly
>
>
>
>
>
> 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.
>
>
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.
