Raymond Feng wrote:
That's why I keep saying it's a pattern rather than a fixed base URI :-).
I assume the base domain URI for (http, binding.ws) is something like:
http://$hostname$:8080/webservices (The $hostname$ will be replaced
during runtime when the service is activated on the http protocol.)
Thanks,
Raymond
Let's try to go a little further for a sec :)
- As you pointed, hostname must be configurable
- Port number must be configurable as well, across nodes, servers,
clusters etc.
- "webservices" cannot just be "webservices", as domain URIs are per
scheme and not per binding type (see the spec snippet I pasted below),
so "webservices" wouldn't really apply here. Also I doubt that anyone
can impose a base context path for all applications on all servers in
his SCA domain, and I'm not sure why he'd do that anyway... Actually, I
wonder if this can even work with a Web container like Tomcat for
example, unless you force all SCA services to be hosted in a single Web
app.
So I guess we're left with: http://$hostname$:$port$. Isn't this like
having no domain URI at all? :)
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 31, 2007 5:54 PM
Subject: Re: Rules for determining binding endpoint URIs, was: Binding
endpoints (was Fwd: Services and WSDL files
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]
---------------------------------------------------------------------
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]
