I know this went to Eric, but I've said the same thing enought time and http://doi.ieeecomputersociety.org/10.1109/MS.2005.80 was my attempt at describing just that.
What a service does needs to including 1) The semantics of interaction (precondition, postcondition, invariant) 2) The policy of interaction (security, QoS, etc) 3) The format of interaction (network, data formats, ports etc) Ideally I'd then lob in the semantics on the information that is being exchanged, but I think that the pre/post/invariant set are more important and also easier to do (just oddly not done properly since Eiffel). Right now WS-* has 2 and 3 and not 1. Given those two elements I can say what I need to do to interact and what I need to do to be allowed to interact and how the physical interaction will take place. The first element would tell me what I need to do first, what the end result will be, and what won't be changed if I call it. Steve On 08/02/07, Jan Algermissen <[EMAIL PROTECTED]> wrote:
On 08.02.2007, at 18:58, Eric Newcomer wrote: I also think there needs to be some kind of description of what that service does, and if it's machine readable that's helpful to program-program communications. What exactly do you mean by "what that service does"? And how could this ever be machine readable? Jan Eric ----- Original Message ---- From: Jan Algermissen <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 8, 2007 10:51:19 AM Subject: Re: [service-orientated-architecture] Booch on SOA & Architecture On 08.02.2007, at 14:44, Eric Newcomer wrote: I think what Steve said in the previous post is very important. To gain the benefit of service orientation it's important to design and model software systems in terms of functions (services) rather than things (objects) since functions are more naturally aligned with "what we do" as people and businesses. Hmm, wouldn't it be more enlightening to emphasize payload instead of interface design? I think the real difference between an OO design and a service design is to be found in the kind of payload the remote system accepts. Services, uuh, endpoints should IMHO be designed around business documents, not around the idea of moving from OO- (back) to functional design. Think 'Order' and 'OrderProcessor' and not service.HandleOrder () Jan Given the service abstraction, implementation is a separate issue. As we have heard many times on this list a wide variety of technologies can be used for implementation. The most important thing is to get the design right - meaning to meet the business requirements, to align with the services that the business provides for its customers, or other departments. Eric ----- Original Message ---- From: Mark Baker <[EMAIL PROTECTED] org <[EMAIL PROTECTED]>> To: service-orientated- architecture@ yahoogroups. com<[email protected]> Sent: Thursday, February 8, 2007 7:58:18 AM Subject: Re: [service-orientated -architecture] Booch on SOA & Architecture On 2/8/07, Dan Creswell <[EMAIL PROTECTED] org <dan%40dancres.org>> wrote: > Hmmm, > > "Obviously someone who can't give up objects in favor of services" > > Someone thinking in objects has serious wrong-thinking in terms of > design full stop! RESTful design is largely object-oriented, and I've had no trouble designing very large scale systems using it. REST was at one time called the "HTTP Object Model", in fact. It's also why I've continued to use "distobj" as my email address. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca<http://www.markbaker.ca/> Coactus; Web-inspired integration strategies http://www.coactus. com<http://www.coactus.com/> ------------------------------ Get your own web address.<http://us.rd.yahoo.com/evt=49678/*http://smallbusiness.yahoo.com/domains/?p=BESTDEAL> Have a HUGE year through Yahoo! Small Business.<http://us.rd.yahoo.com/evt=49678/*http://smallbusiness.yahoo.com/domains/?p=BESTDEAL> ------------------------------ 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut.
