Folks,
Let me put my oar in here.
I'll start first with SCA and ESBs and then move to discuss Tuscany.
Let's start with a controversial statement:
"SCA is a programming model for ESBs"
Daniel made some statements about what an ESB is - I do agree that this
is ill-defined (purposely so, from some of the vendors, I believe).
I think that the following are true of ESBs:
- virtualizes services and service invocations: makes their actual
location and actual protocol irrelevant
- provide (dynamic) mapping between a service invocation and the target
service used
- provide discovery and selection of service(s) meeting specified
criteria: may include choices based on QoS or on business criteria
There may be other aspects too, but these seem to cover the bulk of the
capabilities.
SCA provides a way of describing service consumers and service providers
in a way that is consumable by an ESB. SCA describes the consuming
components and provides metadata for each service reference. SCA
describes the provider components and has metadata for each service offered.
The connection from a consumer to a provider can:
- be left totally open ("autowire"), in which case the runtime
infrastructure is responsible for finding suitable target services
- be specified separately from consumer and provider components
(separate wires), in which case the wires represent static connections
made by the "ESB infrastructure"
- be specified as part of the consumer, but potentially only by
indicating the identity of the target, rather than anything to do with
its location (ie component/service rather than some binding specific
endpoint address)
These methods all allow for the activities of an ESB:
- services and service references are virtualized. Actual locations and
actual protocols can be decided at runtime or bound very late in the
deployment process. An SCA component can be distributed onto a
grid-style runtime (there are products such as Paremus' Infiniflow that
do this)
- dynamic connections are possible (autowire)
- where consumers must be mapped to providers, SCA can model the
activities of the mediation between them - mediations can be modelled as
service components of some mediation type (eg XSLT transform)
- dynamic selection of target services can likewise be modelled as a
component of some type sitting between consumer and provider (eg rules
component)
Tuscany can be used to do some of these things. Tuscany on its own can
be configured with appropriate components. Alternatively, Tuscany can
be used with an ESB like ServiceMix or Synapse, using some of the
mediation capabilities of those systems to provide implementations of
the mediation components.
Hope that this helps the debate.
Yours, Mike.
Daniel Stefan Haischt wrote:
On Dec 14, 2007 10:55 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
"ESB" is much (mis)used as a marketing term. By those standards,
Tuscany is probably one already :-) But we'd probably want to
have some clear technical idea of what an ESB is before we decide
whether we want to put Tuscany under the (increasingly crowded)
ESB umbrella.
I think ESB should be recognized as an architectural pattern. If there is rather
much confusion about what an ESB is, this may indicate that the pattern isn't
well defined. Otherwise it would be more or less easy to determine whether
Tuscany fulfills what the pattern is specifying, no?
Somebody told me recently that ESBs are about virtualized service
endpoints. So there's a layer somewhere that can map virtual
endpoints to real endpoints, and can change the real endpoints
even though the virtual endpoints (as specified by application
code) stay the same.
Hummm I've been told that service virtualization is a SOA principle thus
isn't tightly coupled to an ESB. Quote: "There has been talk about
dynamically provisioned
services for years now. The problem is that even ESBs bind the service
invocation too tightly
to the service implementation." [1]
It's even more interesting what will be virtualized :)
* The actual location of the service (i.e. the FQDN or an IP address)
* The service protocol (OpenESB also supports server-side virtualization of the
service protocol [3])
* I was also once told that virtualization will be used to abstract
different service
implementations and thus the requestor may provide certain quality of service
criteria to the virtual service endpoint which then delegates the
request to the
appropriate service according to the QoS criteria.
* etc.
Refs:
[1] http://rourkem.com/soa/matt-quinn-on-service-virtualization.html
[2] http://websphere.sys-con.com/read/467329.htm (Unifying Grid
Virtualization, SaaS and SOA)
[3] http://blogs.sun.com/tientien/entry/web_service_virtualization
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
