On Fri, Mar 5, 2010 at 5:01 PM, Raymond Feng <[email protected]> wrote: > Comments inline. > > Thanks, > Raymond > -------------------------------------------------- > From: "Simon Laws" <[email protected]> > Sent: Friday, March 05, 2010 4:00 AM > To: <[email protected]>; <[email protected]> > Subject: Re: Propagating the SCA service endpoint address to the client > >> On Thu, Mar 4, 2010 at 11:00 PM, ant elder <[email protected]> wrote: >>> >>> On Fri, Mar 5, 2010 at 11:40 AM, Raymond Feng <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> When an SCA service is published to a binding protocol, it's assigned >>>> with >>>> an address (represented as a URI) so that the service can be accessed >>>> from >>>> the client side using that address. For example, a web service binding >>>> can >>>> be made available at http://myhost:9080/myService. >>>> >>>> We use the endpoint registry to propagate endpoint descriptions from the >>>> node that hosts the endpoint to other nodes in the SCA domain. The >>>> protocol-specific physical endpoint address needs to be carried with the >>>> endpoint description via the registry. The other tricky thing is to make >>>> sure the endpoint address is accessible from a different machine. This >>>> leads >>>> to a few cases: >>>> >>>> 1) The service binding URI is http://localhost:9080/myService. Should >>>> the >>>> localhost be left as-is or replaced with the host ip or name? >>>> 2) Should we use IP addess or host name? >>>> 3) What do we do if the host machine is multiple homed? >>>> >>>> For some of the bindings, we have ServletHost or RMIHost to represent >>>> the >>>> protocol stacks. The "regsiterService" can return a URI to represent a >>>> physical endpoint address that can be used outside of the hosting >>>> machine. >>>> >>>> Now we allow the binding.sca to be mapped to any of the bindings. It >>>> requires the mapped binding to propagate the physical URI to the client >>>> side >>>> too. >>>> >>>> Two questions to be answered: >>>> >>>> 1) How does a binding generate the physical endpoint address based on >>>> the >>>> binding URI and other information? >>>> 2) The binding provider should be responsible for setting the binding >>>> with >>>> the "deployed" URI (do we need to have a separate property in the >>>> Binding >>>> java model?) into the endpoint so that it can be propagated into the >>>> endpoint registry? >>>> >>>> >>> >>> Yep its a problem alright, i've been thing about too. >>> >>> The only way I can see it working well is if Tuscany has a proper >>> fixed base url per protocol and have _everything_ that uses that >>> protocol use that base url, that means anything that listens for >>> things remote requests eg the endpoint registry. Ideally as much as >>> possible we'd want to try to choose the value programatically so users >>> don't need to manually configure it, but that can get hard especially >>> with multiple network interfaces, virtual hosts, and public/private >>> host names. Pragmatically we're mainly interested in the host name/ip >>> addresses, so likely often times we might just need to manually >>> specify that/those when starting a Tuscany runtime. >>> >>> ...ant >>> >> >> In the binding.sca case: >> >> - There is no binding URI on the service side so we have to rely on >> the default binding URI generated schema for the binding that is >> mapped > > For binding.sca, the @uri attribute on service side is ignored. It will be > populated with the structural URI. The structural URI will be used by the > mapped binding to generate a physical endpoint address.
I think we're agreeing > >> - The URI on the reference is an SCA target name and we rely on the >> configuration of the service endpoint to configure the mapping on the >> reference. > > We need to make sure the @uri follows the <component>/<service>/<binding> > syntax. > +1 >> >> - Ant's point is a good one and I think we have taken this approach >> with the node configuration file where base URIs can be set for each >> scheme. > > The configured binding base URI will provide the accurate intension. What I > was asking is the case where a base URI is not defined. You would have to rely on some runtime default wouldn't you? > >> >> I wondering though whether the default URI generated for bindings used >> for remote binding sca support need to be different from default URIs >> generation for bindings added manually. For example, >> >> <component ...> >> <service ...> >> <binding.sca/> >> <binding.ws/> >> </service> >> </component> >> >> Assuming that ws maps to the sca binding, will that try to register >> the same service endpoint twice? > > This configuration is NOT valid. The SCA spec will require one of the > bindings to be configured with @name. The binding name will make the > structural URI unique within the same service. Doh, good point. > >> >> As to the questions... >> >> 1/ I think based on the algorithm embodied in BindingURIBuilderImpl, >> which pretty much takes the based URI for a scheme and adds either the >> structural URI or and relative stuff from the binding URI. > > Yes, I saw that. But the spec says the binding can choose to map it to a > physical URI on its own. The final URI is the deployed URI. It "can" so we need to decide if it will in Tuscany. We could have a binding builder interface that allows the binding to influence the final URI if we want this capability. > >> >> 2/ Can you say a bit more about why another field might be required? >> Is this to separate the deployed URI from what was originally entered >> by the user into the binding uri field? > > Yes. I was wondering if we need to separate the deployed URI from the > binding/@uri. Could be clearer in that we can visually compare the input binding URI with the resulting endpoint URI > >> >> Simon > > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
