Comments inline.
Raymond Feng wrote:
Hi,
My understanding is that the domain base URI is used to
partition/configure the protocol endpoints if there are multiple
bindings share the same protocol scheme. Let's use web service binding
and json-rpc binding as examples. Both of them can listen on the HTTP
requests. And the domain base URI basically defines the pattern on how
to allocate/map endpoints for binding types that share the same scheme.
The assembly spec says something different:
2357 Base Domain URI for a scheme. An SCA domain should define a base
URI for each
2358 hierarchical URI scheme on which it intends to provide services.
2359 For example: the HTTP and HTTPS schemes would each have their own
base URI defined for the
2360 domain. An example of a scheme that is not hierarchical, and
therefore will have no base URI is
2361 the "jms:" scheme.
It's similar as we host multiple web sites on one machine.
* Use a different port number (http://example.com:80 vs.
http://example.com:8080)
* Use a different vitual host name (http://my-exmaple.com vs.
http://your-example.com)
* Use a different context path (http://example.com/webservices vs.
http://example.com/jsonrpc)
To take a staged approach, we could pick a fixed base domain URI
pattern for each binding/scheme pair and make them configurable later on.
I don't think that we can assume that all Web services (for example) in
an SCA domain will be available at http://example.com:8080 as an SCA
domain covers multiple nodes, servers, machines, clusters...
So I'm still not sure how this can work at all :)
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 31, 2007 5:12 PM
Subject: Re: Rules for determining binding endpoint URIs, was: Binding
endpoints (was Fwd: Services and WSDL files
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
[snip]
Another problem is all our bindings work differently. So
<binding.ws/>, <
> binding.rmi/> <binding.jms/> <binding.jsonrpc/> etc all result
in a
> service
> being available at a different endpoint. Also the uri attribute
on those
>
> bindings all work differently so uri="foo" for some bindings
would be
> treated as relative uri, for others an absolute one. What we need
is a
> bit
> of code that implements section 1.7.2.1 of the assembly spec
which all
> bindings then use. (a generic version of
> Axis2ServiceProvider.computeActualURI). Didn't this come up once
before
> and
> something was changing in the runtime binding for this?
I think that these URIs should be determined as part of the process
of combining wires and uris specified at different levels in the
SCA assembly. If the correct URIs are determined once as part of
this process, a binding provider should be able to just call
binding.getURI(), without having to calculate it at all, on its own
or even calling a central URI calculator method.
Before trying to implement a common algorithm for all bindings, I
thought I'd double check the various SCA spec docs. Here's what I
found:
- WebService binding
absolute URI specified in binding/@uri
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in binding/@uri
or
absolute URI specified in WSDL
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in WSDL
or
absolute URI specified in a wsa:Address
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in a wsa:Address
- JMS binding
JMS specific URI specified in binding/@uri
or
no URI, combination of JMS specific attributes
- EJB binding
base domain URI for corba:iiop: + '#' + relative URI specified in
binding/@uri
or
base domain URI for corba:rir: + '#' + relative URI specified in
binding/@uri
or
absolute URI specified in binding/@uri
I think that other bindings introduced by Tuscany can follow similar
patterns:
- RMI binding
similar to EJB binding
- JSON, Ajax and Feed bindings
absolute URI specified in binding/@uri
or
base domain URI for http: + '/' + component URI + '/' + relative URI
specified in binding/@uri
Thoughts? could you guys please review to make sure I understood the
specs correctly? Thanks.
After more reading of the various SCA specs, I think we should defer
supporting a domain URI (or a set of domain URIs) until the specs
clarify the use cases for it. Here are the issues I'm seeing:
- Component URI is not clearly defined in the spec (there's an errata
for this), the name of the component cannot be used alone for nested
components, and concatenating names of nested components with a
domain URI is likely to cause ambiguities and collisions.
- Having a domain URI per node in a domain (proposed earlier in this
thread) is not in line with the spec.
- Also doing that will burn the node topology in the SCA domain
logical assembly, as you'll see the addresses of your nodes in the
URIs on your reference bindings, so the logical assembly won't be so
"logical" anymore :)
- We could say that the domain URI is just a logical URI, but then I
don't understand why we would need it at all, as specifying
domainURI/someURI in the URI of a reference binding would only
compete with the target attribute of a reference or wire.
- And if it was just a logical URI then I'm not sure why we'd need a
different URI per protocol.
So at this point I don't understand how this domain URI was intended
to be used and I think we should keep things simple. I'd suggest to
not try to use a domain URI to calculate any binding URIs for now,
and ask application developers and assemblers to specify the URIs
they want explicitly.
If anyone out there has a requirement for domain URIs and can
articulate the use case and how it should work, please shout :)
Finally, the SCA assembly model is already able to store a single URI
in the domain's Composite model object (see Composite.get/setURI()),
so if people find a real use case and are OK to start with a single
domain URI, they can just use that.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
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]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
