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. >> >> ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
