|
Dear Steve
Thanks for your comments. I take your point about
the importance of having a basis for defining the semantics of a service, and
ensuring that you are not trying to plug things together that do make sense at a
business level.
However, I think it is possible to make a
distinction between:
A) Business Interoperability: Does plugging x
and y together make sense from a business semantics/business policy point
of view?
B) Technical interoperability: Can x
and y work successfully together under all message sequencing possibilities
to meet their shared business objective?
I readily agree that a completely dynamic approach
cannot address A. Trying to make it do so will lead to the situations
like your anomalous join between "first name" and "street name". Some kind
of shared global view of the semantics and "terms and conditions" of a service
is needed to ensure that this does not happen.
However, I think that a dynamic approach has
potential value in the context of B, as it means that A can focus on those
aspects of the interaction that have business significance without having to
address the full range of behavioural possibilities, which may be very
large.
If it is possible and sensible to make this
distinction, then it may be that different solution approaches can be applied to
A and B. If you take the case of a human interacting with a service, saying
buying insurance over the web, I think you can see this as follows:
- A is handled informally by the
user reading the rubric on the web page to determine whether or not the service
meets his or her needs. This may include examination of the "terms and
conditions" of the service, for instance: under what circumstances it
is possible to cancel and get a refund.
- B is handled
dynamically. The service prompts the user on how to enter information
to request the service. If the user revisits the site later and logs onto the
service again, prompts show what it is currently possible to do (cancel the
cover and get a refund, cancel with penalty, amend details of coverage, etc).
All sorts of interaction possibilities may be
allowed in B that are not covered in any explicit way by A.
The questions I have are:
- Is this distinction generally
possible and useful in defining services?
- If so, is a dynamic approach to
B always possible and useful, or only when the service client is a
human?
Regards
Ashley
----- Original Message -----
Sent: Sunday, October 02, 2005 8:30
PM
Subject:
[service-orientated-architecture] Global behavioral models and why they are
useful
Dear Jan and Ashley,
A "global behavioral contract"
is not a silver bullet but it does have
wide spread applicability. I think
that the arguments that Ashley makes
miss some important areas in
enterprise computing. It is fair to say
that a dynamic solution in which
we can construct relationships on the
fly is useful but it is not what
many enterprise users of technology do
or what they need to do. So to
focus on this alone without looking
deeper is perhaps missing where the
revenue opportunities really are.
I build many large scale distributed
systems, mainly for investment
banks. Amongst the problems they have in a
world of increasing
componetization (through SOA-like principles) is
governance and
interoperability. The systems they have are not and do not
need to be
dynamic to the extent of forging new links at the drop of hat.
Rather
they need to be able to work very quickly. The move towards SOA is
largely to do with flexibility of implementation of services. They can
change the implementation fairly readily without the need to re-plumb
the whole thing.
What a global behavioral contract does is act as
the unambiguous
sequence diagrams that we often see that describe how the
services
interact. Alas sequences diagrams are not a good way of
describing this
interaction and this is why using them results it systems
that have to
be tested for long periods to ensure that when they are
introduced
things still work as expected. In financial services a lot of
time has
been spent designing message formats (it's why FpML -
www.fpml.org - is
so popular along with FIXML and many others). These
"on-the-wire"
protocols do not describe behavior they simply describe the
message
content. So naturally behavior becomes the next thing to look at.
What
they need is an overall model of behavior that guarantees
interoperability by design. What they do not need is new services being
provisioned that use services in a way that they were not intended to
be used. It is similar to a relation join between street name and first
name. It means nothing and has no business value. Links are forged
between services with specific meaning. The challenge has been to
capture that meaning. And meaning here is largely governed by or
determined by an overall behavior. You can think of it as a description
of a distributed workflow or business process.
The benefits of
doing this are that we can reduce testing time, remove
deadlocks and
livelocks and race conditions. We can provide behavioral
governance.
Services can belong to many behavioral contracts. They do
not have to
belong to one. But we do need to be able to understand the
role they play
in whatever contract they participate in.
I would be happy to entertain
further discussion if it is required.
Best regards
Steve
Ross-Talbot
>> -----Original Message-----
>> From:
[email protected]
>>
[mailto:[EMAIL PROTECTED] Behalf Of
>> Ashley at Metamaxim
>> Sent: 30 September 2005
23:27
>> To:
[email protected]
>> Subject: Re:
[service-orientated-architecture] Is the WS- vision
>>
achievable?
>>
>> Jan Algermissen wrote:
>>
>> > But the question rally is: does the client have to
know
>> > about the sequence of state operations in order to
enable
>> > those complex business processes - I just
cannot see why.
>> >
>> > All that happens is that the
application logic gets
>> > hard-coded in the client and if
the process changes,
>> > one needs to update the client.
If the client determines
>> > the sequnce of operations at
runtime, changes to the
>> > process do not affect the client
*at all*.
>>
>> Jan
>>
>> I
agree with you completely. Current ideas on how to manage service
>>
choreography are based on the idea of a "global behavioural contract"
>> to which both service and client have to conform. This means, as
I
>> understand it, that the choreography is hard coded into
the client. A
>> possible alternative, as you point out, is that the
client is able to
>> determine the allowable operations at
run time. For the same reasons
>> as you, I think this would be much
better.
>>
>> The REST approach that you described in
an earlier post, where a
>> service publishes a dynamically
generated "menu" of available
>> operations based on its current
state, is one that I have used a lot.
>> I have been involved in the
development of a behavioural modelling
>> tool (ModelScope) that is
based on this paradigm. ModelScope assumes
>> that the client of a
service is a human (rather than a client
>> process), so that the
menu of possible next operations (events) is
>> displayed on a
graphical user interface.
>>
>> In ModelScope, the
behaviour of services is modelled using state
>> transition
diagrams, and the list of "what you can do next" displayed
>> to the
user is generated on-the-fly by interrogation of the service
>>
metadata (simply a coded representation the state transition diagram
>> of the service) and the current service state. Neither the user
>> interface nor the end user need to see or know the whole state
>> transition diagram, which is effectively private to the service.
>> There is no global contract to which a user of the service must
>> conform -- the user just selects the appropriate next operation
from
>> the generated menu.
>>
>> This
paradigm works well, and seems to me to be scalable to
>>
arbitrarily complex interactions. I do not know why many in the SOA
>> industry seem so keen on "global behavioural contracts", given
the
>> apparent advantages of this kind of dynamic
approach.
>>
>> You might be interested in
>> http://www.metamaxim.com/download/documents/DynChor.pdf which
>> discusses some ideas in this area.
>>
>>
Rgds
>> Ashley
>>
>>
>>
>> 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
YAHOO! GROUPS LINKS
|
