On Jul 10, 2006, at 9:02 AM, Meeraj Kunnumpurath wrote:
Jeremy,
This maps on quite well with some of the other implementations I have
seen. For example, in Mule they have the concept of connectors that
provide transport level abstractions which are decoupled from the UMOs
(a.k.a services). Mule uses its own message routing mechanism to
associate a connector to a service (I assume in the SCA world this
would
be a binding to a reference). I think this is also very similar in the
JBI world as well, where the NMR decouples the binding components from
the service engine components.
Yes I think this makes sense too since the reference is already
coupled to the binding and we get the decoupling at the transport layer.
Jim
Ta
Meeraj
-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 10 July 2006 16:15
To: tuscany-dev@ws.apache.org
Subject: Host API, was: Support for callbacks
On Jul 10, 2006, at 7:53 AM, Jim Marino wrote:
On Jul 10, 2006, at 7:40 AM, Jeremy Boynes wrote:
On Jul 10, 2006, at 7:19 AM, Jim Marino wrote:
2. We need to get the host API supporting callbacks. The reference
would use the host API to register itself as a listener with a
binding as opposed to talking directly with the binding.
This will allow us to decouple the callback infrastructure from
particular bindings. Jeremy may have some thoughts on this.
I would have though that the reference would register with the
binding rather than the host. After all the reference is bound on
the
outbound side so is coupled to the binding at that point; wouldn't
the inbound side just be the reverse?
Wouldn't the reference (composite reference) use the host api to
register with the binding transport? I may not have worded things
clear enough. This way we separate the protocol binding and callback
mechanisms from the particular transport (e.g. Jetty)?
In my mind, the host API is a low-level API that allows Tuscany
services
to connect to physical things in the host environment; examples for
physical things would be sockets or things layered on top of sockets
(such as servlets, mail-lets, JMS message listeners), threads, timers,
etc. The host API would be bridged to a managed environment such as a
J2EE server or could be implemented by other low-level Tuscany
services
such as a Jetty transport or ActiveMQ message broker to provide a
standalone environment. Think of it as a host abstraction layer.
Things that represent Tuscany or SCA services would sit at a level
above
that. So, for example, a HTTP transport would sit at this level and
would use the host API to register for inbound HTTP requests or to
make
outbound HTTP requests; a SOAP protocol handler would sit on top of
the
HTTP transport, a WebService binding would sit on top of a SOAP
protocol
handler, and so forth. This is a system connection level.
The associated between a reference and a binding is a Tuscany concept
rather than a physical one so in my mind that would be a connection at
the system level rather than at the host level.
We still get the decoupling from the physical side (e.g. from Jetty
vs.
Tomcat) but it's through the stack that the binding is using rather
than
at the host level. This also means that the reference would be
abstracted from the details of the binding (e.g. which SOAP stack,
which
databinding, which transport).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
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]
