 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / April 20071.1 client to 2.0 web service
Hi all, I have some .net 1.1 web applications that connect to a .net 1.1 web service. I have generated the client proxy using the .net 1.1 wsdl tool and put it in the GAC. I now plan to upgrade the Web Service to .net 2.0, but still continue to leave the web applications in .net 1.1 for now until I can slowly do them. In order to do this, I will upgrade and test the Web Service in 2.0 and then continue to use the .net 1.1 WSDL tool to generate the client proxy to the new service. My question is this should in theory work right? Should I expect to see any breakage in my .net 1.1 web apps? TIA! > Hi all, > [quoted text clipped - 8 lines] > My question is this should in theory work right? Should I expect to see > any breakage in my .net 1.1 web apps? If your web service is platform independant, then there should be no difference between 1.1 and 2.0. You should be able to rewrite your web service in Java or Perl and still not have your clients break. John Hello Param, I agree with John that normally webservice's implementation is tranparent to webservice client, the client side just use the WSDL document to generate the client proxy which is used to visit the server-side service. No matter you're using java client or .net, you can create proxy against a ASPNET 1.1 or 2.0 webservice as long as it conforms to XML webservice standard. There does exists some new enhanced feature in ASP.NET 2.0 webservice which support some advanced interop feature like "WS-I" basic profile 1.1, if you do not want to use them(since you will consume it by .net 1.1 client), you can remove the WS-I basic profile 1.1 specific attributes. Anyway, a straighforward means to check the difference of webservice is compare the generated WSDL document before and after you upgrade from 1.1 to 2.0. Please feel free to post here if there is anything you wonder. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. The current 1.1 Web service returns some of the following object types:- 1. String 2. DataSet 3. Custom Class Objects I am presuming once I port it to 2.0 it will still generate the same WSDL. Where do I check the WS-I setting in Visual Studio 2005? TIA! > Hello Param, > [quoted text clipped - 24 lines] > This posting is provided "AS IS" with no warranties, and confers no > rights. > The current 1.1 Web service returns some of the following object types:- > [quoted text clipped - 3 lines] > > I am presuming once I port it to 2.0 it will still generate the same WSDL. Rather than depending on .NET to generate your WSDL, you should build it yourself. That way, it doesn't matter what .NET does. John Thanks for John's input. Hi Param, If the WSDL document remains the same or be consistent after upgrade to 2.0, I think the webservices should be ok to be consumed by 1.1 client. The WS-Basic profile 1.1 setting is configured through the following attribute: ========== [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public class WebService : System.Web.Services.WebService { ............. ============== You can remove the "ConformsTo = WsiProfiles.BasicProfile1_1" if no necessary. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. What is the benefit of that? Why re-invent the wheel? >> The current 1.1 Web service returns some of the following object types:- >> [quoted text clipped - 9 lines] > > John > What is the benefit of that? Why re-invent the wheel? You are not re-inventing the wheel. Understand what ASP.NET does for you. Every time someone requests the WSDL file with ?WSDL, ASP.NET will use Reflection to analyze your code and will manufacture a WSDL file for you. You will have to take care not to change your code in a way which will inadvertently change the manufactured WSDL. On the other hand, if you decide ahead of time what you want your WSDL should look like, you can change your code in any way you like, and the WSDL will not change. Since the WSDL is the contract between the client and the service, this is important. So, this isn't a question of re-inventing the wheel. Two totally different processes are occurring. On the one hand, ASP.NET manufactures a WSDL file, and you'll have to play around with attributes and such in order to make sure that the WSDL doesn't change when you change your code. On the other hand, you can decide what the WSDL should be, and keep it that way. John Hi Param, The approach john mentioned(auhor the WSDL ourselves before creatig service) is somewhat like the "contract-first" service development. Under such development routine, you create the webservice through the following steps: * Define XML Schema for elements that will be transfered in the webservice SOAP request/response message * define the WSDL document for your webservice (with the XML schema defined above) * generate webservice code that can produce SOAP message conforms to the above WSDL/xml schema the highlight of this approach is that the producted service will conform to our predefined XML schema and WSDL. Thus, it provides good interopability for heterogenious platforms to communication through the webservice. Because the client and server can create service and proxy through the predefined XML schema/WSDL. Here are some articles introducing Contract-First service development and how it works in ASP.NET asmx webservice: #Contract-First Service Development http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/default... #Techniques for Contract-First Development http://msdn.microsoft.com/msdnmag/issues/05/06/ServiceStation/ #Enrich Your XML Serialization With Schema Providers In The .NET Framework http://msdn.microsoft.com/msdnmag/issues/06/06/ClassToContract/defaul... Hope this also helps some. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. Those links should be: http://msdn.microsoft.com/msdnmag/issues/06/06/ClassToContract/ http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/ http://msdn.microsoft.com/msdnmag/issues/05/06/ServiceStation/ Dwight Walker > Hi Param, > [quoted text clipped - 39 lines] > This posting is provided "AS IS" with no warranties, and confers no > rights. > Those links should be: > http://msdn.microsoft.com/msdnmag/issues/06/06/ClassToContract/ > http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/ > http://msdn.microsoft.com/msdnmag/issues/05/06/ServiceStation/ this is wonderful > Dwight Walker > [quoted text clipped - 46 lines] >> This posting is provided "AS IS" with no warranties, and confers no >> rights. I just posted this question in another thread, not sure how I missed this one. I have done this exact thing and the clients do break, unless I delete and re-reference the webservice in the client apps projects and redistribute the app. Obviously this is not desireable. As long as the webservice has not changed, the clients should not care but they do! Help appreciated. >I just posted this question in another thread, not sure how I missed this >one. I have done this exact thing and the clients do break, unless I >delete and re-reference the webservice in the client apps projects and >redistribute the app. Obviously this is not desireable. As long as the >webservice has not changed, the clients should not care but they do! Help >appreciated. I've never seen the client care. Can you give an example? John Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.