SOA?
in [OOP]
|
Prev: help
Next: Temp control design
From: Daniel T. on 31 Aug 2007 20:35 ram(a)zedat.fu-berlin.de (Stefan Ram) wrote: > I read an explanation of �service� (as in �SOA�): > > � o A service can take requests > o Given a well-formed request, a service will send a response > o A service can use other services� > > http://weblog.raganwald.com/2007/08/soa-for-dummies.html > > This seems to match the description of an �object� > in object-oriented programming. > > Is there any difference to an �object� that I might have > missed? An object accepts messages which may or may not be requests. An object need not send a response (unless you consider "message received" as a response.)
From: Patrick May on 31 Aug 2007 20:49 ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > I read an explanation of �service� (as in �SOA�): > > � o A service can take requests > o Given a well-formed request, a service will send a response > o A service can use other services� > > http://weblog.raganwald.com/2007/08/soa-for-dummies.html > > This seems to match the description of an �object� in > object-oriented programming. > > Is there any difference to an �object� that I might have missed? The defining characteristics of a Service-Oriented Architecture are: 1. Functionality is exposed as a set of services. 2. Services make themselves available by registering with a lookup mechanism. 3. Clients find services only via the lookup mechanism. 4. Clients bind to services dynamically. Note that SOA and Web Services are _not_ synonyms. A service, in the context of SOA, is a cohesive set of business functionality aggregated into a single interface. This interface is implemented by one or more software artifacts, which may be local or remote. The primary difference between objects and SOA services is the varying levels of granularity of services. Some services are very fine-grained and correspond closely to OO classes. Others are very coarse-grained, even to the level of entire ERP systems, for example. Another, more qualitative than quantitative, difference is that SOA services should reflect the essential capabilities that an organization requires to meet it's core needs efficiently and to adapt rapidly to changing conditions. The loose coupling inherent in SOAs allows for the creation of resilient (self-healing), scalable distributed systems and supports using services in multiple applications. With an appropriate governance policy in place, services are one step closer to the goal of component reuse. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Patrick May on 1 Sep 2007 08:46 "Daniel T." <daniel_t(a)earthlink.net> writes: > ram(a)zedat.fu-berlin.de (Stefan Ram) wrote: >> This seems to match the description of an �object� in >> object-oriented programming. >> >> Is there any difference to an �object� that I might have >> missed? > > An object accepts messages which may or may not be requests. An > object need not send a response (unless you consider "message > received" as a response.) The same is true of services. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Patrick May on 1 Sep 2007 08:48 ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > "Daniel T." <daniel_t(a)earthlink.net> writes: >>>�o A service can take requests >>>o Given a well-formed request, a service will send a response >>>o A service can use other services� >>An object accepts messages which may or may not be requests. An >>object need not send a response (unless you consider "message >>received" as a response.) > > Thus, SOA might be considered to be a special case of OOP, where > messages are being restricted to request messages and receivers of > messages are being restricted to responding receivers. This is not the case. There are no such restrictions on SOA services in general, although some implementations impose certain constraints. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Gabriel Claramunt on 1 Sep 2007 16:40
Probably you can say the same about a structured component. And an object is more than a group of services. Usually an object belongs to a class and is used to represent an abstraction. A set of services is not used to represent an abstraction (unles you're doing some sort of Object Oriented SOA... never saw that yet :) )I see SOA and OO at different levels, SOA is about how components comunicate to each other, OO is about how to construct those components. (I'm not even trying to define a component) -- Gabriel Claramunt http://gabrielsw.blogspot.com "Stefan Ram" <ram(a)zedat.fu-berlin.de> wrote in message news:SOA-20070901012820(a)ram.dialup.fu-berlin.de... > I read an explanation of �service� (as in �SOA�): > > � o A service can take requests > o Given a well-formed request, a service will send a response > o A service can use other services� > > http://weblog.raganwald.com/2007/08/soa-for-dummies.html > > This seems to match the description of an �object� > in object-oriented programming. > > Is there any difference to an �object� that I might have > missed? > |