Lists Home |
Date Index |
I can see that as philosophy, but practically, it
doesn't make a difference other than performance.
In work we are doing, we are using web services
for things such as report methods. The fact of
locale makes no difference. It's just a report.
Where locale *might* be factored in is roles and
To me, the SOA as philosophical architecture is
an organizational principle, that is, as an enterprise
engineer, I intuitively understand the concepts of
breaking tasks into services thus enabling a contract
model of command, control and communication, and yes,
As a programmer, it looks like an encapsulated
method that advertises an interface.
The former is why I tend to think in terms of events.
Then notions such as correlation engines make more
sense (see autonomic computing) because I can have
event ontologies for reasoning about the event type
and assembling a service to be performed from a
repetoire of services enterprises of this.type offer.
IMHO, the service model fell out of the enterprise
modeling domain. It is how businessHeads see their
businesses, as contracts for products, goods, and services.
From: Karl Waclawek [mailto:email@example.com]
> Are services responses to events?
> That is likely at least one level higher
> in the organizational architecture if call
> and response is the lowest level of description,
> but if we are to speak of a 'services oriented
> architecture' that is meaningful beyond the
> most primitive descriptions, it can be useful
> to think in terms of event types over
> messages. Otherwise, a service and a method
> are indistinguishable.
I have a hard time seeing something new and unique in SOA
worthy of inventing a new acronym.
Maybe the difference is in the fact that services
have "coarser granularity", they do more per request,
they are "chunkier". Which may mean that what they
provide is just that much closer to what a non-programmer
is able to describe, that they deserve their own terminology.
Another "gradual" difference from - let's say, distributed
objects - could be that in SOA there is a heightened awareness
of remote interactions being fundamentally different from local
ones - with SOA specializing in the remote type.