You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@apache.org> on 2007/07/26 11:33:43 UTC
Binding endpoints (was Fwd: Services and WSDL files
This is becoming one of the most often asked about and (i think) one of the
most confusing parts of using Tuscany, so how about we try to fix things up
a bit?
One problem is its just really hard to see where servlets get registered.
These days I often run with a local mod to servlet host that just does a
System.out.println of each servlet registration. Maybe I should just commit
that for now and we can delete it when we have some logging strategy in
place?
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?
Another problem is the runtime base uri is changing for our different
environments, for example the standalone Jetty runtime has an empty base
uri, where as the sample webapp ones have things like /services/ or other
samples /SCA/. That is user configurable in the web.xml, but how about at
least in all our samples we change that to be consistent?
Another kind of related problem is the way we require sca application
developers to know the intimate details of the structure of the Tuscany
build - you want to use web services you must add a <dependency> for
tuscany-binding-ws-axis2, if using Java components then you need to add
tuscany-implementation-java-runtime, etc for all the other things you may
want to use. We got the J2SE samples so you don't need to know any of that,
i think we could do the same for webapps. For example one way would be like
the distribution/webapp module strawman we have. That enables sca
applications to require no dependencies at all on any tuscany modules, you
just build your application jar using only things related to your
application and drop it into the webapp sca-contributions folder and it just
works. Would that be a better approach than what we do today for webapps?
...ant
---------- Forwarded message ----------
From: ant elder <an...@apache.org>
Date: Jul 26, 2007 9:59 AM
Subject: Re: Services and WSDL files
To: tuscany-user@ws.apache.org
On 7/26/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 7/26/07, Radim Kolarik <radim.list@googlemail.com > wrote:
> >
> > Hi Reymond,
> >
> > Thank you for your reply.
> >
> > How do I run the example if it is deployed to a web server, such as
> > Tomcat? I found an information about TuscanyServlet, which needs to be
> > in web.xml file, which I have now.
> >
> > Let's say that my server's root context and web app context URL is
> > http://localhost:8080/myWebApp . What do I have to add after this URL
> > to be able to access the application? According to SCA spec, the web
> > service WSDL should be available if the URL ends with ?wsdl. But if I
> > type http://localhost:8080/myWebApp/?wsdl in the browser, I get an
> > exception:
> >
> > SEVERE: Servlet.service() for servlet TuscanyServlet threw exception
> > java.lang.IllegalStateException: No servlet registered for path: /
> > at org.apache.tuscany.sca.webapp.TuscanyServlet.service(
> > TuscanyServlet.java:57)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (
> > ApplicationFilterChain.java:290)
> > at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > ApplicationFilterChain.java:206)
> > at org.apache.catalina.core.StandardWrapperValve.invoke (
> > StandardWrapperValve.java:230)
> > at org.apache.catalina.core.StandardContextValve.invoke(
> > StandardContextValve.java:175)
> > at org.apache.catalina.core.StandardHostValve.invoke (
> > StandardHostValve.java:128)
> > at org.apache.catalina.valves.ErrorReportValve.invoke(
> > ErrorReportValve.java:104)
> > at org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:109)
> > at org.apache.catalina.connector.CoyoteAdapter.service(
> > CoyoteAdapter.java:261)
> > at org.apache.coyote.http11.Http11Processor.process(
> > Http11Processor.java :844)
> > at
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
> > Http11Protocol.java:581)
> > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
> > JIoEndpoint.java :447)
> > at java.lang.Thread.run(Thread.java:595)
> >
> > I did some debugging on this and it seems that the servlet tries to
> > obtain a mapping from a Map, which is empty. Is this a bug or am I
> > just missing something in my .composite file or WSDL?
> >
> > Also, did you create the WSDL file manually or did you use any
> > generation tool provided by Tuscany?
> >
> > Thanks,
> > Radim
> >
> > On 7/25/07, Raymond Feng <en...@gmail.com> wrote:
> > > Hi, Radim.
> > >
> > > I'm not very sure if we already have the support to deploy an SCA
> > service as
> > > a web service without WSDL. If not, that's something we want to
> support
> > for
> > > sure.
> > >
> > > We have a sample to demonstrate the usage of SCA, web service and SDO.
>
> > It
> > > seems to be what you are looking for. You can see the sample code at:
> > >
> > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo
>
> >
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message -----
> > > From: "Radim Kolarik" < radim.list@googlemail.com >
> > > To: < tuscany-user@ws.apache.org>
> > > Sent: Wednesday, July 25, 2007 7:38 AM
> > > Subject: Services and WSDL files
> > >
> > >
> > > > Hi,
> > > >
> > > > Is it necessary to supply wsdl file if I want to deploy an SCA
> service
> > as
> > > > a
> > > > web service? Or can Tuscany generate the file "on the fly"?
> > > >
> > > > If I need to supply the file myself, what would be the best way to
> > > > generate
> > > > the file? Is it possible to generate the file for SDOs, if they are
> > > > service
> > > > parameters or if a service returns an SDO object as its result?
> > > >
> > > > Thanks,
> > > > Radim
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > Hi Radim
>
> Someone else is asking a similar question [1]. As part of this I made a
> sample [2] to experiment with exposing web services through the web app
> container. There are a few wrinkles in getting this to work. To make it
> work
> I hand created WSDL conatining a service URL that matched where I knew the
>
> service was going to be deployed. For example.
>
> In the sample [2] the URL that is registered with the web app relates to
> the
> single service that is described in the .composite file [3]
>
> <component name="AddServiceComponent">
> <implementation.java class="calculator.AddServiceImpl"/>
> <service name="AddService">
> <interface.java interface="calculator.AddService" />
> <binding.ws
> wsdlElement="http://calculator#wsdl.port(AddService/AddSoapPort)<http://calculator#wsdl.port%28AddService/AddSoapPort%29>
> < http://calculator/#wsdl.port%28AddService/AddSoapPort%29>"/>
> </service>
> </component>
>
> And, in this case, takes its value from the WSDL service description [3]
>
> <wsdl:service name="AddService">
>
> <wsdl:port binding="tns:AddSoapBinding" name="AddSoapPort">
>
> <wsdlsoap:address
> location="http://localhost:8080/sample-calculator-webapp-ws/services/AddService
> "/>
> </wsdl:port>
> </wsdl:service>
>
> I.e, I see the value.
>
> http://localhost:8080/sample-calculator-webapp-ws/services/AddServiceregistered
> in the WebAppServletHost
>
> The important thing here is that the URL I hand edited into the WSDL file
> matches the URL that the web app is deployed at. In my case I'm deploying
> the WAR to tomcat and it ends up at
> http://localhost:8080/sample-calculator-webapp-ws
> . The web.xml file maps "/services" to the TuscanyServlet so that appears
> too and finally the name of the service.
>
> Now this all feels a little complicated to me, I.e Reading the spec I
> would
> expect just to be able to specify a service name and have the runtime
> construct the URL automatically for me. In fact this is how I think the
> TuscanyServlet is coded, in that it only looks for registered servlets
> based
> on path info, and what I think the assembly spec says. The problem is it
> doesn't appear to be easy to configure the .composite file with just path
> info and also keep axis happy. I've tried a few things, e.g.
>
> <binding.ws>
> < binding.ws uri="...">
>
> But Axis complains. So maybe someone (Raymond?) can tell us what the magic
>
> rune is to make this work but for the time being the code in trunk works
> for
> the sample. I have opened JIRA TUSCANY-1481 on this so we have a marker
> but
> it sounds like you are making some progress debugging so feel free to
> attach notes if you feel it's appropriate.
>
> Regards
>
> Simon
>
>
> [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg01434.html
>
> Note. There are a couple of mails missing off this thread that I didn't
> send to the user list by accident. Just forwarded them now so hopefully
> the
> archive will catch up sortly
> [2]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/
>
>
> [3]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/Calculator.composite
> [4]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/wsdl/add.wsdl
>
>
See:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser
and: http://incubator.apache.org/tuscany/sca-java-bindingws.html
Basically, if you reference the WSDL port it will use that, otherwise the
url is constructed from the component name, service name and binding URI. I
find for services its easiest to just leave it all out eg ,< binding.ws/>,
in which case the uri will be the
[webappSerletUrl]/componentName/serviceName, and for references to
explicitly use the uri attribute, eg <binding.ws uri="
http://somehost/someService" />
...ant
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@apache.org>.
On 7/26/07, ant elder <an...@apache.org> wrote:
<snip>
Another problem is the runtime base uri is changing for our different
> environments, for example the standalone Jetty runtime has an empty base
> uri, where as the sample webapp ones have things like /services/ or other
> samples /SCA/. That is user configurable in the web.xml, but how about at
> least in all our samples we change that to be consistent?
I've just hit this issue again with the new helloworld sdo webapp sample
which has a testcase that uses our Jetty host and the sample creates a
deployable war. That results in the WS endpoint being different depending on
where its running, i.e. in the webapp case it includes the webapp name in
the url but the testcase using the jetty host doesn't include the name. I
guess this is related to the discussions on the runtime base URL but could
we somehow make that configurable so that from within a testcase its
possible to set the base url used by the Jetty host so that its the same as
used by the webapp host?
...ant
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Ant,
Working with the policy framework, the definitions.xml is the file
that lists all the intents and policysets that are applicable for an
SCA Domain. The Policy Fwk specs talks quite a bit about the contents
of this file - such as things like the BindingType, ImplementationType
etc.
As for having these in the SPI, I have started off with some
abstractions for these in
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy/src/main/java/org/apache/tuscany/sca/policy
as part of the PolicyFramework things which is still work in progress.
Once I have some thing substantial we could work on moving some things
as SPI. Having looked at definitions.xml before, it just about rung a
bell in the context of this discussion. Not sure if the specs folks
are going to like this proposition ;-)
- Venkat
On 7/30/07, ant elder <an...@apache.org> wrote:
> Thats pretty interesting. Though there's so little detail about
> definitions.xml I find it hard to work out what its for, could any spec
> people give a be more detail about this?
>
> One thing it talks about is using bindingType and implementationType
> elements to add new extensions, should we really be using these as part of
> the extension SPI?
>
> ...ant
>
> On 7/29/07, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > Hi,
> >
> > Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good
> > place to define the domain uri for various schemes for an SCA Domain.
> >
> > - Venkat
> >
> >
> > On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> > > On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > >
> > > >
> > > > On 7/28/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > > >
> > > > > [snip]
> > > > > ant elder wrote:
> > > > > >> 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.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Agreed. Something like this would be a vast improvement. And its
> > the
> > > > > best
> > > > > > way to make sure it works consistently across all binding
> > extensions.
> > > > > >
> > > > > >
> > > > > [snip]
> > > > >
> > > > > Ok I'll get started on that.
> > > > >
> > > > > >>>> And we need some configuration that describes the base URIs for
> > > > > each
> > > > > >>>> domain. The base URI information is part of the topology
> > > > > description
> > > > > >>>> but it
> > > > > >>>> doesn't get used yet so we need to get it into the SCADomain.
> > It
> > > > > >>>> should be
> > > > > >>>> configuratin of the "URI calculator" which could be in the
> > > > > extension
> > > > > >>>> registry so that all bindings can get at it.
> > > > > >>>>
> > > > > >> I'm not quite getting this part... the extension point registry
> > is
> > > > > >> well... a registry for extension points, an extension point
> > contains
> > > > > >> extensions (multiple extensions), I can't quite see how a URI
> > > > > calculator
> > > > > >> utility is an extension point.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > I'm guessing this is just being used as a way to pass base uri
> > > > > infomation
> > > > > > around as to date we don't really have a way to handle system
> > config
> > > > > data.
> > > > > > Whats an alterantive to using this registry?
> > > > > >
> > > > >
> > > > > If we're talking about a domain URI, this is typically model
> > information
> > > > > that can be hosted in a Top level Composite or Domain Composite or
> > > > > Domain model object, whatever we want to call it. If I understand
> > the
> > > > > spec correctly, the cardinality is: 1 Domain -> 1 base URI per
> > protocol
> > > > > used in the domain. The ExtensionPointRegistry is associated with a
> > > > > Runtime instance, not tied to a Domain. I'll propose a new model
> > object
> > > > > to host that domain-wide configuration.
> > > >
> > > >
> > > > Sounds good to me.
> > > >
> > > > I'm assuming when you say runtime instance here you mean something
> > like,
> > > > ReallySmallRuntime. Can you say if you have in your mind some specific
> > > > scenarios that leverage the difference between the domain model and
> > runtime
> > > > as they exist in the code at the moment, for example, by starting more
> > than
> > > > one runtime for a domain model. I'm happy if the answer is "not at
> > the
> > > > moment" and that it is just good architecture practice to separate
> > these
> > > > clearly distinct parts of the solution.
> > > >
> > > > [snip]
> > > > > >
> > > > > >> I guess it should be sufficient to report if we run in Jetty or
> > > > > Tomcat,
> > > > > >> right?
> > > > > >>
> > > > > >
> > > > > >
> > > > > > And there's webapp's or the hotupdate webapp, and doesn't this
> > also
> > > > > include
> > > > > > non http things like rmi host (and jms host if we ever get one of
> > > > > those)?
> > > > > >
> > > > > >
> > > > > Right, we have multiple options for HTTP hosts so it's interesting
> > to
> > > > > report which one is used.
> > > > >
> > > > > It looks like we have only one implementation for RMI or JMS at this
> > > > > point. So I was not thinking about spending time reporting which one
> > is
> > > > > used right now... I'll be happy to spend time sorting out which one
> > is
> > > > > used when we get to a point where we have multiple implementations
> > for
> > > > > these.
> > > > >
> > > > > >>> All those sound good, and just to add one more, i think there's
> > a
> > > > > bug
> > > > > >>> (unless its been fixed recently) in the standalone jetty/tomcat
> > > > > >>> runtimes so
> > > > > >>> that the port in a endpoint url is used but only for the first
> > > > > >>> endpoint. So
> > > > > >>> if you have two binding uri's http://localhost:8080/foo and
> > > > > >>> http://localhost:8085/bar then both services are exposed on the
> > same
> > > > > one
> > > > > >>> port and its just whichever port happened to get processed
> > first.
> > > > > >>>
> > > > > >> Yes, I've bumped into this one several times too... so I'd like
> > to
> > > > > >> volunteer to fix it.
> > > > > >>
> > > > > >> It looks like adding prints is under way too.
> > > > > >>
> > > > > >> In addition I'd like to do the following. When Tuscany starts,
> > make a
> > > > > >> Web Page available with its status, http://localhost:9090 for
> > > > > example,
> > > > > >> and on that page say Hello Tuscany has started or something like
> > > > > that,
> > > > > >> plus:
> > > > > >> 1. display the top level components started
> > > > > >> 2. display the services available and their endpoints
> > > > > >> 3. display the extensions loaded in the runtime
> > > > > >>
> > > > > >> I'll probably do 1 and 2 first, leaving 3 for later, depending on
> > how
> > > > >
> > > > > >> useful people think it is.
> > > > > >>
> > > > > >> If there's no objection, I'd like to add this sometime before the
> > end
> > > > > of
> > > > > >> the week.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > There's already a start of exactly this distribution/webapp which
> > i'd
> > > > > > planned to develop further, would you help?
> > > > > >
> > > > >
> > > > > Sure! Where is it? The scenario I'm most interested in is running
> > > > > Tuscany outside of a Web container, so I'd like to see if I can use
> > and
> > > > > add to what you have started in that environment.
> > > >
> > > >
> > > > distribution/webapp/src/main/webapp/scaDomainInfo.jsp
> > > >
> > > > --
> > > > > Jean-Sebastien
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > I forgot to say that, for completeness, we should extend the
> > cardinality a
> > > little to be accurate for the distributed case.
> > >
> > > 1 Domain -> n Nodes -> 1 base URI per protocol used in the node/domain.
> > > (see [1])
> > >
> > > So the logical domain will have n base URIs per protocol. This doesn't
> > > affect the change you are proposing immediately (the cardinality you
> > give is
> > > true of the part of the domain that is at each node) but I wanted to
> > extend
> > > this to distributed domains.
> > >
> > > Simon
> > >
> > > [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Terminology
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@apache.org>.
Thats pretty interesting. Though there's so little detail about
definitions.xml I find it hard to work out what its for, could any spec
people give a be more detail about this?
One thing it talks about is using bindingType and implementationType
elements to add new extensions, should we really be using these as part of
the extension SPI?
...ant
On 7/29/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi,
>
> Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good
> place to define the domain uri for various schemes for an SCA Domain.
>
> - Venkat
>
>
> On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> > On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > >
> > >
> > > On 7/28/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > >
> > > > [snip]
> > > > ant elder wrote:
> > > > >> 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.
> > > > >>
> > > > >
> > > > >
> > > > > Agreed. Something like this would be a vast improvement. And its
> the
> > > > best
> > > > > way to make sure it works consistently across all binding
> extensions.
> > > > >
> > > > >
> > > > [snip]
> > > >
> > > > Ok I'll get started on that.
> > > >
> > > > >>>> And we need some configuration that describes the base URIs for
> > > > each
> > > > >>>> domain. The base URI information is part of the topology
> > > > description
> > > > >>>> but it
> > > > >>>> doesn't get used yet so we need to get it into the SCADomain.
> It
> > > > >>>> should be
> > > > >>>> configuratin of the "URI calculator" which could be in the
> > > > extension
> > > > >>>> registry so that all bindings can get at it.
> > > > >>>>
> > > > >> I'm not quite getting this part... the extension point registry
> is
> > > > >> well... a registry for extension points, an extension point
> contains
> > > > >> extensions (multiple extensions), I can't quite see how a URI
> > > > calculator
> > > > >> utility is an extension point.
> > > > >>
> > > > >
> > > > >
> > > > > I'm guessing this is just being used as a way to pass base uri
> > > > infomation
> > > > > around as to date we don't really have a way to handle system
> config
> > > > data.
> > > > > Whats an alterantive to using this registry?
> > > > >
> > > >
> > > > If we're talking about a domain URI, this is typically model
> information
> > > > that can be hosted in a Top level Composite or Domain Composite or
> > > > Domain model object, whatever we want to call it. If I understand
> the
> > > > spec correctly, the cardinality is: 1 Domain -> 1 base URI per
> protocol
> > > > used in the domain. The ExtensionPointRegistry is associated with a
> > > > Runtime instance, not tied to a Domain. I'll propose a new model
> object
> > > > to host that domain-wide configuration.
> > >
> > >
> > > Sounds good to me.
> > >
> > > I'm assuming when you say runtime instance here you mean something
> like,
> > > ReallySmallRuntime. Can you say if you have in your mind some specific
> > > scenarios that leverage the difference between the domain model and
> runtime
> > > as they exist in the code at the moment, for example, by starting more
> than
> > > one runtime for a domain model. I'm happy if the answer is "not at
> the
> > > moment" and that it is just good architecture practice to separate
> these
> > > clearly distinct parts of the solution.
> > >
> > > [snip]
> > > > >
> > > > >> I guess it should be sufficient to report if we run in Jetty or
> > > > Tomcat,
> > > > >> right?
> > > > >>
> > > > >
> > > > >
> > > > > And there's webapp's or the hotupdate webapp, and doesn't this
> also
> > > > include
> > > > > non http things like rmi host (and jms host if we ever get one of
> > > > those)?
> > > > >
> > > > >
> > > > Right, we have multiple options for HTTP hosts so it's interesting
> to
> > > > report which one is used.
> > > >
> > > > It looks like we have only one implementation for RMI or JMS at this
> > > > point. So I was not thinking about spending time reporting which one
> is
> > > > used right now... I'll be happy to spend time sorting out which one
> is
> > > > used when we get to a point where we have multiple implementations
> for
> > > > these.
> > > >
> > > > >>> All those sound good, and just to add one more, i think there's
> a
> > > > bug
> > > > >>> (unless its been fixed recently) in the standalone jetty/tomcat
> > > > >>> runtimes so
> > > > >>> that the port in a endpoint url is used but only for the first
> > > > >>> endpoint. So
> > > > >>> if you have two binding uri's http://localhost:8080/foo and
> > > > >>> http://localhost:8085/bar then both services are exposed on the
> same
> > > > one
> > > > >>> port and its just whichever port happened to get processed
> first.
> > > > >>>
> > > > >> Yes, I've bumped into this one several times too... so I'd like
> to
> > > > >> volunteer to fix it.
> > > > >>
> > > > >> It looks like adding prints is under way too.
> > > > >>
> > > > >> In addition I'd like to do the following. When Tuscany starts,
> make a
> > > > >> Web Page available with its status, http://localhost:9090 for
> > > > example,
> > > > >> and on that page say Hello Tuscany has started or something like
> > > > that,
> > > > >> plus:
> > > > >> 1. display the top level components started
> > > > >> 2. display the services available and their endpoints
> > > > >> 3. display the extensions loaded in the runtime
> > > > >>
> > > > >> I'll probably do 1 and 2 first, leaving 3 for later, depending on
> how
> > > >
> > > > >> useful people think it is.
> > > > >>
> > > > >> If there's no objection, I'd like to add this sometime before the
> end
> > > > of
> > > > >> the week.
> > > > >>
> > > > >
> > > > >
> > > > > There's already a start of exactly this distribution/webapp which
> i'd
> > > > > planned to develop further, would you help?
> > > > >
> > > >
> > > > Sure! Where is it? The scenario I'm most interested in is running
> > > > Tuscany outside of a Web container, so I'd like to see if I can use
> and
> > > > add to what you have started in that environment.
> > >
> > >
> > > distribution/webapp/src/main/webapp/scaDomainInfo.jsp
> > >
> > > --
> > > > Jean-Sebastien
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > I forgot to say that, for completeness, we should extend the
> cardinality a
> > little to be accurate for the distributed case.
> >
> > 1 Domain -> n Nodes -> 1 base URI per protocol used in the node/domain.
> > (see [1])
> >
> > So the logical domain will have n base URIs per protocol. This doesn't
> > affect the change you are proposing immediately (the cardinality you
> give is
> > true of the part of the domain that is at each node) but I wanted to
> extend
> > this to distributed domains.
> >
> > Simon
> >
> > [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Terminology
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good
place to define the domain uri for various schemes for an SCA Domain.
- Venkat
On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >
> > On 7/28/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > > [snip]
> > > ant elder wrote:
> > > >> 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.
> > > >>
> > > >
> > > >
> > > > Agreed. Something like this would be a vast improvement. And its the
> > > best
> > > > way to make sure it works consistently across all binding extensions.
> > > >
> > > >
> > > [snip]
> > >
> > > Ok I'll get started on that.
> > >
> > > >>>> And we need some configuration that describes the base URIs for
> > > each
> > > >>>> domain. The base URI information is part of the topology
> > > description
> > > >>>> but it
> > > >>>> doesn't get used yet so we need to get it into the SCADomain. It
> > > >>>> should be
> > > >>>> configuratin of the "URI calculator" which could be in the
> > > extension
> > > >>>> registry so that all bindings can get at it.
> > > >>>>
> > > >> I'm not quite getting this part... the extension point registry is
> > > >> well... a registry for extension points, an extension point contains
> > > >> extensions (multiple extensions), I can't quite see how a URI
> > > calculator
> > > >> utility is an extension point.
> > > >>
> > > >
> > > >
> > > > I'm guessing this is just being used as a way to pass base uri
> > > infomation
> > > > around as to date we don't really have a way to handle system config
> > > data.
> > > > Whats an alterantive to using this registry?
> > > >
> > >
> > > If we're talking about a domain URI, this is typically model information
> > > that can be hosted in a Top level Composite or Domain Composite or
> > > Domain model object, whatever we want to call it. If I understand the
> > > spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
> > > used in the domain. The ExtensionPointRegistry is associated with a
> > > Runtime instance, not tied to a Domain. I'll propose a new model object
> > > to host that domain-wide configuration.
> >
> >
> > Sounds good to me.
> >
> > I'm assuming when you say runtime instance here you mean something like,
> > ReallySmallRuntime. Can you say if you have in your mind some specific
> > scenarios that leverage the difference between the domain model and runtime
> > as they exist in the code at the moment, for example, by starting more than
> > one runtime for a domain model. I'm happy if the answer is "not at the
> > moment" and that it is just good architecture practice to separate these
> > clearly distinct parts of the solution.
> >
> > [snip]
> > > >
> > > >> I guess it should be sufficient to report if we run in Jetty or
> > > Tomcat,
> > > >> right?
> > > >>
> > > >
> > > >
> > > > And there's webapp's or the hotupdate webapp, and doesn't this also
> > > include
> > > > non http things like rmi host (and jms host if we ever get one of
> > > those)?
> > > >
> > > >
> > > Right, we have multiple options for HTTP hosts so it's interesting to
> > > report which one is used.
> > >
> > > It looks like we have only one implementation for RMI or JMS at this
> > > point. So I was not thinking about spending time reporting which one is
> > > used right now... I'll be happy to spend time sorting out which one is
> > > used when we get to a point where we have multiple implementations for
> > > these.
> > >
> > > >>> All those sound good, and just to add one more, i think there's a
> > > bug
> > > >>> (unless its been fixed recently) in the standalone jetty/tomcat
> > > >>> runtimes so
> > > >>> that the port in a endpoint url is used but only for the first
> > > >>> endpoint. So
> > > >>> if you have two binding uri's http://localhost:8080/foo and
> > > >>> http://localhost:8085/bar then both services are exposed on the same
> > > one
> > > >>> port and its just whichever port happened to get processed first.
> > > >>>
> > > >> Yes, I've bumped into this one several times too... so I'd like to
> > > >> volunteer to fix it.
> > > >>
> > > >> It looks like adding prints is under way too.
> > > >>
> > > >> In addition I'd like to do the following. When Tuscany starts, make a
> > > >> Web Page available with its status, http://localhost:9090 for
> > > example,
> > > >> and on that page say Hello Tuscany has started or something like
> > > that,
> > > >> plus:
> > > >> 1. display the top level components started
> > > >> 2. display the services available and their endpoints
> > > >> 3. display the extensions loaded in the runtime
> > > >>
> > > >> I'll probably do 1 and 2 first, leaving 3 for later, depending on how
> > >
> > > >> useful people think it is.
> > > >>
> > > >> If there's no objection, I'd like to add this sometime before the end
> > > of
> > > >> the week.
> > > >>
> > > >
> > > >
> > > > There's already a start of exactly this distribution/webapp which i'd
> > > > planned to develop further, would you help?
> > > >
> > >
> > > Sure! Where is it? The scenario I'm most interested in is running
> > > Tuscany outside of a Web container, so I'd like to see if I can use and
> > > add to what you have started in that environment.
> >
> >
> > distribution/webapp/src/main/webapp/scaDomainInfo.jsp
> >
> > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > I forgot to say that, for completeness, we should extend the cardinality a
> little to be accurate for the distributed case.
>
> 1 Domain -> n Nodes -> 1 base URI per protocol used in the node/domain.
> (see [1])
>
> So the logical domain will have n base URIs per protocol. This doesn't
> affect the change you are proposing immediately (the cardinality you give is
> true of the part of the domain that is at each node) but I wanted to extend
> this to distributed domains.
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Terminology
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 7/28/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 7/28/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > ant elder wrote:
> > >> 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.
> > >>
> > >
> > >
> > > Agreed. Something like this would be a vast improvement. And its the
> > best
> > > way to make sure it works consistently across all binding extensions.
> > >
> > >
> > [snip]
> >
> > Ok I'll get started on that.
> >
> > >>>> And we need some configuration that describes the base URIs for
> > each
> > >>>> domain. The base URI information is part of the topology
> > description
> > >>>> but it
> > >>>> doesn't get used yet so we need to get it into the SCADomain. It
> > >>>> should be
> > >>>> configuratin of the "URI calculator" which could be in the
> > extension
> > >>>> registry so that all bindings can get at it.
> > >>>>
> > >> I'm not quite getting this part... the extension point registry is
> > >> well... a registry for extension points, an extension point contains
> > >> extensions (multiple extensions), I can't quite see how a URI
> > calculator
> > >> utility is an extension point.
> > >>
> > >
> > >
> > > I'm guessing this is just being used as a way to pass base uri
> > infomation
> > > around as to date we don't really have a way to handle system config
> > data.
> > > Whats an alterantive to using this registry?
> > >
> >
> > If we're talking about a domain URI, this is typically model information
> > that can be hosted in a Top level Composite or Domain Composite or
> > Domain model object, whatever we want to call it. If I understand the
> > spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
> > used in the domain. The ExtensionPointRegistry is associated with a
> > Runtime instance, not tied to a Domain. I'll propose a new model object
> > to host that domain-wide configuration.
>
>
> Sounds good to me.
>
> I'm assuming when you say runtime instance here you mean something like,
> ReallySmallRuntime. Can you say if you have in your mind some specific
> scenarios that leverage the difference between the domain model and runtime
> as they exist in the code at the moment, for example, by starting more than
> one runtime for a domain model. I'm happy if the answer is "not at the
> moment" and that it is just good architecture practice to separate these
> clearly distinct parts of the solution.
>
> [snip]
> > >
> > >> I guess it should be sufficient to report if we run in Jetty or
> > Tomcat,
> > >> right?
> > >>
> > >
> > >
> > > And there's webapp's or the hotupdate webapp, and doesn't this also
> > include
> > > non http things like rmi host (and jms host if we ever get one of
> > those)?
> > >
> > >
> > Right, we have multiple options for HTTP hosts so it's interesting to
> > report which one is used.
> >
> > It looks like we have only one implementation for RMI or JMS at this
> > point. So I was not thinking about spending time reporting which one is
> > used right now... I'll be happy to spend time sorting out which one is
> > used when we get to a point where we have multiple implementations for
> > these.
> >
> > >>> All those sound good, and just to add one more, i think there's a
> > bug
> > >>> (unless its been fixed recently) in the standalone jetty/tomcat
> > >>> runtimes so
> > >>> that the port in a endpoint url is used but only for the first
> > >>> endpoint. So
> > >>> if you have two binding uri's http://localhost:8080/foo and
> > >>> http://localhost:8085/bar then both services are exposed on the same
> > one
> > >>> port and its just whichever port happened to get processed first.
> > >>>
> > >> Yes, I've bumped into this one several times too... so I'd like to
> > >> volunteer to fix it.
> > >>
> > >> It looks like adding prints is under way too.
> > >>
> > >> In addition I'd like to do the following. When Tuscany starts, make a
> > >> Web Page available with its status, http://localhost:9090 for
> > example,
> > >> and on that page say Hello Tuscany has started or something like
> > that,
> > >> plus:
> > >> 1. display the top level components started
> > >> 2. display the services available and their endpoints
> > >> 3. display the extensions loaded in the runtime
> > >>
> > >> I'll probably do 1 and 2 first, leaving 3 for later, depending on how
> >
> > >> useful people think it is.
> > >>
> > >> If there's no objection, I'd like to add this sometime before the end
> > of
> > >> the week.
> > >>
> > >
> > >
> > > There's already a start of exactly this distribution/webapp which i'd
> > > planned to develop further, would you help?
> > >
> >
> > Sure! Where is it? The scenario I'm most interested in is running
> > Tuscany outside of a Web container, so I'd like to see if I can use and
> > add to what you have started in that environment.
>
>
> distribution/webapp/src/main/webapp/scaDomainInfo.jsp
>
> --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> I forgot to say that, for completeness, we should extend the cardinality a
little to be accurate for the distributed case.
1 Domain -> n Nodes -> 1 base URI per protocol used in the node/domain.
(see [1])
So the logical domain will have n base URIs per protocol. This doesn't
affect the change you are proposing immediately (the cardinality you give is
true of the part of the domain that is at each node) but I wanted to extend
this to distributed domains.
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Terminology
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
>
>> If we're talking about a domain URI, this is typically model information
>> that can be hosted in a Top level Composite or Domain Composite or
>> Domain model object, whatever we want to call it. If I understand the
>> spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
>> used in the domain. The ExtensionPointRegistry is associated with a
>> Runtime instance, not tied to a Domain. I'll propose a new model object
>> to host that domain-wide configuration.
>>
>
>
> Sounds good to me.
>
> I'm assuming when you say runtime instance here you mean something like,
> ReallySmallRuntime. Can you say if you have in your mind some specific
> scenarios that leverage the difference between the domain model and runtime
> as they exist in the code at the moment, for example, by starting more than
> one runtime for a domain model. I'm happy if the answer is "not at the
> moment" and that it is just good architecture practice to separate these
> clearly distinct parts of the solution.
>
>
One example: an administrator creates / edits / updates domain
configuration, without having started any runtime at all :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 7/28/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> ant elder wrote:
> >> 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.
> >>
> >
> >
> > Agreed. Something like this would be a vast improvement. And its the
> best
> > way to make sure it works consistently across all binding extensions.
> >
> >
> [snip]
>
> Ok I'll get started on that.
>
> >>>> And we need some configuration that describes the base URIs for each
> >>>> domain. The base URI information is part of the topology description
> >>>> but it
> >>>> doesn't get used yet so we need to get it into the SCADomain. It
> >>>> should be
> >>>> configuratin of the "URI calculator" which could be in the extension
> >>>> registry so that all bindings can get at it.
> >>>>
> >> I'm not quite getting this part... the extension point registry is
> >> well... a registry for extension points, an extension point contains
> >> extensions (multiple extensions), I can't quite see how a URI
> calculator
> >> utility is an extension point.
> >>
> >
> >
> > I'm guessing this is just being used as a way to pass base uri
> infomation
> > around as to date we don't really have a way to handle system config
> data.
> > Whats an alterantive to using this registry?
> >
>
> If we're talking about a domain URI, this is typically model information
> that can be hosted in a Top level Composite or Domain Composite or
> Domain model object, whatever we want to call it. If I understand the
> spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
> used in the domain. The ExtensionPointRegistry is associated with a
> Runtime instance, not tied to a Domain. I'll propose a new model object
> to host that domain-wide configuration.
Sounds good to me.
I'm assuming when you say runtime instance here you mean something like,
ReallySmallRuntime. Can you say if you have in your mind some specific
scenarios that leverage the difference between the domain model and runtime
as they exist in the code at the moment, for example, by starting more than
one runtime for a domain model. I'm happy if the answer is "not at the
moment" and that it is just good architecture practice to separate these
clearly distinct parts of the solution.
[snip]
> >
> >> I guess it should be sufficient to report if we run in Jetty or Tomcat,
> >> right?
> >>
> >
> >
> > And there's webapp's or the hotupdate webapp, and doesn't this also
> include
> > non http things like rmi host (and jms host if we ever get one of
> those)?
> >
> >
> Right, we have multiple options for HTTP hosts so it's interesting to
> report which one is used.
>
> It looks like we have only one implementation for RMI or JMS at this
> point. So I was not thinking about spending time reporting which one is
> used right now... I'll be happy to spend time sorting out which one is
> used when we get to a point where we have multiple implementations for
> these.
>
> >>> All those sound good, and just to add one more, i think there's a bug
> >>> (unless its been fixed recently) in the standalone jetty/tomcat
> >>> runtimes so
> >>> that the port in a endpoint url is used but only for the first
> >>> endpoint. So
> >>> if you have two binding uri's http://localhost:8080/foo and
> >>> http://localhost:8085/bar then both services are exposed on the same
> one
> >>> port and its just whichever port happened to get processed first.
> >>>
> >> Yes, I've bumped into this one several times too... so I'd like to
> >> volunteer to fix it.
> >>
> >> It looks like adding prints is under way too.
> >>
> >> In addition I'd like to do the following. When Tuscany starts, make a
> >> Web Page available with its status, http://localhost:9090 for example,
> >> and on that page say Hello Tuscany has started or something like that,
> >> plus:
> >> 1. display the top level components started
> >> 2. display the services available and their endpoints
> >> 3. display the extensions loaded in the runtime
> >>
> >> I'll probably do 1 and 2 first, leaving 3 for later, depending on how
> >> useful people think it is.
> >>
> >> If there's no objection, I'd like to add this sometime before the end
> of
> >> the week.
> >>
> >
> >
> > There's already a start of exactly this distribution/webapp which i'd
> > planned to develop further, would you help?
> >
>
> Sure! Where is it? The scenario I'm most interested in is running
> Tuscany outside of a Web container, so I'd like to see if I can use and
> add to what you have started in that environment.
distribution/webapp/src/main/webapp/scaDomainInfo.jsp
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
ant elder wrote:
>> 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.
>>
>
>
> Agreed. Something like this would be a vast improvement. And its the best
> way to make sure it works consistently across all binding extensions.
>
>
[snip]
Ok I'll get started on that.
>>>> And we need some configuration that describes the base URIs for each
>>>> domain. The base URI information is part of the topology description
>>>> but it
>>>> doesn't get used yet so we need to get it into the SCADomain. It
>>>> should be
>>>> configuratin of the "URI calculator" which could be in the extension
>>>> registry so that all bindings can get at it.
>>>>
>> I'm not quite getting this part... the extension point registry is
>> well... a registry for extension points, an extension point contains
>> extensions (multiple extensions), I can't quite see how a URI calculator
>> utility is an extension point.
>>
>
>
> I'm guessing this is just being used as a way to pass base uri infomation
> around as to date we don't really have a way to handle system config data.
> Whats an alterantive to using this registry?
>
If we're talking about a domain URI, this is typically model information
that can be hosted in a Top level Composite or Domain Composite or
Domain model object, whatever we want to call it. If I understand the
spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
used in the domain. The ExtensionPointRegistry is associated with a
Runtime instance, not tied to a Domain. I'll propose a new model object
to host that domain-wide configuration.
[snip]
>
>> I guess it should be sufficient to report if we run in Jetty or Tomcat,
>> right?
>>
>
>
> And there's webapp's or the hotupdate webapp, and doesn't this also include
> non http things like rmi host (and jms host if we ever get one of those)?
>
>
Right, we have multiple options for HTTP hosts so it's interesting to
report which one is used.
It looks like we have only one implementation for RMI or JMS at this
point. So I was not thinking about spending time reporting which one is
used right now... I'll be happy to spend time sorting out which one is
used when we get to a point where we have multiple implementations for
these.
>>> All those sound good, and just to add one more, i think there's a bug
>>> (unless its been fixed recently) in the standalone jetty/tomcat
>>> runtimes so
>>> that the port in a endpoint url is used but only for the first
>>> endpoint. So
>>> if you have two binding uri's http://localhost:8080/foo and
>>> http://localhost:8085/bar then both services are exposed on the same one
>>> port and its just whichever port happened to get processed first.
>>>
>> Yes, I've bumped into this one several times too... so I'd like to
>> volunteer to fix it.
>>
>> It looks like adding prints is under way too.
>>
>> In addition I'd like to do the following. When Tuscany starts, make a
>> Web Page available with its status, http://localhost:9090 for example,
>> and on that page say Hello Tuscany has started or something like that,
>> plus:
>> 1. display the top level components started
>> 2. display the services available and their endpoints
>> 3. display the extensions loaded in the runtime
>>
>> I'll probably do 1 and 2 first, leaving 3 for later, depending on how
>> useful people think it is.
>>
>> If there's no objection, I'd like to add this sometime before the end of
>> the week.
>>
>
>
> There's already a start of exactly this distribution/webapp which i'd
> planned to develop further, would you help?
>
Sure! Where is it? The scenario I'm most interested in is running
Tuscany outside of a Web container, so I'd like to see if I can use and
add to what you have started in that environment.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@apache.org>.
On 7/26/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> ant elder wrote:
> > On 7/26/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >> On 7/26/07, ant elder <an...@apache.org> wrote:
> >> >
> >> > This is becoming one of the most often asked about and (i think)
> >> one of
> >> > the
> >> > most confusing parts of using Tuscany, so how about we try to fix
> >> things
> >> > up
> >> > a bit?
> >> >
> >> > One problem is its just really hard to see where servlets get
> >> > registered.
> >> > These days I often run with a local mod to servlet host that just
> >> does a
> >> > System.out.println of each servlet registration. Maybe I should just
> >> > commit
> >> > that for now and we can delete it when we have some logging
> >> strategy in
> >> > place?
> >>
> >> +1 - I use a registry inspector component that I shove into the SCDL
> I'm
> >> testing but it's more complicated to use that just having the
> >> printout in
> >> place
>
> +1 to print the URIs of the endpoints of the services activated by
> Tuscany.
>
> >>
> >> 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.
Agreed. Something like this would be a vast improvement. And its the best
way to make sure it works consistently across all binding extensions.
>>
> >> And we need some configuration that describes the base URIs for each
> >> domain. The base URI information is part of the topology description
> >> but it
> >> doesn't get used yet so we need to get it into the SCADomain. It
> >> should be
> >> configuratin of the "URI calculator" which could be in the extension
> >> registry so that all bindings can get at it.
>
> I'm not quite getting this part... the extension point registry is
> well... a registry for extension points, an extension point contains
> extensions (multiple extensions), I can't quite see how a URI calculator
> utility is an extension point.
I'm guessing this is just being used as a way to pass base uri infomation
around as to date we don't really have a way to handle system config data.
Whats an alterantive to using this registry?
>>
> >> We should try and catch the case where an absolute URL is specified
> that
> >> doesn't match the result of the "URI Calculator".
>
> +1
>
> >>
> >> We should report is what extension is hosting each protocol. As we have
> >> multiple options in some cases this can be confusing if you have your
> >> classpath wrong.
> >>
>
> I guess it should be sufficient to report if we run in Jetty or Tomcat,
> right?
And there's webapp's or the hotupdate webapp, and doesn't this also include
non http things like rmi host (and jms host if we ever get one of those)?
>
> > All those sound good, and just to add one more, i think there's a bug
> > (unless its been fixed recently) in the standalone jetty/tomcat
> > runtimes so
> > that the port in a endpoint url is used but only for the first
> > endpoint. So
> > if you have two binding uri's http://localhost:8080/foo and
> > http://localhost:8085/bar then both services are exposed on the same one
> > port and its just whichever port happened to get processed first.
>
> Yes, I've bumped into this one several times too... so I'd like to
> volunteer to fix it.
>
> It looks like adding prints is under way too.
>
> In addition I'd like to do the following. When Tuscany starts, make a
> Web Page available with its status, http://localhost:9090 for example,
> and on that page say Hello Tuscany has started or something like that,
> plus:
> 1. display the top level components started
> 2. display the services available and their endpoints
> 3. display the extensions loaded in the runtime
>
> I'll probably do 1 and 2 first, leaving 3 for later, depending on how
> useful people think it is.
>
> If there's no objection, I'd like to add this sometime before the end of
> the week.
There's already a start of exactly this distribution/webapp which i'd
planned to develop further, would you help?
...ant
Re: Embedded servers now correctly support multiple ports, was: Binding
endpoints (was Fwd: Services and WSDL files
Posted by Simon Nash <na...@hursley.ibm.com>.
Sorry, I did not see this before doing the checkout and testing that
led to my creating TUSCANY-1501. I have rerun my test against the
latest trunk code and this is working now. I'll close TUSCANY-1501.
Simon
Jean-Sebastien Delfino wrote:
> [snip]
> Jean-Sebastien Delfino wrote:
>
>>
>>>
>>> All those sound good, and just to add one more, i think there's a bug
>>> (unless its been fixed recently) in the standalone jetty/tomcat
>>> runtimes so
>>> that the port in a endpoint url is used but only for the first
>>> endpoint. So
>>> if you have two binding uri's http://localhost:8080/foo and
>>> http://localhost:8085/bar then both services are exposed on the same one
>>> port and its just whichever port happened to get processed first.
>>
>>
>> Yes, I've bumped into this one several times too... so I'd like to
>> volunteer to fix it.
>>
>>
>
> This is now fixed, you should be able to register servlets under
> different port numbers and both the JettyServer and TomcatServer will
> take care of starting embedded servers listening on these ports.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Embedded servers now correctly support multiple ports, was: Binding
endpoints (was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Jean-Sebastien Delfino wrote:
>
>>
>> All those sound good, and just to add one more, i think there's a bug
>> (unless its been fixed recently) in the standalone jetty/tomcat
>> runtimes so
>> that the port in a endpoint url is used but only for the first
>> endpoint. So
>> if you have two binding uri's http://localhost:8080/foo and
>> http://localhost:8085/bar then both services are exposed on the same one
>> port and its just whichever port happened to get processed first.
>
> Yes, I've bumped into this one several times too... so I'd like to
> volunteer to fix it.
>
>
This is now fixed, you should be able to register servlets under
different port numbers and both the JettyServer and TomcatServer will
take care of starting embedded servers listening on these ports.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/6/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/6/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Simon Laws wrote:
> > > On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > >> ant elder wrote:
> > >>
> > >>> On 8/1/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > >>>
> > >>>
> > >>>> 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?
> > >>>>
> > >>>>
> > >>> So what is the proposal exactly - "ask application developers and
> > >>>
> > >> assemblers
> > >>
> > >>> to specify the URIs they want explicitly" - could there be some
> > examples
> > >>>
> > >> of
> > >>
> > >>> what that would mean for our various http based bindings?
> > >>>
> > >>> ...ant
> > >>>
> > >>>
> > >>>
> > >> I'm just proposing to continue to do what we already do today,
> > without
> > >> introducing a domain base URI configuration now as it's unclear at
> > this
> > >> point how it's going to be used and how it should work.
> > >>
> > >> Here are two sample composite files:
> > >>
> > >>
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
> > >>
> > >>
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
> > >>
> > >> I suggest to default the host to localhost, and the port to 8080 if
> > they
> > >> are not specified in the binding/@uri. This is what most bindings do
> > >> today. We still need to make sure that all HTTP based bindings use
> > the
> > >> specified binding/@uri consistently, there's no question about that.
> > >>
> > >> --
> > >> Jean-Sebastien
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >> This is a little problematic for the remote SCA Binding where we
> > could
> > >>
> > > default to localhost:8080 but don't necessarily have the ability to
> > define a
> > > specific URL. We could ask that binding.sca appears explicitly
> > whenever a
> > > non default URL is required but in that case you are probably better
> > off
> > > using an explicit binding where you have control over the protocol.
> > Can we
> > > say that Tuscany will define base scheme URLs for each node so that we
> > can
> > > configure the default sca binding?
> > >
> > > Simon
> > >
> > >
> >
> > Can you describe how you would use base scheme URLs for each node and
> > how it would help the SCA binding?
> >
> > From your other email about the SCA binding [1] I understand that a
> > node will advertise (in some repository or directory?) which services it
> > offers at which endpoint, so I'm still not sure what we'll do with a
> > base scheme URL for each node. Won't the other nodes get the endpoint
> > address of the services they need to talk to from that directory?
> >
> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21171.html
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Yeah, this is separate from the exchange of endpoint information between
> nodes.
>
> It's the case where we want to run up the SCA Binding to expose a service
> remotely. Say the axis2 version of the SCA Binding is being used. If we are
> running inside of some other container (Geronimo?) then I guess we get
> whatever endpoint that container is configured to give us so as long as we
> can work out what the resulting URL is then we are set.
>
> If however we a running an internal Tomcat/Jetty server and we go with the
> hard coded defaults you suggest the we get our services at
> http://localhost:8080 and again we are good to go. If we don't want this
> address what do we do?
>
> Simon
>
>
> Having spent a bit of time testing the sca binding it can be frustrating
when you want to run more than one SCADomain within a VM or in separate VMs
on the same machine when you are using the default HTTP support. Everything
tries to come up on the same port and clashes unless you go round and
configure each of your bindings for a separate port.
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/6/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Simon Laws wrote:
> > On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> ant elder wrote:
> >>
> >>> On 8/1/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>>
> >>>
> >>>> 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?
> >>>>
> >>>>
> >>> So what is the proposal exactly - "ask application developers and
> >>>
> >> assemblers
> >>
> >>> to specify the URIs they want explicitly" - could there be some
> examples
> >>>
> >> of
> >>
> >>> what that would mean for our various http based bindings?
> >>>
> >>> ...ant
> >>>
> >>>
> >>>
> >> I'm just proposing to continue to do what we already do today, without
> >> introducing a domain base URI configuration now as it's unclear at this
> >> point how it's going to be used and how it should work.
> >>
> >> Here are two sample composite files:
> >>
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
> >>
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
> >>
> >> I suggest to default the host to localhost, and the port to 8080 if
> they
> >> are not specified in the binding/@uri. This is what most bindings do
> >> today. We still need to make sure that all HTTP based bindings use the
> >> specified binding/@uri consistently, there's no question about that.
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >> This is a little problematic for the remote SCA Binding where we could
> >>
> > default to localhost:8080 but don't necessarily have the ability to
> define a
> > specific URL. We could ask that binding.sca appears explicitly whenever
> a
> > non default URL is required but in that case you are probably better off
> > using an explicit binding where you have control over the protocol. Can
> we
> > say that Tuscany will define base scheme URLs for each node so that we
> can
> > configure the default sca binding?
> >
> > Simon
> >
> >
>
> Can you describe how you would use base scheme URLs for each node and
> how it would help the SCA binding?
>
> From your other email about the SCA binding [1] I understand that a
> node will advertise (in some repository or directory?) which services it
> offers at which endpoint, so I'm still not sure what we'll do with a
> base scheme URL for each node. Won't the other nodes get the endpoint
> address of the services they need to talk to from that directory?
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21171.html
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Yeah, this is separate from the exchange of endpoint information between
nodes.
It's the case where we want to run up the SCA Binding to expose a service
remotely. Say the axis2 version of the SCA Binding is being used. If we are
running inside of some other container (Geronimo?) then I guess we get
whatever endpoint that container is configured to give us so as long as we
can work out what the resulting URL is then we are set.
If however we a running an internal Tomcat/Jetty server and we go with the
hard coded defaults you suggest the we get our services at
http://localhost:8080 and again we are good to go. If we don't want this
address what do we do?
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> ant elder wrote:
>>
>>> On 8/1/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>>
>>>> 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?
>>>>
>>>>
>>> So what is the proposal exactly - "ask application developers and
>>>
>> assemblers
>>
>>> to specify the URIs they want explicitly" - could there be some examples
>>>
>> of
>>
>>> what that would mean for our various http based bindings?
>>>
>>> ...ant
>>>
>>>
>>>
>> I'm just proposing to continue to do what we already do today, without
>> introducing a domain base URI configuration now as it's unclear at this
>> point how it's going to be used and how it should work.
>>
>> Here are two sample composite files:
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
>>
>> I suggest to default the host to localhost, and the port to 8080 if they
>> are not specified in the binding/@uri. This is what most bindings do
>> today. We still need to make sure that all HTTP based bindings use the
>> specified binding/@uri consistently, there's no question about that.
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> This is a little problematic for the remote SCA Binding where we could
>>
> default to localhost:8080 but don't necessarily have the ability to define a
> specific URL. We could ask that binding.sca appears explicitly whenever a
> non default URL is required but in that case you are probably better off
> using an explicit binding where you have control over the protocol. Can we
> say that Tuscany will define base scheme URLs for each node so that we can
> configure the default sca binding?
>
> Simon
>
>
Can you describe how you would use base scheme URLs for each node and
how it would help the SCA binding?
From your other email about the SCA binding [1] I understand that a
node will advertise (in some repository or directory?) which services it
offers at which endpoint, so I'm still not sure what we'll do with a
base scheme URL for each node. Won't the other nodes get the endpoint
address of the services they need to talk to from that directory?
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21171.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 8/1/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> 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?
> >>
> >
> >
> > So what is the proposal exactly - "ask application developers and
> assemblers
> > to specify the URIs they want explicitly" - could there be some examples
> of
> > what that would mean for our various http based bindings?
> >
> > ...ant
> >
> >
>
> I'm just proposing to continue to do what we already do today, without
> introducing a domain base URI configuration now as it's unclear at this
> point how it's going to be used and how it should work.
>
> Here are two sample composite files:
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
>
> I suggest to default the host to localhost, and the port to 8080 if they
> are not specified in the binding/@uri. This is what most bindings do
> today. We still need to make sure that all HTTP based bindings use the
> specified binding/@uri consistently, there's no question about that.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> This is a little problematic for the remote SCA Binding where we could
default to localhost:8080 but don't necessarily have the ability to define a
specific URL. We could ask that binding.sca appears explicitly whenever a
non default URL is required but in that case you are probably better off
using an explicit binding where you have control over the protocol. Can we
say that Tuscany will define base scheme URLs for each node so that we can
configure the default sca binding?
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 8/1/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> 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?
>>
>
>
> So what is the proposal exactly - "ask application developers and assemblers
> to specify the URIs they want explicitly" - could there be some examples of
> what that would mean for our various http based bindings?
>
> ...ant
>
>
I'm just proposing to continue to do what we already do today, without
introducing a domain base URI configuration now as it's unclear at this
point how it's going to be used and how it should work.
Here are two sample composite files:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/helloworldws.composite
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/src/main/resources/FeedAggregator.composite
I suggest to default the host to localhost, and the port to 8080 if they
are not specified in the binding/@uri. This is what most bindings do
today. We still need to make sure that all HTTP based bindings use the
specified binding/@uri consistently, there's no question about that.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@apache.org>.
On 8/1/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> 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?
So what is the proposal exactly - "ask application developers and assemblers
to specify the URIs they want explicitly" - could there be some examples of
what that would mean for our various http based bindings?
...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> I think we need this or something like it to generate URIs for callback
> endpoints. The Web Service binding support for callbacks is currently
> doing this. I'm not happy with forcing the user to specify an explicit
> URI for an endpoint that is generated by the runtime.
>
> Simon
>
I'm not quite following what you mean with callbacks:
- Why would callbacks be handled differently from regular services? I
thought we were going to make them work the same way?
- This discussion is about configuring a base domain URI, which - as
stated in the SCA assembly spec - will not apply to JMS for example, how
are you planning to determine callback endpoints for JMS?
- Could you describe how you're going to use a base domain URI to
generate URIs for callbacks with HTTP based bindings?
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Jean-Sebastien Delfino wrote:
> 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 :)
>
I think we need this or something like it to generate URIs for callback
endpoints. The Web Service binding support for callbacks is currently
doing this. I'm not happy with forcing the user to specify an explicit
URI for an endpoint that is generated by the runtime.
Simon
> 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?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> 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"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Raymond Feng <en...@gmail.com>.
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
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
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"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Raymond Feng <en...@gmail.com>.
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.
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.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Raymond Feng <en...@gmail.com>.
Hi,
The cases listed by Sebastien seem to match what the specs say. Here is my
understanding from a slightly different angle.
1) If the binding configuration defines an explict URI, it will be honored.
As Sebasiten listed, different bindings define how the explict URI is
provided.
2) If no explict URI is provided, the binding URI is calculated based on the
metadata including the name of the binding (The SCA assembly spec defines an
algorithm).
3) The absolute URI will be taken as-is.
4) The reative URI will be combined with the domain base URI (pattern) to
derive the absolute URI.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, July 31, 2007 12:43 PM
Subject: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
> Jean-Sebastien Delfino wrote:
[snip]
> 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.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/15/07, ant elder <an...@gmail.com> wrote:
>
> On 8/15/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >
> > On 8/15/07, ant elder <an...@gmail.com> wrote:
> > >
> > > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > >
> > > > ant elder wrote:
> > > > > On 8/15/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > > > >
> > > > >> 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.
> > > > >>>
> > > > >>>
> > > > >> Default values for service binding URIs are now initialized by
> > > > >> CompositeBuilder, so binding extensions do not have to repeat
> that
> > > > logic
> > > > >> anymore.
> > > > >>
> > > > >> Service binding extensions can now call binding.getURI() and get:
> > > > >>
> > > > >> - binding/@uri if it the specified URI is absolute
> > > > >>
> > > > >> - component URI + binding/@uri if the specified URI is relative
> > > > >> ../ ./ etc. are supported as supported by java.net.URI
> > > > >> for a domain level composite service, component URI is empty
> > > > >> for a service on a domain level component, component URI is the
> > > > >> component name
> > > > >> for a nested component, component URI is the sum of the names of
> > > the
> > > > >> nested components separated by '/'
> > > > >>
> > > > >> - component URI / binding/@name if no URI is specified on the
> > > binding
> > > > >>
> > > > >> - component URI / service/@name if no binding name is specified
> > > > >>
> > > > >> Binding extensions are still responsible for determining the
> > > effective
> > > > >> URI, choosing their specific protocol scheme, or applying any
> other
> > > > >> binding-specific precedence rules (for example the Web Service
> > > binding
> > > > >> needs to consider the URI specified in a WSDL port or WSDL
> > > endpoint).
> > > > >>
> > > > >
> > > > >
> > > > > Why is component URI empty for a service on a domain level
> > > component? Is
> > > > > that in the spec somewhere?
> > > > >
> > > > > ...ant
> > > > >
> > > > >
> > > >
> > > > Not for a domain level component, but for a domain level composite
> > > > service.
> > > >
> > > > From my original description:
> > > > "for a domain level composite service, component URI is empty"
> > > >
> > > > From the assembly spec:
> > > >
> > > > 2380 Services deployed into the Domain (as opposed to services of
> > > > components) have a URI that does
> > > > 2381 not include a component name
> > >
> > >
> > > Ok i see, thanks for the line numbers.
> > >
> > > The website page on binding.ws describes this a bit but i think I'm
> > > going to
> > > a new page on the website just about how binding uri's work and link
> to
> > > that
> > > from the other binding pages. Anyone feel free to help out and make it
> > > as
> > > clear as possible.
> > >
> > > ...ant
> > >
> > I'd like to make sure this is absolutely clear in my mind (if no one
> > else's). What would you like me to do?
> >
> > Simon
> >
>
> The page i've started is at
>
> http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding+endpoints
>
> So the idea was just add a bunch more examples of different configurations
> and the resulting endpoints, maybe also adding a sentence or two saying
> how
> the endpoint is arrived at for each example. Does that sound ok / useful?
> Feel free to suggest alternative approaches , add different examples or
> more
> description etc.
>
> ...ant
>
Sounds very useful, I'll take a look.
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@gmail.com>.
On 8/15/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/15/07, ant elder <an...@gmail.com> wrote:
> >
> > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > > ant elder wrote:
> > > > On 8/15/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > > >
> > > >> 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.
> > > >>>
> > > >>>
> > > >> Default values for service binding URIs are now initialized by
> > > >> CompositeBuilder, so binding extensions do not have to repeat that
> > > logic
> > > >> anymore.
> > > >>
> > > >> Service binding extensions can now call binding.getURI() and get:
> > > >>
> > > >> - binding/@uri if it the specified URI is absolute
> > > >>
> > > >> - component URI + binding/@uri if the specified URI is relative
> > > >> ../ ./ etc. are supported as supported by java.net.URI
> > > >> for a domain level composite service, component URI is empty
> > > >> for a service on a domain level component, component URI is the
> > > >> component name
> > > >> for a nested component, component URI is the sum of the names of
> > the
> > > >> nested components separated by '/'
> > > >>
> > > >> - component URI / binding/@name if no URI is specified on the
> > binding
> > > >>
> > > >> - component URI / service/@name if no binding name is specified
> > > >>
> > > >> Binding extensions are still responsible for determining the
> > effective
> > > >> URI, choosing their specific protocol scheme, or applying any other
> > > >> binding-specific precedence rules (for example the Web Service
> > binding
> > > >> needs to consider the URI specified in a WSDL port or WSDL
> > endpoint).
> > > >>
> > > >
> > > >
> > > > Why is component URI empty for a service on a domain level
> > component? Is
> > > > that in the spec somewhere?
> > > >
> > > > ...ant
> > > >
> > > >
> > >
> > > Not for a domain level component, but for a domain level composite
> > > service.
> > >
> > > From my original description:
> > > "for a domain level composite service, component URI is empty"
> > >
> > > From the assembly spec:
> > >
> > > 2380 Services deployed into the Domain (as opposed to services of
> > > components) have a URI that does
> > > 2381 not include a component name
> >
> >
> > Ok i see, thanks for the line numbers.
> >
> > The website page on binding.ws describes this a bit but i think I'm
> > going to
> > a new page on the website just about how binding uri's work and link to
> > that
> > from the other binding pages. Anyone feel free to help out and make it
> > as
> > clear as possible.
> >
> > ...ant
> >
> I'd like to make sure this is absolutely clear in my mind (if no one
> else's). What would you like me to do?
>
> Simon
>
The page i've started is at
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding+endpoints
So the idea was just add a bunch more examples of different configurations
and the resulting endpoints, maybe also adding a sentence or two saying how
the endpoint is arrived at for each example. Does that sound ok / useful?
Feel free to suggest alternative approaches , add different examples or more
description etc.
...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/15/07, ant elder <an...@gmail.com> wrote:
>
> On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > ant elder wrote:
> > > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > >> 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.
> > >>>
> > >>>
> > >> Default values for service binding URIs are now initialized by
> > >> CompositeBuilder, so binding extensions do not have to repeat that
> > logic
> > >> anymore.
> > >>
> > >> Service binding extensions can now call binding.getURI() and get:
> > >>
> > >> - binding/@uri if it the specified URI is absolute
> > >>
> > >> - component URI + binding/@uri if the specified URI is relative
> > >> ../ ./ etc. are supported as supported by java.net.URI
> > >> for a domain level composite service, component URI is empty
> > >> for a service on a domain level component, component URI is the
> > >> component name
> > >> for a nested component, component URI is the sum of the names of the
> > >> nested components separated by '/'
> > >>
> > >> - component URI / binding/@name if no URI is specified on the binding
> > >>
> > >> - component URI / service/@name if no binding name is specified
> > >>
> > >> Binding extensions are still responsible for determining the
> effective
> > >> URI, choosing their specific protocol scheme, or applying any other
> > >> binding-specific precedence rules (for example the Web Service
> binding
> > >> needs to consider the URI specified in a WSDL port or WSDL endpoint).
> > >>
> > >
> > >
> > > Why is component URI empty for a service on a domain level component?
> Is
> > > that in the spec somewhere?
> > >
> > > ...ant
> > >
> > >
> >
> > Not for a domain level component, but for a domain level composite
> > service.
> >
> > From my original description:
> > "for a domain level composite service, component URI is empty"
> >
> > From the assembly spec:
> >
> > 2380 Services deployed into the Domain (as opposed to services of
> > components) have a URI that does
> > 2381 not include a component name
>
>
> Ok i see, thanks for the line numbers.
>
> The website page on binding.ws describes this a bit but i think I'm going
> to
> a new page on the website just about how binding uri's work and link to
> that
> from the other binding pages. Anyone feel free to help out and make it as
> clear as possible.
>
> ...ant
>
I'd like to make sure this is absolutely clear in my mind (if no one
else's). What would you like me to do?
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@gmail.com>.
On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> 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.
> >>>
> >>>
> >> Default values for service binding URIs are now initialized by
> >> CompositeBuilder, so binding extensions do not have to repeat that
> logic
> >> anymore.
> >>
> >> Service binding extensions can now call binding.getURI() and get:
> >>
> >> - binding/@uri if it the specified URI is absolute
> >>
> >> - component URI + binding/@uri if the specified URI is relative
> >> ../ ./ etc. are supported as supported by java.net.URI
> >> for a domain level composite service, component URI is empty
> >> for a service on a domain level component, component URI is the
> >> component name
> >> for a nested component, component URI is the sum of the names of the
> >> nested components separated by '/'
> >>
> >> - component URI / binding/@name if no URI is specified on the binding
> >>
> >> - component URI / service/@name if no binding name is specified
> >>
> >> Binding extensions are still responsible for determining the effective
> >> URI, choosing their specific protocol scheme, or applying any other
> >> binding-specific precedence rules (for example the Web Service binding
> >> needs to consider the URI specified in a WSDL port or WSDL endpoint).
> >>
> >
> >
> > Why is component URI empty for a service on a domain level component? Is
> > that in the spec somewhere?
> >
> > ...ant
> >
> >
>
> Not for a domain level component, but for a domain level composite
> service.
>
> From my original description:
> "for a domain level composite service, component URI is empty"
>
> From the assembly spec:
>
> 2380 Services deployed into the Domain (as opposed to services of
> components) have a URI that does
> 2381 not include a component name
Ok i see, thanks for the line numbers.
The website page on binding.ws describes this a bit but i think I'm going to
a new page on the website just about how binding uri's work and link to that
from the other binding pages. Anyone feel free to help out and make it as
clear as possible.
...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@gmail.com>.
On 8/15/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > ant elder wrote:
> > > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >
> > >> 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.
> > >>>
> > >>>
> > >> Default values for service binding URIs are now initialized by
> > >> CompositeBuilder, so binding extensions do not have to repeat that
> > logic
> > >> anymore.
> > >>
> > >> Service binding extensions can now call binding.getURI() and get:
> > >>
> > >> - binding/@uri if it the specified URI is absolute
> > >>
> > >> - component URI + binding/@uri if the specified URI is relative
> > >> ../ ./ etc. are supported as supported by java.net.URI
> > >> for a domain level composite service, component URI is empty
> > >> for a service on a domain level component, component URI is the
> > >> component name
> > >> for a nested component, component URI is the sum of the names of the
> > >> nested components separated by '/'
> > >>
> > >> - component URI / binding/@name if no URI is specified on the binding
> > >>
> > >> - component URI / service/@name if no binding name is specified
> > >>
> > >> Binding extensions are still responsible for determining the
> effective
> > >> URI, choosing their specific protocol scheme, or applying any other
> > >> binding-specific precedence rules (for example the Web Service
> binding
> > >> needs to consider the URI specified in a WSDL port or WSDL endpoint).
> > >>
> > >
> > >
> > > Why is component URI empty for a service on a domain level component?
> Is
> > > that in the spec somewhere?
> > >
> > > ...ant
> > >
> > >
> >
> > Not for a domain level component, but for a domain level composite
> > service.
> >
> > From my original description:
> > "for a domain level composite service, component URI is empty"
> >
> > From the assembly spec:
> >
> > 2380 Services deployed into the Domain (as opposed to services of
> > components) have a URI that does
> > 2381 not include a component name
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Your comment "Binding extensions are still responsible for determining
> the
> effective URI," describes a Tuscany specific mechanism where by the URI
> determined using the algorithm you describe is turned into the "effective
> URI" required by each binding extension.
>
> In the code today a number of bindings hardcode default endpoint
> information
> which is used to create the effective URI in the case where this
> information
> can't be extracted from binding.getURI()
>
> I would expect, at some point, to see a mechanism by which this hardcoded
> default information can be changed. From previously in this thread you do
> seem to be correct that this mechanism is not the "Base Domain URI for a
> scheme" which appears to be some logical URI for the entire domain. So
> another Tuscany specific mechanism is required.
>
> Simon
>
Don't we need something like this now and a way for extensions to get hold
of it, for example, so the web service binding can determine the complete
uri to include in the wsdl returned from ?wsdl. Could we just add a
something like a get base uri on the ServletHost interface?
...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> 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.
> >>>
> >>>
> >> Default values for service binding URIs are now initialized by
> >> CompositeBuilder, so binding extensions do not have to repeat that
> logic
> >> anymore.
> >>
> >> Service binding extensions can now call binding.getURI() and get:
> >>
> >> - binding/@uri if it the specified URI is absolute
> >>
> >> - component URI + binding/@uri if the specified URI is relative
> >> ../ ./ etc. are supported as supported by java.net.URI
> >> for a domain level composite service, component URI is empty
> >> for a service on a domain level component, component URI is the
> >> component name
> >> for a nested component, component URI is the sum of the names of the
> >> nested components separated by '/'
> >>
> >> - component URI / binding/@name if no URI is specified on the binding
> >>
> >> - component URI / service/@name if no binding name is specified
> >>
> >> Binding extensions are still responsible for determining the effective
> >> URI, choosing their specific protocol scheme, or applying any other
> >> binding-specific precedence rules (for example the Web Service binding
> >> needs to consider the URI specified in a WSDL port or WSDL endpoint).
> >>
> >
> >
> > Why is component URI empty for a service on a domain level component? Is
> > that in the spec somewhere?
> >
> > ...ant
> >
> >
>
> Not for a domain level component, but for a domain level composite
> service.
>
> From my original description:
> "for a domain level composite service, component URI is empty"
>
> From the assembly spec:
>
> 2380 Services deployed into the Domain (as opposed to services of
> components) have a URI that does
> 2381 not include a component name
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Your comment "Binding extensions are still responsible for determining the
effective URI," describes a Tuscany specific mechanism where by the URI
determined using the algorithm you describe is turned into the "effective
URI" required by each binding extension.
In the code today a number of bindings hardcode default endpoint information
which is used to create the effective URI in the case where this information
can't be extracted from binding.getURI()
I would expect, at some point, to see a mechanism by which this hardcoded
default information can be changed. From previously in this thread you do
seem to be correct that this mechanism is not the "Base Domain URI for a
scheme" which appears to be some logical URI for the entire domain. So
another Tuscany specific mechanism is required.
Simon
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> 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.
>>>
>>>
>> Default values for service binding URIs are now initialized by
>> CompositeBuilder, so binding extensions do not have to repeat that logic
>> anymore.
>>
>> Service binding extensions can now call binding.getURI() and get:
>>
>> - binding/@uri if it the specified URI is absolute
>>
>> - component URI + binding/@uri if the specified URI is relative
>> ../ ./ etc. are supported as supported by java.net.URI
>> for a domain level composite service, component URI is empty
>> for a service on a domain level component, component URI is the
>> component name
>> for a nested component, component URI is the sum of the names of the
>> nested components separated by '/'
>>
>> - component URI / binding/@name if no URI is specified on the binding
>>
>> - component URI / service/@name if no binding name is specified
>>
>> Binding extensions are still responsible for determining the effective
>> URI, choosing their specific protocol scheme, or applying any other
>> binding-specific precedence rules (for example the Web Service binding
>> needs to consider the URI specified in a WSDL port or WSDL endpoint).
>>
>
>
> Why is component URI empty for a service on a domain level component? Is
> that in the spec somewhere?
>
> ...ant
>
>
Not for a domain level component, but for a domain level composite service.
From my original description:
"for a domain level composite service, component URI is empty"
From the assembly spec:
2380 Services deployed into the Domain (as opposed to services of
components) have a URI that does
2381 not include a component name
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@gmail.com>.
On 8/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> 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.
> >
>
> Default values for service binding URIs are now initialized by
> CompositeBuilder, so binding extensions do not have to repeat that logic
> anymore.
>
> Service binding extensions can now call binding.getURI() and get:
>
> - binding/@uri if it the specified URI is absolute
>
> - component URI + binding/@uri if the specified URI is relative
> ../ ./ etc. are supported as supported by java.net.URI
> for a domain level composite service, component URI is empty
> for a service on a domain level component, component URI is the
> component name
> for a nested component, component URI is the sum of the names of the
> nested components separated by '/'
>
> - component URI / binding/@name if no URI is specified on the binding
>
> - component URI / service/@name if no binding name is specified
>
> Binding extensions are still responsible for determining the effective
> URI, choosing their specific protocol scheme, or applying any other
> binding-specific precedence rules (for example the Web Service binding
> needs to consider the URI specified in a WSDL port or WSDL endpoint).
Why is component URI empty for a service on a domain level component? Is
that in the spec somewhere?
...ant
Re: Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
>
Default values for service binding URIs are now initialized by
CompositeBuilder, so binding extensions do not have to repeat that logic
anymore.
Service binding extensions can now call binding.getURI() and get:
- binding/@uri if it the specified URI is absolute
- component URI + binding/@uri if the specified URI is relative
../ ./ etc. are supported as supported by java.net.URI
for a domain level composite service, component URI is empty
for a service on a domain level component, component URI is the
component name
for a nested component, component URI is the sum of the names of the
nested components separated by '/'
- component URI / binding/@name if no URI is specified on the binding
- component URI / service/@name if no binding name is specified
Binding extensions are still responsible for determining the effective
URI, choosing their specific protocol scheme, or applying any other
binding-specific precedence rules (for example the Web Service binding
needs to consider the URI specified in a WSDL port or WSDL endpoint).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Rules for determining binding endpoint URIs, was: Binding endpoints
(was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
ant elder wrote:
> On 7/26/07, Simon Laws <si...@googlemail.com> wrote:
>>
>> On 7/26/07, ant elder <an...@apache.org> wrote:
>> >
>> > This is becoming one of the most often asked about and (i think)
>> one of
>> > the
>> > most confusing parts of using Tuscany, so how about we try to fix
>> things
>> > up
>> > a bit?
>> >
>> > One problem is its just really hard to see where servlets get
>> > registered.
>> > These days I often run with a local mod to servlet host that just
>> does a
>> > System.out.println of each servlet registration. Maybe I should just
>> > commit
>> > that for now and we can delete it when we have some logging
>> strategy in
>> > place?
>>
>> +1 - I use a registry inspector component that I shove into the SCDL I'm
>> testing but it's more complicated to use that just having the
>> printout in
>> place
+1 to print the URIs of the endpoints of the services activated by Tuscany.
>>
>> 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.
>>
>> And we need some configuration that describes the base URIs for each
>> domain. The base URI information is part of the topology description
>> but it
>> doesn't get used yet so we need to get it into the SCADomain. It
>> should be
>> configuratin of the "URI calculator" which could be in the extension
>> registry so that all bindings can get at it.
I'm not quite getting this part... the extension point registry is
well... a registry for extension points, an extension point contains
extensions (multiple extensions), I can't quite see how a URI calculator
utility is an extension point.
>>
>> We should try and catch the case where an absolute URL is specified that
>> doesn't match the result of the "URI Calculator".
+1
>>
>> We should report is what extension is hosting each protocol. As we have
>> multiple options in some cases this can be confusing if you have your
>> classpath wrong.
>>
I guess it should be sufficient to report if we run in Jetty or Tomcat,
right?
>
> All those sound good, and just to add one more, i think there's a bug
> (unless its been fixed recently) in the standalone jetty/tomcat
> runtimes so
> that the port in a endpoint url is used but only for the first
> endpoint. So
> if you have two binding uri's http://localhost:8080/foo and
> http://localhost:8085/bar then both services are exposed on the same one
> port and its just whichever port happened to get processed first.
Yes, I've bumped into this one several times too... so I'd like to
volunteer to fix it.
It looks like adding prints is under way too.
In addition I'd like to do the following. When Tuscany starts, make a
Web Page available with its status, http://localhost:9090 for example,
and on that page say Hello Tuscany has started or something like that, plus:
1. display the top level components started
2. display the services available and their endpoints
3. display the extensions loaded in the runtime
I'll probably do 1 and 2 first, leaving 3 for later, depending on how
useful people think it is.
If there's no objection, I'd like to add this sometime before the end of
the week.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by ant elder <an...@apache.org>.
On 7/26/07, Simon Laws <si...@googlemail.com> wrote:
>
> Ant, you beat me too it;-) Having spent time yesterday trying to figure
> out how URLs are handled with the web app host I feel the pain. Some
> comments inline
>
> Simon
>
> On 7/26/07, ant elder <an...@apache.org> wrote:
> >
> > This is becoming one of the most often asked about and (i think) one of
> > the
> > most confusing parts of using Tuscany, so how about we try to fix things
> > up
> > a bit?
> >
> > One problem is its just really hard to see where servlets get
> > registered.
> > These days I often run with a local mod to servlet host that just does a
> > System.out.println of each servlet registration. Maybe I should just
> > commit
> > that for now and we can delete it when we have some logging strategy in
> > place?
>
>
> +1 - I use a registry inspector component that I shove into the SCDL I'm
> testing but it's more complicated to use that just having the printout in
> place
>
> 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?
>
>
> And we need some configuration that describes the base URIs for each
> domain. The base URI information is part of the topology description but it
> doesn't get used yet so we need to get it into the SCADomain. It should be
> configuratin of the "URI calculator" which could be in the extension
> registry so that all bindings can get at it.
>
> We should try and catch the case where an absolute URL is specified that
> doesn't match the result of the "URI Calculator".
>
> We should report is what extension is hosting each protocol. As we have
> multiple options in some cases this can be confusing if you have your
> classpath wrong.
>
All those sound good, and just to add one more, i think there's a bug
(unless its been fixed recently) in the standalone jetty/tomcat runtimes so
that the port in a endpoint url is used but only for the first endpoint. So
if you have two binding uri's http://localhost:8080/foo and
http://localhost:8085/bar then both services are exposed on the same one
port and its just whichever port happened to get processed first.
Another problem is the runtime base uri is changing for our different
> > environments, for example the standalone Jetty runtime has an empty base
> >
> > uri, where as the sample webapp ones have things like /services/ or
> > other
> > samples /SCA/. That is user configurable in the web.xml, but how about
> > at
> > least in all our samples we change that to be consistent?
>
>
> +1 to sample consistency. Re. the base uri. The least we can do is report
> which base uris are in operation for each binding/environment. A confusion
> for me is knowing which of the many pieces of information that can be
> specified wins. Again if we trap the case where what is specified doesn't
> match what the runtime calculates the uri should be then that would be a
> great help.
>
> Another kind of related problem is the way we require sca application
> > developers to know the intimate details of the structure of the Tuscany
> > build - you want to use web services you must add a <dependency> for
> > tuscany-binding-ws-axis2, if using Java components then you need to add
> > tuscany-implementation-java-runtime, etc for all the other things you
> > may
> > want to use. We got the J2SE samples so you don't need to know any of
> > that,
> > i think we could do the same for webapps. For example one way would be
> > like
> > the distribution/webapp module strawman we have. That enables sca
> > applications to require no dependencies at all on any tuscany modules,
> > you
> > just build your application jar using only things related to your
> > application and drop it into the webapp sca-contributions folder and it
> > just
> > works. Would that be a better approach than what we do today for
> > webapps?
>
>
> Not sure yet. What's the mode of operation with the distribution/webapp
> module? You deploy a distribution/webapp war and then deploy application
> jars to the sca-contributions folder?
>
Thats the way it works right now yes. Its like for example Axis2 or DWR
which have ready to run WAR distributions that you just download and deploy
and they have some sample applications in the repository (sca-contributions
folder) and users just add their own to that. Or we could do something else,
maybe have a maven archetype so its easy to create an application maven
project for sca webapps.
...ant
Re: Binding endpoints (was Fwd: Services and WSDL files
Posted by Simon Laws <si...@googlemail.com>.
Ant, you beat me too it;-) Having spent time yesterday trying to figure out
how URLs are handled with the web app host I feel the pain. Some comments
inline
Simon
On 7/26/07, ant elder <an...@apache.org> wrote:
>
> This is becoming one of the most often asked about and (i think) one of
> the
> most confusing parts of using Tuscany, so how about we try to fix things
> up
> a bit?
>
> One problem is its just really hard to see where servlets get registered.
> These days I often run with a local mod to servlet host that just does a
> System.out.println of each servlet registration. Maybe I should just
> commit
> that for now and we can delete it when we have some logging strategy in
> place?
+1 - I use a registry inspector component that I shove into the SCDL I'm
testing but it's more complicated to use that just having the printout in
place
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?
And we need some configuration that describes the base URIs for each
domain. The base URI information is part of the topology description but it
doesn't get used yet so we need to get it into the SCADomain. It should be
configuratin of the "URI calculator" which could be in the extension
registry so that all bindings can get at it.
We should try and catch the case where an absolute URL is specified that
doesn't match the result of the "URI Calculator".
We should report is what extension is hosting each protocol. As we have
multiple options in some cases this can be confusing if you have your
classpath wrong.
Another problem is the runtime base uri is changing for our different
> environments, for example the standalone Jetty runtime has an empty base
> uri, where as the sample webapp ones have things like /services/ or other
> samples /SCA/. That is user configurable in the web.xml, but how about at
> least in all our samples we change that to be consistent?
+1 to sample consistency. Re. the base uri. The least we can do is report
which base uris are in operation for each binding/environment. A confusion
for me is knowing which of the many pieces of information that can be
specified wins. Again if we trap the case where what is specified doesn't
match what the runtime calculates the uri should be then that would be a
great help.
Another kind of related problem is the way we require sca application
> developers to know the intimate details of the structure of the Tuscany
> build - you want to use web services you must add a <dependency> for
> tuscany-binding-ws-axis2, if using Java components then you need to add
> tuscany-implementation-java-runtime, etc for all the other things you may
> want to use. We got the J2SE samples so you don't need to know any of
> that,
> i think we could do the same for webapps. For example one way would be
> like
> the distribution/webapp module strawman we have. That enables sca
> applications to require no dependencies at all on any tuscany modules, you
> just build your application jar using only things related to your
> application and drop it into the webapp sca-contributions folder and it
> just
> works. Would that be a better approach than what we do today for webapps?
Not sure yet. What's the mode of operation with the distribution/webapp
module? You deploy a distribution/webapp war and then deploy application
jars to the sca-contributions folder?
...ant
>
> ---------- Forwarded message ----------
> From: ant elder <an...@apache.org>
> Date: Jul 26, 2007 9:59 AM
> Subject: Re: Services and WSDL files
> To: tuscany-user@ws.apache.org
>
>
>
> On 7/26/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 7/26/07, Radim Kolarik <radim.list@googlemail.com > wrote:
> > >
> > > Hi Reymond,
> > >
> > > Thank you for your reply.
> > >
> > > How do I run the example if it is deployed to a web server, such as
> > > Tomcat? I found an information about TuscanyServlet, which needs to be
> > > in web.xml file, which I have now.
> > >
> > > Let's say that my server's root context and web app context URL is
> > > http://localhost:8080/myWebApp . What do I have to add after this URL
> > > to be able to access the application? According to SCA spec, the web
> > > service WSDL should be available if the URL ends with ?wsdl. But if I
> > > type http://localhost:8080/myWebApp/?wsdl in the browser, I get an
> > > exception:
> > >
> > > SEVERE: Servlet.service() for servlet TuscanyServlet threw exception
> > > java.lang.IllegalStateException: No servlet registered for path: /
> > > at org.apache.tuscany.sca.webapp.TuscanyServlet.service(
> > > TuscanyServlet.java:57)
> > > at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (
> > > ApplicationFilterChain.java:290)
> > > at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> > > ApplicationFilterChain.java:206)
> > > at org.apache.catalina.core.StandardWrapperValve.invoke (
> > > StandardWrapperValve.java:230)
> > > at org.apache.catalina.core.StandardContextValve.invoke(
> > > StandardContextValve.java:175)
> > > at org.apache.catalina.core.StandardHostValve.invoke (
> > > StandardHostValve.java:128)
> > > at org.apache.catalina.valves.ErrorReportValve.invoke(
> > > ErrorReportValve.java:104)
> > > at org.apache.catalina.core.StandardEngineValve.invoke(
> > > StandardEngineValve.java:109)
> > > at org.apache.catalina.connector.CoyoteAdapter.service(
> > > CoyoteAdapter.java:261)
> > > at org.apache.coyote.http11.Http11Processor.process(
> > > Http11Processor.java :844)
> > > at
> > >
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
> > > Http11Protocol.java:581)
> > > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
> > > JIoEndpoint.java :447)
> > > at java.lang.Thread.run(Thread.java:595)
> > >
> > > I did some debugging on this and it seems that the servlet tries to
> > > obtain a mapping from a Map, which is empty. Is this a bug or am I
> > > just missing something in my .composite file or WSDL?
> > >
> > > Also, did you create the WSDL file manually or did you use any
> > > generation tool provided by Tuscany?
> > >
> > > Thanks,
> > > Radim
> > >
> > > On 7/25/07, Raymond Feng <en...@gmail.com> wrote:
> > > > Hi, Radim.
> > > >
> > > > I'm not very sure if we already have the support to deploy an SCA
> > > service as
> > > > a web service without WSDL. If not, that's something we want to
> > support
> > > for
> > > > sure.
> > > >
> > > > We have a sample to demonstrate the usage of SCA, web service and
> SDO.
> >
> > > It
> > > > seems to be what you are looking for. You can see the sample code
> at:
> > > >
> > > >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo
> >
> > >
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > ----- Original Message -----
> > > > From: "Radim Kolarik" < radim.list@googlemail.com >
> > > > To: < tuscany-user@ws.apache.org>
> > > > Sent: Wednesday, July 25, 2007 7:38 AM
> > > > Subject: Services and WSDL files
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > Is it necessary to supply wsdl file if I want to deploy an SCA
> > service
> > > as
> > > > > a
> > > > > web service? Or can Tuscany generate the file "on the fly"?
> > > > >
> > > > > If I need to supply the file myself, what would be the best way to
> > > > > generate
> > > > > the file? Is it possible to generate the file for SDOs, if they
> are
> > > > > service
> > > > > parameters or if a service returns an SDO object as its result?
> > > > >
> > > > > Thanks,
> > > > > Radim
> > > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > > Hi Radim
> >
> > Someone else is asking a similar question [1]. As part of this I made a
> > sample [2] to experiment with exposing web services through the web app
> > container. There are a few wrinkles in getting this to work. To make it
> > work
> > I hand created WSDL conatining a service URL that matched where I knew
> the
> >
> > service was going to be deployed. For example.
> >
> > In the sample [2] the URL that is registered with the web app relates to
> > the
> > single service that is described in the .composite file [3]
> >
> > <component name="AddServiceComponent">
> > <implementation.java class="calculator.AddServiceImpl"/>
> > <service name="AddService">
> > <interface.java interface="calculator.AddService" />
> > <binding.ws
> > wsdlElement="http://calculator#wsdl.port(AddService/AddSoapPort)<
> http://calculator#wsdl.port%28AddService/AddSoapPort%29>
> > < http://calculator/#wsdl.port%28AddService/AddSoapPort%29>"/>
> > </service>
> > </component>
> >
> > And, in this case, takes its value from the WSDL service description [3]
> >
> > <wsdl:service name="AddService">
> >
> > <wsdl:port binding="tns:AddSoapBinding" name="AddSoapPort">
> >
> > <wsdlsoap:address
> > location="
> http://localhost:8080/sample-calculator-webapp-ws/services/AddService
> > "/>
> > </wsdl:port>
> > </wsdl:service>
> >
> > I.e, I see the value.
> >
> >
> http://localhost:8080/sample-calculator-webapp-ws/services/AddServiceregistered
> > in the WebAppServletHost
> >
> > The important thing here is that the URL I hand edited into the WSDL
> file
> > matches the URL that the web app is deployed at. In my case I'm
> deploying
> > the WAR to tomcat and it ends up at
> > http://localhost:8080/sample-calculator-webapp-ws
> > . The web.xml file maps "/services" to the TuscanyServlet so that
> appears
> > too and finally the name of the service.
> >
> > Now this all feels a little complicated to me, I.e Reading the spec I
> > would
> > expect just to be able to specify a service name and have the runtime
> > construct the URL automatically for me. In fact this is how I think the
> > TuscanyServlet is coded, in that it only looks for registered servlets
> > based
> > on path info, and what I think the assembly spec says. The problem is
> it
> > doesn't appear to be easy to configure the .composite file with just
> path
> > info and also keep axis happy. I've tried a few things, e.g.
> >
> > <binding.ws>
> > < binding.ws uri="...">
> >
> > But Axis complains. So maybe someone (Raymond?) can tell us what the
> magic
> >
> > rune is to make this work but for the time being the code in trunk works
> > for
> > the sample. I have opened JIRA TUSCANY-1481 on this so we have a marker
> > but
> > it sounds like you are making some progress debugging so feel free to
> > attach notes if you feel it's appropriate.
> >
> > Regards
> >
> > Simon
> >
> >
> > [1]
> http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg01434.html
> >
> > Note. There are a couple of mails missing off this thread that I
> didn't
> > send to the user list by accident. Just forwarded them now so hopefully
> > the
> > archive will catch up sortly
> >
> [2]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/
> >
> >
> >
> [3]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/Calculator.composite
> >
> [4]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/wsdl/add.wsdl
> >
> >
>
> See:
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser
> and: http://incubator.apache.org/tuscany/sca-java-bindingws.html
>
> Basically, if you reference the WSDL port it will use that, otherwise the
> url is constructed from the component name, service name and binding URI.
> I
> find for services its easiest to just leave it all out eg ,< binding.ws/>,
> in which case the uri will be the
> [webappSerletUrl]/componentName/serviceName, and for references to
> explicitly use the uri attribute, eg <binding.ws uri="
> http://somehost/someService" />
>
> ...ant
>