Simon Laws wrote:
On Wed, Mar 5, 2008 at 12:52 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:
On Wed, Mar 5, 2008 at 6:01 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
Thanks Sebastien, Hopefully some insight on the puzzle in line...
Simon
On Mon, Mar 3, 2008 at 9:57 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]>
wrote:
I apologize in advance for the inline comment puzzle, but you had
started with a long email in the first place :)
no problem at all. Thanks for you detailed response.
snip...
I'm happy with workspace.configuration.impl. However applying default
binding configuration to bindings in a composition doesn't have much
to
do with the workspace so I'd suggest to push it down to assembly,
possible if you use a signature like I suggested above.
Ok I can do that.
B) The algorithm (A) that calculates service endpoints based on node
default
binding configurations depends on knowing the protocol that a
particular
binding is configured to use.
That part I don't get :) We could toy with the idea that SCA bindings
are not the right level of abstraction and that we need a transport
concept (or scheme or protocol, e.g. http) and the ability for
multiple
bindings (e.g. ws, atom, json) to share the same transport... But
that's
a whole different discussion IMO.
Can we keep this simply on a binding basis? and have a node declare
this:
<component ...>
<implementation.node ...>
<service...>
<binding.ws uri="http://localhost:1234/services"/>
<binding.jsonrpc uri="http://localhost:1234/services"/>
<binding.atom uri="http://localhost:9999/services"/>
</component>
Then the <binding.ws uri=...> declaration can provide the default
config
for all binding.ws on that node, <binding.jsonrpc> for all
binding.json,
<binding.atom> for all binding.atom etc. As you can see in this
example,
different bindings could use different ports... so, trying to share a
common transport will probably be less functional if it forces the
bindings sharing that transport to share a single port.
This is OK until you bring policy into the picture. A policy might
affect
the scheme a binding relies on so you may more realistically end up
with..
<component ...>
<implementation.node ...>
<service...>
<binding.ws uri="http://localhost:1234/services"/>
<binding.ws
uri="https://localhost:443/services<http://localhost:1234/services>"/>
<binding.jsonrpc uri="http://localhost:1234/services"/>
<binding.atom uri="http://localhost:9999/services"/>
</component>
And any particular, for example, binding.ws might required to be
defaulted
with "http://...";, "https://.."; or even not defaulted at all if it's
going
to use "jms:...". The issue with policies of course is that they are
not,
currently, applied until later on when the bindings are actually
activated.
So just looking at the model you can tell it has associated
intents/policy
but not what the implications are for the endpoint.
We can ignore this in the first instance I guess and run with the
restriction that you can't apply policy that affects the scheme to
bindings
inside the domain. But I'd be interested on you thoughts on the future
solution none the less. You will notice from the code that I haven't
actually done anything inside the bindings but just proposed that we
will
have to ask binding specific questions at some point during URL
creation.
Well, I think you're raising an interesting issue, but it seems to be
independent of any of this node business, more like a general issue with
the impact of policies on specified binding URIs.
I agree that if the binding URI were completed based on the processing of
the "build" phase then this conversation is independent of the default
values provided by nodes. This is not currently the case AFAIUI. The policy
model is built and matched at build phase but the policy sets are not
applied until the binding runtime is created. For example, the
Axis2ServiceProvider constructor is involved in setting the binding URI at
the moment. So in having an extension I was proposing a new place where
binding specific operations related to generating the URI could be housed
independently of the processing that happens when the providers are created.
In this way we would kick off this URL processing earlier on.
If I understand correctly, and I'm taking the store tutorial Catalog
component as an example to illustrate the issue:
<component name="CatalogServiceComponent">
<service name="Catalog" intents="ns:myEncryptionIntent">
<binding.ws uri="http://somehost:8080/catalog"/>
</service>
</component>
would in fact translate to:
<component name="CatalogComponent">
<service name="Catalog" intents="myEncryptionIntent">
<binding.ws uri="https://localhost:443/catalog"/>
</service>
</component>
assuming in this example that "myEncryptionIntent" is realized using
HTTPS on port 443.
Is that the issue you're talking about?
Yes, that's the issue, i.e. the binding specific code that makes this so
is not running during the build phase. I.e. the URI isn't resolved by
having a value poked in from outside the binding, rather the implications of
the policy set are processed by binding specific code and the URI results.
Another, non-policy related, issue has also come to mind....
<component name="CatalogComponent">
<service name="Catalog" intents="myEncryptionIntent">
<binding.ws wsdlElement="
http://test#wsdl.port(CatalogService/CatalogPort)<http://test#wsdl.port%28CatalogService/CatalogPort%29>"
/>
</service>
</component>
Particularly where where the port location is relative. Again the code
that applies WSDL details to the binding URI doesn't run until activation.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
So disregarding how we do binding specific URI processing at this build
stage, which is still an issue IMO, I've checked in some new code in the
CompositeConfigurationBuilderImpl that calculates service binding URIs. I've
not hooked it up to anything yet so it's not running except through the
JUnit test I added.
I would like to use this code during the build phase proper so that we only
have binding URI generation happening in one place. In due course I'll
switch over to it.
+1 from me.
I'll also look at how we do the binding specific bits
once we have agree here what needs to be done.
Now to make it work with Sebastien's workspace code.
Simon
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
