A service
is an implementation of a well-defined business
functionality, and such services can then be consumed by clients in different
applications or business processes. [Sun]
ZZZ comments: This means that
service is a business functionality,
not technology or implementation of some technology.
Services
are software components with well-defined interfaces that are
implementation-independent. [Sun]
Services
are self-contained (perform predetermined tasks) and loosely coupled (for
independence)
[Sun]
A service
is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by
software agents on behalf of their owners. [XML.com]
A service
is a function that is well-defined, self-contained,
and does not depend on the context or state of other services. [http://www.service-architecture.com]
SOA is A collection of Services that communicate with each
other [Cryer.com]
(=A
service-oriented architecture is essentially a collection of services. These
services communicate with each other. The communication can involve either
simple data passing or it could involve two or more services coordinating some
activity. Some means of connecting services to each other is
needed. - http://www.service-architecture.com)
TODO: SOA is described, asynchronous,
remote, loosly coupled, orchestrated, standard-based... quote
[SOA] is an integrated software infrastructure and design approach,
leveraging Web computing standards, for delivering business functions as shared
and reusable services. [sun]
SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. [Sun]
SOA and web
services are two different things, but web services are the preferred
standards-based way to realize SOA. [Sun]
ZZZ Comments:
Such 'preferred way' contradicts the guideline on Services which says
services should be implementation independent.
SOA is web services [unattributed]
ZZZ Comments: Sun contradicts
this!
In reality " SOA misused web services to get focus (you naughty: your
concepts are at least 40 years old)."
http://soa-eda.blogspot.com/2006/06/soa-doesnt-add-business-value-but-eda.html
·
SOA
is an architectural style whose goal is to
achieve (?ZZZ)loose coupling among interacting
software agents. A service is a unit of work done by a service provider to
achieve desired end results for a service consumer. [xml.com]
·
The
idea of SOA departs significantly from that of object oriented programming (!ZZZ), which strongly suggests that you should bind data and
its processing together. [xml.com]
Loose coupling
Orchestration
- the act of combining hharmoniously ;
instrumentation(?)
SOA allows for the reuse of existing assets where
new services can be created from an existing IT
infrastructure of systems. In other words, it enables businesses to leverage
existing investments by allowing them to reuse existing applications, and
promises interoperability between heterogeneous applications and technologies.
SOA provides a level of flexibility that wasn't
possible before in the sense that: [sun]
Services
are software components with well-defined interfaces that are
implementation-independent. An important aspect of SOA is the separation of the
service interface (the what) from its implementation (the how).
Such services are consumed by clients that are not concerned with how
these services will execute their requests.
Services
are self-contained (perform predetermined tasks) and loosely coupled (for
independence)
Services
can be dynamically discovered (ZZZ ?)
Composite
services can be built from aggregates of other
services
http://webservices.sys-con.com/read/175388_p.htm
even say that SOA Will Kill the Offshore Model.
ZZZ
comments: In reality SOA will complicate and confuse
the application development to such an extent that more and more stuff will be
offshored!
How does SOA achieve loose
coupling among interacting software agents? It does so by employing two architectural constraints:
1.
A
small set of simple and ubiquitous
interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be
universally available for all providers and consumers.
2.
Descriptive
messages constrained by an extensible schema delivered through the interfaces.
No, or only minimal, system behavior is prescribed by messages. A schema limits
the vocabulary and structure of messages. An extensible schema allows new
versions of services to be introduced without breaking
existing services.
[Xml.com] ubiquitous
=Present, appearing, or found everywhere; omnipresent.[1]
I've heard people say the nice thing about SOA is
that it separates data from process,
that it combines data and process,
that it uses web standards,
that it's independent of web standards,
that it's asynchronous,
that it's synchronous,
that the synchronicity doesn't matter....
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
Here is the
full text:
Whenever ThoughtWorks
rashly lets me out in front of a client, one question I'm
bound to be asked is "what do you think of SOA (Service Oriented
Architecture)?" It's a question that's pretty much
impossible to answer because SOA means so many different things to
different people.
I've heard people say the nice thing
about SOA is that it separates data from process, that it combines data and
process, that it uses web standards, that it's independent of web standards,
that it's asynchronous, that it's synchronous, that the synchronicity doesn't
matter....
I was at Microsoft PDC a
couple of years ago. I sat through a day's worth of presentations on SOA - at
the end I was on the SOA panel. I played it for laughs by asking if anyone else
understood what on earth SOA was. Afterwards someone
made the comment that this ambiguity was also something that happened with
Object Orientation. There's some truth in that, there
were (and are) some divergent views on what OO means. But
there's far less Object Ambiguity than the there is Service Oriented Ambiguity.
So what do we do? For a start we have to remember all the time about how many
different (and mostly incompatible) ideas fall under the SOA camp. These do
need to be properly described (and named)
independently of SOA. I think SOA has turned into a semantics-free concept that
can join 'components' and 'architecture'. It's beyond
saving - so the concrete ideas that do have some substance need to get an
independent life.
[1]Excerpted from