Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards)
- On Nov 28, 2006, at 11:40 PM, Steve Jones wrote:
> o you are saying that it is _bad_ practice in REST to have sensiblyURIs are opaque identifiers (just like object references in any OO
> named URIs?
language). You should
not infer anything from a URI.
- Hi Anne,
Nice to see you back posting on the list again.
Anne Thomas Manes wrote:
> This service called "Wal-Mart" (or "WMT") is a service to a stockholder.I'm not too sure what you mean by "Wal-Mart service". What is the
> I would also content that a Wal-Mart store is a representation of the
> Wal-Mart service, which is a service to a shopping consumer.
difference between having an Wal-Mart object in OO and Wal-Mart service?
>> I meant this from a technical perspective. There is lots ofYes, thank you for restating it.
>> functionality that is unique to a specific application. If this
>> functionality will never be used in any other application, and the
>> functionality is quite stable, it doesn't make sense to implement it
>> as a service and impose the overhead of service creation, service
>> management, and service invocation. Also, you might have application
>> requirements that demand extremely high performance or atomic
>> transactions, etc, that demand more tight coupling.
Similarly, as there are limitations placed by the current technology and
the cost associated with it
in a technical perspective, there are limitations placed by people on a
It may be a "should" in the context of SOA , but that does not necessary
translate to a "should"
in the context of a project.
>> SOA is a mindset -- it's your approach to designing systems. It's a+1 on SOA is a mindset.
>> set of principles that help ensure that you build flexible and
>> adaptable systems. I recommend that you internalize these principles
>> and apply to to every application system you're building. That does
>> not mean that you will implement every application using any
>> particular technology (SOA is independent of any particular
>> technology), or that in every application system you will refactor
>> reusable functionality into shared services, or that in every
>> application system you will reuse an existing service rather than
>> build the capability again, or that when you do implement a service,
>> its interface must be completely loosely coupled. In all cases, you
>> must let the application system requirements dictate your design and
>> infrastructure decisions. But I reiterate, you should apply SOA
>> principles to every system design. (Just as, I'm sure, you apply many
>> other fundamental design principles to every project you do.)
"every" is a strong word which I'm hesitant to use. There are some
fundamental design principles I use
on "many" projects, but there's always some exceptions based on