Hi Chinthaka, hi Rodrigo, 1) As Rodrigo has pointed out there is already an dependency of the service class to Axis2 because of the OperationContext class in the setOperationContext() method, if you need to access the framework. So having therefore an explicit interface does not hurt anyfurther.
2) Inversion of control is one of the pillars of framework design and using abstract classes and/or interfaces to define the (static) contract for the framework adaptation (how to plugin into the framework) is commonly used (see Building Applications Frameworks by Fayad et al). Maybe there are now tendencies to have more 'implicit contracts'. But I am not sure if I like that because in my opinon it is more complex to understand and to remember if you have to alter the service class months later and don't remember the 'magic' anymore. So my suggestion whould be to use an approach as it has been realized in the Apache Avalon component model: there is an set of optional interfaces which can be used if a component wants to get some dedicated data from the framework or participate in a special 'interaction'. So for the Axis2 toolkit this would mean: the vast majority of the sercie classes would have no dependency on the framework. If a service class has the requirement to access some specific data (like the SOAPHeader), then it can implement the corresponding interface, thus making the contract explicit. If the axis2 detects that the service class realizes some of these optional interfaces than it calls the approriate methods at the required time. This is in my opinon more simple to understand asnd therefore easier to maintain. As usual, only my(!!) thoughts on this ;-) Regards, Thomas -----Ursprüngliche Nachricht----- Von: Eran Chinthaka [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 14. Juli 2006 13:47 An: axis-user@ws.apache.org Betreff: Re: AW: How to access the SOAPHeader Hi Rodrigu, Rodrigo Ruiz wrote: > > Eran Chinthaka wrote: >> We didn't want to put any restriction on a user who wanna write a simple >> java class and expose that as a web service. Thats been the case so far. >> I hope you can understand that it will make the most common and simple >> case simple. >> And I don't see a single reason behind the service impl being dependent >> on the web services engine being used. So thats why we didn't wanna >> define a contract for the service implementor to implement. > > Sorry Chintaka, but I think I miss something here. Why does implementing > an Axis2 interface makes your service more implementation dependent than > adding a method that receives an Axis2 parameter? > > Once you need to pass an OperationContext instance you are > implementation dependent, aren't you?. Yes, that will happen iff you, as the service author, wanna get some information from the Axis2 environment. But, if you wanna deploy a simple service which does an xslt transformation on the recd xml, you don't wanna know what is happening in Axis2. Isn't it? -- Chinthaka --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
