What the service does = what message does it accept for processing and what message, if any, does it return. A description should also include some information about how to dispatch the message for processing, such as an environment variable (or the equivalent) that maps to a procedure name, object method, input message queue name, stored procedure name, etc.
Of course a service does more than this, typical descriptions include quality of service assertions, service level agreements, and human readable information. But the machine readable stuff is pretty much the message and a clue as to how the service needs to process it, whether it needs to return a reply etc. Eric ----- Original Message ---- From: Jan Algermissen <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, February 8, 2007 2:02:14 PM Subject: Re: [service-orientated-architecture] Booch on SOA & Architecture 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 <algermissen1971@ mac.com> To: service-orientated- architecture@ yahoogroups. com 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> To: service-orientated- architecture@ yahoogroups. com 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> 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 Coactus; Web-inspired integration strategies http://www.coactus. com Get your own web address. Have a HUGE year through Yahoo! Small Business. 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
