 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / July 2005Add Web Service advice
Hello all We have an SOA application that includes an ASP.NET webservice and WinForms client. My question is regarding the use of Add Web Reference in Visual Studio. The tool is nice because it easilly creates and updates the client-side proxies that we need to communicate with the webservice. The problem is that our webservice methods accept and return business objects and when generating the proxies, VS creates scoped versions of these business objects for use with the webservice methods. It is undesirable to have the proxy generator create these business objects for several reasons: 1. There are some references to business objects that exist on separate webservices. For example, Customer.asmx has a GetCustomer method that returns a Customer object and Invoicing.asmx has a CreateInvoice method that takes a Customer object. These are the same customer object in both cases, so it would make sense that we could call Customer.GetCustomer and then pass the Customer object to Invoicing.CreateInvoice. The problem is that the proxy generator creates scoped versions of Customer when generating the proxy for both webservices, which means a CustomerProxy.Customer cannot be passed to a method expecting a InvoicingProxy.Customer. 2. The business objects contain helper methods that should ideally be available to the client application, so we'd like to continue to reference the business object library from the client as well. 3. The web service proxy generator changes properties to fields in the business objects. This prevents the WinForms combobox from being able to databind to a collection of the object with the DisplayMember and ValueMember properties set. For this reason, it seems ideal that the Client and Webservice should both reference the same business object class library, and that the Add Web Reference tool NOT create scoped versions of the business objects. Right now, we are getting around the behavior of Add Web Reference by using WSDL.exe to generate a proxy class and then removing the business object definitions by hand. This is a bit tedious, however, and I would like to be able to use Add Web Reference's functionality to both add new proxies and update existing ones as the webservice changes. Does anyone have any advice on what we can do here? Thanks, Eric Hi Eric, I'm having this problem too. I want to return business objects from a web service. I delete the custom class which is generated in the proxy, I then add a reference to the business object class library. I can return an object fine, the trouble is when i try to deserialise it at the other end, the object obtained is the object which is constructed by the default constructor. Ie. to reconstruct the object, the deserialisation process seems to use the default constructor and thus the values are incorrect. Can you tell me how you solve this problem ? Many thanks. > Hello all > [quoted text clipped - 42 lines] > Thanks, > Eric its better to use interfaces to construct webservices... > Hello all > [quoted text clipped - 42 lines] > Thanks, > Eric Hi Clemens, Are you referring to using a base WSDL contract to describe the webservice and then using the WSDL contract to generate client proxy and webservice skeletons? If so, we would still have the issue of the client proxy generator creating separately scoped versions of the business object classes for each webservice, and also fields being changed to properties. Or am I missing something? Thanks, Eric > its better to use interfaces to construct webservices... > [quoted text clipped - 44 lines] >> Thanks, >> Eric Greetings Eric, One of the issues you've identified is the need to share data types between web service proxies. This feature will be available in .NET 2.0 (http://www.theserverside.net/blogs/showblog.tss?id=WSStrikesBackP6), however, this does not address your immediate requirement. Thinktecture have a VS addin available called Web Service Contract First that provides data type sharing today (http://www.thinktecture.com/Resources/Software/WSContractFirst/default.html). It also generates properties instead of fields, which was one of the other issues you identified. With reference to sharing behaviour between tiers, strictly speaking, this is a violation of one of the tenents of service orientation, however, as always, there are times when rules can be broken. An example in this case would be to share validation logic between the tiers (as the implementation of this behaviour will be exactly the same in each tier). Perhaps you can factor this logic into helper classes that you can share between tiers instead? I wouldn't recommend sharing behaviour more complex than this though. Hope this helps. Cheers, Matt Hi Matt, Thank you for your comments and advice. I'll take a look at the ThinkTecture proxy generator. I would like to followup on your comments about "tenents of service orientation" in order to understand the issues better. I do understand that in many cases webservices are intended to be used by multiple foreign clients that have no formal connection with the webservice provider so there is little if any opportunity to share business object libraries. In a case where there is a base client application and webservice that are compiled as a unit, though, are there other reasons not to use a shared business object library? For a foreign client, a webservice proxy could still be generated that contains proxy business object classes, but for our in-house client this allows us to share a great deal of functionality. Eric > Greetings Eric, > [quoted text clipped - 22 lines] > Cheers, > Matt Hi Eric, Whilst there are numerous resources available declaring this tenant of service orientation, there are limited resources explaining the underlying reasoning. The following are my thoughts on why sharing types should be avoided as a starting point for distibuted applications. Perhaps the points raised will not be relevant to your system, this will be for you to decide. - Reduce coupling between services and their consumers Increasing coupling between services and their consumers leads to the following issues: 1. Difficulty maintaining shared functionality When complex logic is shared between tiers, it can become quite difficult to determine the implications of changes to the behaviour in each of the tiers. I have seen examples whereby such logic made extensive use of interfaces to allow differing behaviour to be substituted in the appropriate tiers, which made it difficult to see where behaviour was actually implemented (as interfaces were referencing interfaces which referenced further interfaces etc). Perhaps this is more an example of over-engineering, however, ultimately there was no reason to couple the tiers by using the same logic, and would have been much simpler if each tier had independently implemented its own functionality. This is why I believe only sharing simple functionality (such as validation) is appropriate. 2. Synchronisation/Versioning issues Functionality deployed to both tiers must be synchronised for consistency. If you have a sufficient client-side updating facility, this issue may not be relevant. - Security Functionality deployed to the client is susceptible to intrusion. Obfuscation, strong-naming and digital signing are mechanisms to deter such compromises, however, not deploying functionality to the client tier is an easier preventative measure. Furthermore, server-side functionality can be secured via role based security and other mechanisms provided by IIS/ASP.NET. There may be other reasons for not sharing types between tiers that I am not aware of, however, I hope this provides an insight into my initial advice. Cheers, Matt
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.