 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / August 2007Web service, generics and complex data types
HI, I'm having some problems with web services, as I cannot make them do what I need. I have a class called Order that has more classes inside. For example, I have Order. Addresses, in this case Addresses is a generic collection as (of Address) What I want is that my web service returns an object Order as it is, with all its properties as it is mean to be. Right now, the proxy generated when I reference the service (Reference.vb) downgrades the object Addresses to an object Address. What I need is the ability to get (thru the web service) an Order object as it was created, not downgraded, and also I need the ability to pass to the web service an object Order so I can persist this object to the DB thru the web service. How can I achieve this? Thanks > HI, > [quoted text clipped - 16 lines] > to the web service an object Order so I can persist this object to the > DB thru the web service. The Web Services platform is meant to be platform-neutral. Generics, in particular generic collections, are a platform-specific feature. As such, they should not be used in web services. In fact, there is no way in WSDL and XSD to describe a generic collection. But I suspect that you don't actually need a generic collection. You need to pass a set of Address data. Note that I don't say that you need to pass a set of Address objects, because that is fundamentally impossible. But you can pass a set of the data that an Address object is composed of. It seems quite old-fashioned, but you should be passing arrays of Address. There is a lot of behind-the-scenes magic that makes it easy to use Web Services. That is, they are easy to use, until they aren't easy to use any more. This magic obscures the process, so I'll briefly describe the process. 1) A client-side development tool (maybe VS "Add Web Reference") requests the WSDL from the server 2) ASP.NET on the server uses the .asmx file to create an instance of the web service class. It uses Reflection to examine the Web Service class and the other types used by that class as parameters and return values. It then creates a WSDL and schema that describes what it found, and returns that to the client-side development tool 3) The client-side tool will probably use the WSDL and schema to create proxy classes. These will be classes that can be serialized into XML that validates against the schema in the WSDL file, and classes that can make calls to the service described by the WSDL 4) You use the proxy classes to produce your client program 5) At run-time, your client program uses the proxy classes to create proxy objects that get serialized to XML that gets sent to the server, sends it to the server, gets XML responses from the server and deserializes the responses back into proxy objects Note that it is impossible for the client to use your server-side classes, so it will never be using your Order object "as it was created". The client will never be using your Order object at all! If you have a design that depends on the client using your actual Order object, then you should be using .NET Remoting and not Web Services.  SignatureJohn Saunders [MVP] John, I really appreciate the time you've taken to answer to may question. This is the work around that I found. I have all my vanilla classes in a project called Entities. The web service reference this project (or DLL) and of course he know what an object Customer is. What I have in the web services are methods what will return a serialized binary byte array. In the client side, I will deserialize and cast back to the proper object type (the client needs to reference Entities DLL though. If I have to expose the web methods to third parties, I will use SOAP serialization instead, to return raw XML. I benchmarked it and response times sound pretty fair to me. What do you think about the solution? -----Original Message----- From: John Saunders [MVP] [mailto:john.saunders at trizetto.com] Posted At: Thursday, August 30, 2007 10:19 AM Posted To: microsoft.public.dotnet.framework.webservices Conversation: Web service, generics and complex data types Subject: Re: Web service, generics and complex data types > HI, > [quoted text clipped - 16 lines] > to the web service an object Order so I can persist this object to the > DB thru the web service. The Web Services platform is meant to be platform-neutral. Generics, in particular generic collections, are a platform-specific feature. As such, they should not be used in web services. In fact, there is no way in WSDL and XSD to describe a generic collection. But I suspect that you don't actually need a generic collection. You need to pass a set of Address data. Note that I don't say that you need to pass a set of Address objects, because that is fundamentally impossible. But you can pass a set of the data that an Address object is composed of. It seems quite old-fashioned, but you should be passing arrays of Address. There is a lot of behind-the-scenes magic that makes it easy to use Web Services. That is, they are easy to use, until they aren't easy to use any more. This magic obscures the process, so I'll briefly describe the process. 1) A client-side development tool (maybe VS "Add Web Reference") requests the WSDL from the server 2) ASP.NET on the server uses the .asmx file to create an instance of the web service class. It uses Reflection to examine the Web Service class and the other types used by that class as parameters and return values. It then creates a WSDL and schema that describes what it found, and returns that to the client-side development tool 3) The client-side tool will probably use the WSDL and schema to create proxy classes. These will be classes that can be serialized into XML that validates against the schema in the WSDL file, and classes that can make calls to the service described by the WSDL 4) You use the proxy classes to produce your client program 5) At run-time, your client program uses the proxy classes to create proxy objects that get serialized to XML that gets sent to the server, sends it to the server, gets XML responses from the server and deserializes the responses back into proxy objects Note that it is impossible for the client to use your server-side classes, so it will never be using your Order object "as it was created". The client will never be using your Order object at all! If you have a design that depends on the client using your actual Order object, then you should be using .NET Remoting and not Web Services. SignatureJohn Saunders [MVP] > John, I really appreciate the time you've taken to answer to may > question. [quoted text clipped - 11 lines] > If I have to expose the web methods to third parties, I will use SOAP > serialization instead, to return raw XML. I'm sorry, but you've made precisely the mistake I was talking about, and it's a very serious mistake. Your client and server _cannot_ use the same DLL with web services. The fact that you have discovered a hack that seems to work does not change this fact. For instance, what about versioning? You'll have to change your client in lockstep with your server. In fact, you have tightly bound the client and server together. They'd just as well be one thing, except that they are on different machines with a network between them. You should be using .NET Remoting instead of web services. In fact, you seem to be re-inventing .NET Remoting as you go along. It will do all of this for you, and it will do a better job of it than you are likely to do, as they have considered scenarios encountered by many users, not just those that you have thought of already. > I benchmarked it and response times sound pretty fair to me. > What do you think about the solution? Performance is only an issue in a single release. Your solution is unsupportable over the lifetime of your application. Among other supportability problems, you're the only person I've ever heard of who has implemented something like this. Any new developers you bring in will be unfamiliar with such a unique implementation. Around here, many would decline to work for a company that used such an implementation. Please research .NET Remoting, or else learn how to implement Web Services using a thick wall between the client and server. This wall should only have small holes in it through which only XML may pass - not objects. SignatureJohn Saunders [MVP]
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.