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! Objects are simply a runtime by-product, the relevant stuff is classes and interfaces for they are what dictate behaviour. Which makes the above statement somewhat ambiguous and difficult to reason about. A service is just a specification of behaviours triggered by some specified means is it not? In which case at least for software services in code terms from an object perspective we'd be talking about an interface which is nothing but specification (bar language semantics of course, that's a different conversation) and the implementation behind the interface is largely a separate concern. And if the implementation behind the interface is a class instantiated into a runtime object that doesn't have to mean it's equivalent to CORBA with all the attendant tight bindings, dispatching to a single endpoint etc. I wonder if the statement should actually say: "Obviously someone who can't give up _distributed_ objects in favor of services" Dan. Gregg Wonderly wrote: > Eric Newcomer wrote: >> Obviously someone who can't give up objects in favor of services. > > Humm, does that mean that a service can never be an object, but must be > multiple > objects or multiple of something? I agree that all "services" in an SOA may > not > be software services, but for software based services, what makes it bad for > them to be objects in implementation? > > Gregg Wonderly > > > > Yahoo! Groups Links > > > >
