Thanks for the comprehensive response Mike. Sorry I'm a little tardy in getting back to this. Have been heads down trying to solve some issues in the build.
Simon On 10/2/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Simon, > > Oh boy, I'm going to have to pick the bones out of this one... > > This may take more than one email to deal with since I fear that things > could get quite lengthy. > > First, how might the use of SOAP/JMS be represented in the SCA model? > > There is no single "right" answer to this - certainly not at the moment, > with the SCA Bindings spec group only just having this on their agenda > and the SOAP/JMS spec only just going towards publication and > standardization. > > How COULD it be done? > > 1) Treat SOAP/JMS as a completely separate binding, separate from > SOAP/HTTP. eg binding.soapjms > > 2) Treat SOAP/JMS as a variant of the binding.ws, selected by a > parameter supplied on the binding.ws element. > > 3) Treat SOAP/JMS as a variant of the binding.jms, selected by a > parameter on the binding.ws element > > 4) Treat SOAP/JMS as a variant of either or both binding.ws and > binding.jms, where the selection is done via an intent, as you are doing > in what follows. > > None of these is "right". They are all possible and they have their > pros and cons. Right. I just picked one as an education for me and to get this discussion going. Using a variant of binding.ws allows for the use of WSDL in a clear and > simple fashion. Use of a variant of binding.jms allows for > specification of JMS parameter values (things like Queue names, for > example). > > Simon Laws wrote: > > The new SOAP/JMS transport option in binding-ws-axis provided by Dinesh > > motivated me to go and look at how this new option (soap/jms) might be > > selected using the policy framework. This all started a while back with > this > > thread ( > http://www.mail-archive.com/[email protected]/msg20657.html). > > By way of a little education in the policy framework I've just looked at > the > > server side of things at the moment and have a few questions of those > who > > know policy better than I do.... > > > > I created a definitions.xml file with the following... > > > > <sca:intent name="transport.jms"> > > <sca:description> > > A JMS transport is required > > </sca:description> > > </sca:intent> > > > > This needs to declare what it attaches the intent to, using the > @constrains attribute, which is mandatory. > > constrains="sca:binding" > > will do, although this is an XPath expression which can get more > specific if you wish, eg "sca:binding.ws" Oops. That was a cut and past error on my part from the security sample. > <sca:policySet name="wsJMSTransportPolicy" > > provides="transport.jms" > > appliesTo="sca:binding.ws"> > > <tuscany:wsConfigParam> > > <parameter name="TuscanyQueueConnectionFactory"> > > <parameter name="java.naming.factory.initial"> > > org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> > > <parameter name="java.naming.provider.url > > ">tcp://localhost:61616</parameter> > > <parameter > > name="transport.jms.ConnectionFactoryJNDIName > ">QueueConnectionFactory</parameter> > > > > </parameter> > > </tuscany:wsConfigParam> > > </sca:policySet> > > > > This is OK, assuming that the binding implementation code that you have > for binding.ws does understand those wsConfigParam elements. I note > that this is inventing a new policy language. I think it is fair to ask > why you created a new language rather than use the WS-Policy language. Just a stepping stone to WS-Policy. I used what has currently implemented for the security policies. I have seen a subsequent post from Venkat saying that he is looking at ws-policy. I'd also like to ask which namespace the <parameter.../> elements are > coming from (I suspect I know but I'd appreciate hearing your intentions). They are in the default namespace currently as there are elements that match the Axis2 configuration mechanism. You are picking up here on my question about using this structure. I used it as it aready existed but I don;t think this is the way to go utimately. I envisage having a policy structure that is specific to the business of describing the JMS transport rather than being specific to the way that Axi2 is configured. One thing that worries me somewhat is that namimg provider url, which > seems awfully machine-dependent, even using localhost. It assumes that > all machines using this PolicySet will have port 61616 set for this > capability. On the other hand, perhaps in a more general distributed > system, it is reasonable that there is a central authority for this > capability on a fixed network address (eg tcp://foosystem:61616). Yep. It shouldn't be localhost. We do need to be able to configure the explicit location of the JNDI provider or provide a way as this bootstraps the JMS discovery mechanism. > I plumbed this into the Axis2ServiceProvider as an alternative to > providing > > this information via the binding.ws uri attibute so you can specify the > > following... > > > > <component name="HelloWorldServiceComponent"> > > <implementation.java class="helloworld.HelloWorldImpl" /> > > <service name="HelloWorldService"> > > <interface.wsdl interface=" > > http://helloworld#wsdl.interface(HelloWorld)" /> > > <binding.ws wsdlElement=" > > http://helloworld#wsdl.binding(HelloWorldSoapJmsBinding)" requires=" > > transport.jms"/> > > </service> > > </component> > > > > Quetions... > > > > - How does an SCA artifact, binding-ws in this case, advertise what > intents > > and policy sets can validly be specified. Is the intention that it is > > inferred through the policy set appliesTo attribute? > > OK, I think I can answer this one straightforwardly: > > There is a bindingType declaration element which goes into the > definitions.xml file. Pseudo-schema: > > <bindingType type="NCName" > alwaysProvides="listOfQNames"? > mayProvide="listOfQNames"?/> > > @alwaysProvides lists the set of intents that the binding always > supplies, irrespective of any configuration (eg an HTTPS binding would > always provide the "confidentiality" intent since messages are always > encrypted) > > @mayProvide lists the set of intents that the binding may provide if > configured with an appropriate PolicySet > > So you would say something like... > > <bindingType type="binding.ws" > alwaysProvides="....." > mayProvide="transport.jms ...."/> Ah, ok. I have forgotten about that. There seems to be many interrelated bits on information so I need to go back and work out what they are all for. > > > - I used the policy-scurity Axis2ConfigParamPolicy to structure the > policy > > here. This is more generally useful that security. It raises the > question > > about where we put policy implementations. > > Each in a separate module > > In one big module (possibly with separate package names) > > With the SCA artifact implementation to which they belong > > Somewhere else > > > > Umm "policy implementation" is a term that confuses me. I don't know > what you are talking about - do you mean a slice of code in the binding > implementation, or do you mean that PolicySet file up above? > > PolicySets can be constructed in a number of ways: > > - lots of separate ones each dealing with a particular area or domain of > policy (eg Security, Transactions, etc) > > - few large ones combining a whole series of areas of policy (typically > handled using IntentMaps....) > > take your pick, either is OK. This is the point about the Axis2 specific structure in the policy and I'm saying that it we are going to use it they having it in a modules called policy-security does't sounds like the right place for it. On the other hand I think we should move away from this Axis2 specific form. See my next point. > - This policy is very specific to Axis2. Well the information is general > but > > the parameters are structured as they are because this is the way that > Axis > > reads configuration parameters. In the end though I didn't end up > pushing > > them directly into Axis 2 so, in theory, they could be structured > > differently. It would be interesting to look at more general > alternatives, > > e.g. ws-policy. Are there any examples in the codebase yet? > > This is where the appliesTo attribute can come into its own. It is > possible to structure PolicySets that apply to a particular > implementation of binding.ws, as long as there is some feature of that > binding that can be picked out in XML terms. > > Defining something more general is probably best done through a request > to the OASIS Bindings TC, since it would necessarily be "standardized" > to apply to a range of implementations. In this particular case it comes down to whether we want the Axis2 binding to just apply the policy directly to its configuration or whether we are happy for it to interpret a more use friendly policy and then apply to result to its configuration. As it stands with these policies you have to get them correct as though you are writing Axis2 configuration files. > > > - I was originally going to drive the processing from the required > intents > > on the binding but they don't appear to be preserved in the model. Is > this > > intentional? > > Hmm, not clever - the intents are a very important part of selecting the > right policies. They will be necessary for wire matching and also for > configuring the binding. Needs investigation. > > > I haven't looked at the reference side of this yet. > > > > The non SCA client relies on the service location in the wsdl having the > > appropriate JMS configuration so the WSDL needs to be generated taking > > intents into account. > > Yeah, this will give some real entertainment to the WSDL generation code. :-) > > > In the case of an SCA client in the same domain I'm assuming we would > > expect the specification of a policy intent to be sufficient so > that this > > can be part of the reference/service matching process. Currently I > name > > the JMS queue after the service name so the minimum information is the > > contract, the reference target and the policy set. > > I suggest you look over the defaulting rules for the queue name as > defined in the JMS binding spec. Ok. > > > Regards > > > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
