Dear Ashley, You raise a number of questions which I shall attempt to address.
Forging dynamic relationships is something that many researchers have bee involved in doing for some time. Perhaps the best examples can be found in Jim Hendlers research group at Maryland University which leverages semantic web technologies to enable an end user to link different services together on the fly to conduct some sort of pricing and then make some purchasing decision. What this work does is replace the broker website with a dynamically rendered page with pricing information about some commodity. It preserves the urls to the actual websites or services through which a purchase may take place. It isn't difficult to apply the same techniques to construct dynamic relationships with say a credit agency to do credit checking based on some business constraints (cost of the check and timeliness of response). So there is much out there that handles dynamic relationships today. Alas it is not yet formalised with respect to standards and so it isn't here for the real world (outside of academia yet). The business interoperability can be seen as a pattern of behavior across a set of services. If we have patterns of behavior that we wish to use then this can be described as a choreography and offered as a WS-CDL document. I can certainly imagine such documents being stored as meta-data descriptions of business processes which can then be queries by users in order to select a process that meets their needs. I can also imagine such behavioral descriptions being generated by higher level tools. The trick is then to apply the description to the services available. This can be done naively such that the WSDL descriptions match. It can be augmented with policy statements that describe static considerations (e.g. You must use WS-RM, WS-Transactions, SAML, etc) and dynamic considerations (e.g. guarantees 1000 transaction per second or 5 nines availability, etc). This can also be done using some sort of semantic mapping in which functions and parameters are deemed equivalent based on an ontology (this is what WSMO is trying to do). Regardless of the technique and depth of services that can be used to fulfill a choreography description what we have is a mechanism (in the future) in which the actual services that are used are selected dynamically. And yet their is some guarantee of interoperability and so a guarantee that the business transaction being enacted will suceed - at least technically. I don't really understand what you mean by this dynamic approach. Do you mean service selection or do you mean that the pattern of interaction (the choreography) is itself dynamic. If you mean the former then it is done or being done within the existing work that is ongoing. if you mean the latter then what is dynamic? Is it the linkage between services (the topology of the connection between services)? If it is topology this is also done. WS-CDL provides a mechanism for channel passing which is based on pi-calculus and so allows dynamic topology changes. Could you be more explicit - perhaps providing a use case - so that at least I can understand what it is that you want to achieve? Cheers Steve T On 4 Oct 2005, at 14:46, Ashley at Metamaxim wrote: > 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 ----- >> From: Steve Ross-Talbot >> To: [email protected] >> 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 >> Service-oriented architecture >> Computer monitoring software >> Computer and internet software >> Free computer monitoring software >> >> 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 --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/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/
