See in line below:
Cheers
Steve T
On 26 May 2006, at 10:27, Harm Smit wrote:
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Steve Ross-Talbot
> > Sent: jeudi 25 mai 2006 15:59
> > To: [email protected]
> > Subject: Re: [service-orientated-architecture] Re: an SOA in
> practice
> >
> >
> > I think that Gregg is correct developers do not and should not care
> > about the transport as long as the behavioral contract is fulfilled
> > correctly by each participant service in a system.
> >
> > This does not mean that the behaviors can be guaranteed because the
> > stack upon which you base your participant service may have
> different
> > underlying synchronisation and threading models. When those
> > models clash with the behavioral contract of the services you care.
> > When it does not you don't care and don't need to care.
> >
> > The ideal world (which of course we do not live in) would enforce
> > behavior, enforce data and functions and so guarantee
> interoperability
> > of participant services regardless of the underlying transport.
>
> There are many differences between the ideal world and the real world.
> The "8 fallacies of distributed computing" is one _expression_ of that
> difference: you cannot ignore that networks break down and that
> bandwidth isn't infinite.
> But even in the ideal world there may be stringent behavioral
> contraints
> of the kind "if you don't respond within the next 30 ms, the roof will
> come down".
> Enforcing such behavior in the real, networked world, "regardless of
> the
> underlying transport", is not exactly an easy task.
>
I agree entirely. I think having a system describing with differing
layers of policy
attachments can be used to express these constraints on a system and
then be
used in an autonomic way to manage it when things go wrong. Not a pipe
dream
but a reality we are close to doing this right now.
> > Given WSDL does not provide behavioral contracts (just
> > functional ones over data)
> > how can we:
> > i) describe the behavior?
> > ii) monitor services against their described behavior?
> > iii) guarantee that services do behave correctly?
> > All of course in a standard and unambiguous way. If we can do
> > this then we can ensure that different implementations over
> > different transports do the right thing at right time and that way
> > ensure interoperability and substituability of participant services.
>
> Right. Then, what's your approach to answer the above questions?
>
WS-CDL provides one way of doing it. It provides a clean formalism
(theory)
from a global model (an architectural description) to the end points
(local
behavior). One can use this to determine bisimilarity in a reasonable
time/space way. One can also use it to guarantee certain levels of
conformance of end points to a global model and so ensure behavior is
preserved. Think of it as acting globally and thinking locally from an
architects perspective and thinking globally and acting locally from the
perspective of a developer developing one service in an SOA fabric.
> > Cheers
> > Steve T
>
>
>
>
>
> 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.
