Simon Laws 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.
OK (taking the policy processing aside), you're right that the
determination of the binding URI should not be done at all in the
Axis2ServiceProvider.
I would suggest the following:
- Recognize that this is a manifestation of a bigger issue (and the code
in Axis2ServiceProvider a hack to work around it). There is no extension
point for build-time processing of models at the moment. We have plug
points for read(), resolve() but nothing for build().
- Add a build(<T> model) method to ArtifactProcessor<T>.
- Invoke that method from CompositeBuilder() or one the related classes
in the builder package.
- Move the code responsible for the determination of the URI of a
binding to ArtifactProcessor.read(), resolve(), build() or a combination
of these as most convenient.
- Review the current policy processing and make sure that policies are
processed in the right stages, I won't discuss this here as I believe
that there's another discussion on policy applications currently going 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.
OK, so we need to move the policy processing code to the proper
composite build stage, and make sure that the build code that will
determine the binding URI - for example in ArtifactProcessor.build() or
another similar extension point - is able to at the policies attached to
the binding.
However, IMO this still has nothing to do with the node configuration.
Node configuration can be used to provide default values, before the
build process kicks in, like if the application developer had written
these default values in the <binding> in the composite file himself.
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.
Yes, same issue here, this code should run at model build time.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
