One option I have available is to leave the web services in 1.1, but if I'm going to have to solve this problem eventually, I'd rather do it now. I'm trying to find a way to make this work in 2.0 so that I don't have to duplicate all of the query methods in the admin service. Any ideas out there?
Thanks,
Todd
The only difference for me is , there's not much login in my web service code , except acting as remote facade
example. All i culd suggest is to do lot sa refactoring, and move you business code to Domain Layer( BusinessAction). Not only you gain this benefit, but also , have the ability to expose the services through multiple channels. In our case, a plain XML(WSE) web services and TCP WSE Messaging and MSMQ easily implemented without too much of problem.
[WebMethod]
[return: XmlElementAttribute("ManageSurveillanceResponse", Namespace = //ivirtualsb.com/miss/managesurveillanceresponse" href="http://ivirtualsb.com/miss/managesurveillanceresponse">http://ivirtualsb.com/miss/managesurveillanceresponse)]
public ManageSurveillanceResponse ManageSurveillanceData(ManageSurveillanceRequest ManageSurveillanceRequest)
{
return new interVirtual.MiSS.Services.Surveillance.BusinessActions.InjurySurveillanceBusinessAction().ManageSurveillanceData(ManageSurveillanceRequest);
}
, the actual logic is in BusinessAction project, whic is a class library.
NOTE : forgive for the namespace , messup, it not my fault but they (MSDN ) had to do something about the formatting
My web services were already really just "wrappers" for the business/data layer, anyway.
I solved the problem using the following:
While this may be a little tougher to maintain than the previous solution, I still get the original benefits without too much work. If anyone has a more "elegant" way I could have done this, I'd love to hear about it.
Cheers,
Todd Gray
Whenever I add a new method to my ...Base class, then try to access that method through my admin class, I get a SOAP exception specifying that the "Server did not recognize the value of HTTP Header SOAPAction: ..." I have recompiled the project with the base classes, re-compiled the admin webservice, updated the web reference and recompiled the client. I even tried decorating my base class with [WebServiceBinding(Namespace=http://tempuri.org/)], and even that didn't work.
This is really wierd, because all of the methods I had written before conversion continue to work just fine. It's just methods that I'm adding since then. So, my solution may not be so great. Stay tuned...
Todd
Everything works fine using my original solution. Sorry for any confusion.Todd
Webservcie have two ends, one is the service end, another is conumer end. by referencing the first web service project, you are turning your second web service project into the consumer of the first web services, the first project exposed. which means all the functionalities first project have is invoked through http, in your case, you are not doing webservice agregation, so, it is very costly. putting the common functionality(query db) work in a common class library project(or called business component), this can be shared easliy by both webservice project i s the better solution in my opinion.
for a relatively complicated websercie project, putting data access code directly in a webmethod is not good solution.
Now then, I wanted to make it easier on clients consuming the admin functionality, and rather than having them add two web references, I wanted to include the query methods in the admin web services. But, I didn't want to duplicate the method code.
So, in .net 1.1, I added a reference to the DLL that was built for my query service, and had my admin service classes inherit from the query web service. For example, in my query project I have a class that looks something like this:
namespace Boeing { public class Airplane : System.Web.Services.WebService { [WebMethod] public DataSet GetAirplane(int SerialNo) { ... call data object ... } } } |
namespace Boeing { public class AirplaneAdmin : Airplane { [WebMethod] public UpdateAirplane(DataSet ds) { ... Call data object ... } } } |
So, the admin service isn't calling the query service as a web service, it's simply loading the query assembly into its process space and using the functionality in the base classes.
My solution for 2.0 was to strip all of the methods out of the query service and put them in a class library project that could be shared by both the query and admin services. So, my class library project has a class in it that looks like this:
namespace Boeing { public class AirplaneBase : System.Web.Services.WebService { [WebMethod] public DataSet GetAirplane(int SerialNo) { ... call data object ... } } } |
namespace Boeing { public class Airplane : AirplaneBase { } } |
namespace Boeing { public class AirplaneAdmin : AirplaneBase { [WebMethod] public UpdateAirplane(DataSet ds) { ... Call data object ... } } } |
So, I'm still just loading an assembly into my process and utilizing the code. I'm not aware of a more efficient way to use code than to load the assembly into your process space, but if there is one, I'd love to hear about it.
Hopefully this explains better what I'm doing. Sorry for the confusion, guys. You mentioned Web Service aggregation, which is a term I haven't heard before. I'll have to do some research on that to see if that would work better for me.
Cheers,
Todd
