All, also +1 to go in that direction. Taking the policies from WSDL and generate a "ready to go client" would be nice.
However, the policy files are not designed (and it is also not their purpose) to hold every information necessary to actually generate and run the client. IMHO we need additional deployment descriptors to complement the information contained in the policies. For example, a policy may define that a token is required (e.g. X.509) but the policy does not define which token (i.e. who is the owner of the token). Also the WS Policy specifications are in flux and IMHO need some "brush-up" to be really usable. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Sanka Samaranayake [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 20. Februar 2006 06:02 > An: [email protected] > Betreff: Re: [Axis2]Associating more than one module aginst a > give policy namespace > > Srinath Perera wrote: > > Hi All; > > > > <big picture> > > I am talking about the client side (dynamic) policy. > > 1) We start with the WSDL that has policy attached. > > 2) At the WSDL parsing policies are attached to the > information model > > 3) We engage modules based on policy name spaces. > > 4) Each engaged module will be notified about the > engagement and they > > go look at the policy attachments and configure themselves based on > > the policy > > > > <dream>User get a WSDL, give it to a service client, and get service > > client configured. Then create a operation client and invoke. > > WS-Secuirty /RM etc all configured as given by the policy and just > > work </dream> > > </bigpicture> > > > > > > Some policy name spaces have a wide scope (e.g. Security) and should > > be covered with more than one module. For an example > authorization is > > not covered by WS-Security and I need to add authorization > module that > > handle it. > > > > Can we allow number of modules to register under same name space and > > when the policy is found every one get called. > > +1 > > It seems a valid usecase and I'll fix that in CodeGen > > Sanka > > Each configure himself > > for policy he can handle and store that in the Operation > object. (Each > > may tell Axis2 does he need to engaged or not ) > > > > <thought> > > when a module is called to notify that he is engaged, he should > > configure himself and store the configuration some where in the > > operation/service he is engaged. e.g. this could be Outflow > > Configuration/Inflow Configuration object for WS-Security. May be we > > want to revise the > > </thought> > > > > There are lot of detail to handle, but I want to know what people > > think about it. > > After a chat with Sanka, I plan to try to implement the scenario!! > > > > thoughts? > > > > Thanks > > Srinath > > > > > > -- > > ============================ > > Srinath Perera: > > http://www.cs.indiana.edu/~hperera/ > > http://www.bloglines.com/blog/hemapani > > >
