Vishal Mehra wrote:
> Thanks James,
>
> Yes, one can provide the business logic either in SOAPBindingStub.java or
> SOAPBindingImp.java but this does not solve the problem of moving the logic
> from existing java classes to any one of the above classes.
>
> Is there an automated way to transform the existing java classes to
> SOAPBindingImp.java? or an automated way to write wrapper (SOAPBindingImp)
> classes on top of existing java classes?
What I do is just have my SOAPBindingImp class just call the original java
classes that actually has the logic. So, it just serves as a way to tie
together many java classes and SOAP.
As to automation, there is none that I know of, but then, it isn't that hard
to just go through the server stubs made by wsdl2java and just have it return
what is in your business logic.
For example, if I have in my interface
public String method1(int somenum, String somestr) throws
java.rmi.RemoteException;
In the server stub I have
public String method1(int somenum, String somestr) ... {
SOAPBindingStub test = new SOAPBindingStub();
return test.method1(somenum, somestr);
}
In SOAPBindingStub:
public String method1(int somenum, String somestr) ... {
[business logic]
}
Why put all the business logic in SOAPBindingImp? You should keep logic in
the logical class, and just use the various components.
I hope this helps, if not, then I misunderstand what you are asking about.
