On 08/02/07, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > > > 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?
Not for me, payload is just the stuff getting lobbed it shouldn't have an intention in it. Its the initiation (client) and consumption (service) that are the important bits... hence the interface. > 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. > So like MQ Series networks then? I'm not seeing that as a major step forward given that EAI was very business document centric and didn't exactly set the world on fire (except in the burning down buildings sense). Services aren't "functional" in the traditional sense, they are descriptions of FUNCTION where a business function is a combination of behaviour, data and governance. > > Think 'Order' and 'OrderProcessor' and not service.HandleOrder() So you do think that MQ Series networks and JMS Listeners are the way to go? I wouldn't have service.handleOrder() either. I'd have something like Sales.placeOrder(order). In the same way in the real world I will contact a sales department to place my order and then later on do either Sales.getStatus(orderRef) or if its been communicated to me that once place the order goes over to logistics then I might do CustomerLogistics.getStatus(orderRef), of course the sales interface might be what I as a consumer use when in fact internally its just a pass through to the logistics element. Thus sales as a business priority handles all customer interaction and aggregates the relevant information on behalf of the user. That is why, for me, you should be service centric rather than document or object centric because businesses are not organised based around documents or objects, but they do deliver services to the market. > > > 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]> > To: [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> 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. > > >
