|
|
You're in the
dotnet web services
group:Custom Serializable Objects
dotnet web services:
behave like DataSets when using WebServices? What I'm looking for is some way to force the WSDL generated code to create a reference to my custom object's namespace instead of creating it's own copy of the object in it's own WS namespace. Either that, or some easy way to move all of the properties from the Custom Serializable Object into the WSDL generated object via a clone operation or something of this nature, that executes fast. The idea is to have a common assembly with all the custom objects in it which can be used on both the client and WS sides, since from an architectural standpoint the UI should be separated from the Business Logic and separated from the Data Access. Any ideas?
I'm looking for a WebService solution. We have looked into Remoting but it
won't meet the long term needs and goals. Not to mension the fact the WCF is aimed in the Webservice direction. The functionality in question is being used across a WAN with all probability of opening it up to 3rd party vendors to access also. The objects that I am passing are XML Serializable but they can handle/contain complex structures (i.e nesting and collection type structures of other XML Serializable objects). The whole idea behind WS is to serialize data and pass it across the wire to be deserialized on the other end. My question is pertaining to the fact that when I create my custom XML Serializable object to either pass into a WS as a Param or return from a WS, the WSDL generated code create's it own version of the object instead of using the schema that I have specified. Say I have created a custom object "Acme.BizObjects.Contract oContract". When I call the WS, I want to be able to make the call "oWS.AddContract(oContract)" instead of making the call "oWS.AddContract(oWSContract)" where oWSContract is of type Acme.BizObjects.WS.Contract created by WSDL. When you pass a DataSet back and forth the WSDL doesn't create an WS.DataSet object, it uses the actual DataSet defined in the System.Data namespace. [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:uodkiTRzGHA.3424@TK2MSFTNGP03.phx.gbl... > "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message > news:eVtGkcFzGHA.1256@TK2MSFTNGP02.phx.gbl... >> Has anyone come up with a slick way to make Custom Serializable Objects >> to behave like DataSets when using WebServices? What I'm looking for is >> some way to force the WSDL generated code to create a reference to my >> custom object's namespace instead of creating it's own copy of the object >> in it's own WS namespace. Either that, or some easy way to move all of >> the properties from the Custom Serializable Object into the WSDL >> generated object via a clone operation or something of this nature, that >> executes fast. The idea is to have a common assembly with all the custom >> objects in it which can be used on both the client and WS sides, since >> from an architectural standpoint the UI should be separated from the >> Business Logic and separated from the Data Access. Any ideas? > > Your client and server are both .NET, and you _want_ to share types > between them, right? Is there a reason you haven't considered using .NET > Remoting? It's really quite simple to get started with it. > > John > > P.S. Web Services is all about XML; it's not about objects. There will be > valid Web Service messages which cannot be deserialized into objects in > some given programming language, and objects which cannot be trivially > serialized into XML. There's an "impedance mismatch" there. If you want > the impedance to match, use Remoting. > >
[quoted text, click to view]
"Techno_Dex" <nospamchurst@osi-corp.com> wrote in message news:eVtGkcFzGHA.1256@TK2MSFTNGP02.phx.gbl... > Has anyone come up with a slick way to make Custom Serializable Objects to > behave like DataSets when using WebServices? What I'm looking for is some > way to force the WSDL generated code to create a reference to my custom > object's namespace instead of creating it's own copy of the object in it's > own WS namespace. Either that, or some easy way to move all of the > properties from the Custom Serializable Object into the WSDL generated > object via a clone operation or something of this nature, that executes > fast. The idea is to have a common assembly with all the custom objects > in it which can be used on both the client and WS sides, since from an > architectural standpoint the UI should be separated from the Business > Logic and separated from the Data Access. Any ideas? Your client and server are both .NET, and you _want_ to share types between them, right? Is there a reason you haven't considered using .NET Remoting? It's really quite simple to get started with it. John P.S. Web Services is all about XML; it's not about objects. There will be valid Web Service messages which cannot be deserialized into objects in some given programming language, and objects which cannot be trivially serialized into XML. There's an "impedance mismatch" there. If you want the impedance to match, use Remoting.
I think you are taking my comments too literally. The idea behind creating
my own custom objects which are for all intensive purposes an Interface which adheres to a particular XML schema (xsd) is completely independent of the underlying framework. As long as the object that the user sends in to the WS matches up to the XML schema called Contract, it doesn't matter if they use Java, perl, etc... It's all about the XML structure of the object. As for creating the WSDL file by hand, that is just crazy talk, esp with the IDE so happy to auto generate and overwrite any custom code you have written every time you go to build in the IDE. There has got to be a way for WSDL to automatically create the same custom object for the simple fact that they do for DataSets. As for the remoting, I know what remoting is capable of I've already written multiple pieces of code in remoting. Remoting is not part of the scope of this project, it's Webservices just like in the name of the newsgroup. [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:%230zEoZTzGHA.3656@TK2MSFTNGP04.phx.gbl... > (Comments inline) > > "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message > news:%23HL5nxRzGHA.3424@TK2MSFTNGP03.phx.gbl... >> I'm looking for a WebService solution. We have looked into Remoting but >> it won't meet the long term needs and goals. Not to mension the fact the >> WCF is aimed in the Webservice direction. The functionality in question >> is being used across a WAN with all probability of opening it up to 3rd >> party vendors to access also. > > Will these 3rd party vendors all be using .NET? > >> The objects that I am passing are XML Serializable but they can >> handle/contain complex structures (i.e nesting and collection type >> structures of other XML Serializable objects). The whole idea behind WS >> is to serialize data and pass it across the wire to be deserialized on >> the other end. > > I strongly disagree with that statement. Web Services is about > communicating over the Internet using XML, in order to abstract away the > particulars of the type and object systems of any particular platform. The > idea is that it should be possible for your client to be written in C#, or > Perl, or something not yet invented. > > You seem to want to use web services, but to tie it to the .NET platform. > Oh, and BTW, have you considered the versioning issues if you're going to > share the same assemblies between your clients and server? > >> My question is pertaining to the fact that when I create my custom XML >> Serializable object to either pass into a WS as a Param or return from a >> WS, the WSDL generated code create's it own version of the object instead >> of using the schema that I have specified. Say I have created a custom >> object "Acme.BizObjects.Contract oContract". When I call the WS, I want >> to be able to make the call "oWS.AddContract(oContract)" instead of >> making the call "oWS.AddContract(oWSContract)" where oWSContract is of >> type Acme.BizObjects.WS.Contract created by WSDL. > > > See, that's where you're mistaken about this. Acme.BizObjects.Contract is > a type that you've created. You want .NET to look at your WSDL (which I > hope you created by hand, and didn't rely on .NET to create), and to > produce the same exact type. That's not going to happen, except by luck. > If you want to use the same type, you need to be using Remoting. > > Even there, the suggestion is to use interfaces to define the contract > between the client and server, and to expose the interface to your > customers, and not the type implementing the interface. This is > effectively what you're doing with Web Services, though the WSDL is then > the contract. > > .NET Remoting works well for using an interface as the contract. And, I've > probably already mentioned to you that .NET Remoting can use SOAP over > HTTP. > > John > >
(Comments inline)
[quoted text, click to view] "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message news:%23HL5nxRzGHA.3424@TK2MSFTNGP03.phx.gbl... > I'm looking for a WebService solution. We have looked into Remoting but > it won't meet the long term needs and goals. Not to mension the fact the > WCF is aimed in the Webservice direction. The functionality in question > is being used across a WAN with all probability of opening it up to 3rd > party vendors to access also. Will these 3rd party vendors all be using .NET? [quoted text, click to view] > The objects that I am passing are XML Serializable but they can > handle/contain complex structures (i.e nesting and collection type > structures of other XML Serializable objects). The whole idea behind WS > is to serialize data and pass it across the wire to be deserialized on the > other end. I strongly disagree with that statement. Web Services is about communicating over the Internet using XML, in order to abstract away the particulars of the type and object systems of any particular platform. The idea is that it should be possible for your client to be written in C#, or Perl, or something not yet invented. You seem to want to use web services, but to tie it to the .NET platform. Oh, and BTW, have you considered the versioning issues if you're going to share the same assemblies between your clients and server? [quoted text, click to view] > My question is pertaining to the fact that when I create my custom XML > Serializable object to either pass into a WS as a Param or return from a > WS, the WSDL generated code create's it own version of the object instead > of using the schema that I have specified. Say I have created a custom > object "Acme.BizObjects.Contract oContract". When I call the WS, I want > to be able to make the call "oWS.AddContract(oContract)" instead of making > the call "oWS.AddContract(oWSContract)" where oWSContract is of type > Acme.BizObjects.WS.Contract created by WSDL. See, that's where you're mistaken about this. Acme.BizObjects.Contract is a type that you've created. You want .NET to look at your WSDL (which I hope you created by hand, and didn't rely on .NET to create), and to produce the same exact type. That's not going to happen, except by luck. If you want to use the same type, you need to be using Remoting. Even there, the suggestion is to use interfaces to define the contract between the client and server, and to expose the interface to your customers, and not the type implementing the interface. This is effectively what you're doing with Web Services, though the WSDL is then the contract. ..NET Remoting works well for using an interface as the contract. And, I've probably already mentioned to you that .NET Remoting can use SOAP over HTTP. John
[quoted text, click to view]
"Techno_Dex" <nospamchurst@osi-corp.com> wrote in message news:eZM0ilTzGHA.1288@TK2MSFTNGP03.phx.gbl... >I think you are taking my comments too literally. The idea behind creating >my own custom objects which are for all intensive purposes an Interface >which adheres to a particular XML schema (xsd) is completely independent of >the underlying framework. As long as the object that the user sends in to >the WS matches up to the XML schema called Contract, it doesn't matter if >they use Java, perl, etc... It's all about the XML structure of the object. Then, I'm confused about why you're interested in duplicating what .NET does with DataSet objects. What do you expect Perl to do with a DataSet? That's what you should expect _any_ client to do with the DataSet, including .NET clients. [quoted text, click to view] > As for creating the WSDL file by hand, that is just crazy talk, esp with > the IDE so happy to auto generate and overwrite any custom code you have > written every time you go to build in the IDE. It's not crazy talk, it's the way I just wrote the web service I'm working on. No overwriting of code, or any other such nonsense. Inherit from the classes generated by WSDL.EXE, don't modify them. It allows you to be in control of the WSDL. John
When creating a reference to a WS in a project, the reference is created,
the *.disco, *.wsdl and Reference.map/Reference.cs class is created. In the Reference.cs class, the a DataSet is passed into a WebMethod, a System.Data.DataSet reference is added to this class as it is a known predefined type and has an xsd of it's structure. If I have a custom object call Contract that is passed into a WebMethod, I want the IDE when creating the References.cs class to recognize this structure by the XSD defined in the custom object Contract and create the reference of that type in the class instead of creating a brand new class in the References.cs class and giving it a brand new namespace. The reason I want this functionality is because in the BussinessLayer behind the ClientUI, I want to be able to reference this common Contracts object/structure in order to create an instance of the object using the info from the ClientUI layer, then pass this object to the ClientDataAccess Layer which can then pass the info along to the Webservice. The BusinessLayer should not be required to know what format the ClientDataAccessLayer is using to communicate with WebService because that defeats the purpose of separating out the layers. And currently there doesn't appear to be a good way to translate the Common.Contracts object to the WS.Contracts object in the ClientDataAccessLayer, except to transform it by hand. In the case of a DataSet, the dataset can be passed directly from the BussinessLayer to the ClientDataAccessLayer to the WebService without any transformation. This is what I am looking for. [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:eTmfCjVzGHA.3512@TK2MSFTNGP04.phx.gbl... > "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message > news:eZM0ilTzGHA.1288@TK2MSFTNGP03.phx.gbl... >>I think you are taking my comments too literally. The idea behind >>creating my own custom objects which are for all intensive purposes an >>Interface which adheres to a particular XML schema (xsd) is completely >>independent of the underlying framework. As long as the object that the >>user sends in to the WS matches up to the XML schema called Contract, it >>doesn't matter if they use Java, perl, etc... It's all about the XML >>structure of the object. > > Then, I'm confused about why you're interested in duplicating what .NET > does with DataSet objects. What do you expect Perl to do with a DataSet? > That's what you should expect _any_ client to do with the DataSet, > including .NET clients. > >> As for creating the WSDL file by hand, that is just crazy talk, esp with >> the IDE so happy to auto generate and overwrite any custom code you have >> written every time you go to build in the IDE. > > It's not crazy talk, it's the way I just wrote the web service I'm working > on. No overwriting of code, or any other such nonsense. Inherit from the > classes generated by WSDL.EXE, don't modify them. It allows you to be in > control of the WSDL. > > John > > > >
I'm also dealing with this issue, as I'm being forced to consume web services
to interface with a Locally available Database, because of corporate IT policy (Inadequate understanding of what Web Services are about, imho) I would much rather, (in my solution space) be dealing with a .Net remoting server, using a shared assembly containing well-defined data transfer types. However, things being as they are, I am creating my own business classes on the client side of the web service, but instead of coding them as wrappers or adaptors, around the web service proxy generated types, I have coded them as stand alone types with constructors that take the web service generated types as constrctor input parameters. It bothers me though, to have to be creating an entire business type structure downstream of the web service - The issues of using a web service (instead of remoting) are causing me to have build an entire layer of code on the client (perhaps in each client that consumes the web service) - that in a remoting solution would only need to be created once, in the business layer, upstream of the remoting interface. -- Charles Bretana Jr. Arete Industries Inc. [quoted text, click to view] "John Saunders" wrote:
> "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message > news:eZM0ilTzGHA.1288@TK2MSFTNGP03.phx.gbl... > >I think you are taking my comments too literally. The idea behind creating > >my own custom objects which are for all intensive purposes an Interface > >which adheres to a particular XML schema (xsd) is completely independent of > >the underlying framework. As long as the object that the user sends in to > >the WS matches up to the XML schema called Contract, it doesn't matter if > >they use Java, perl, etc... It's all about the XML structure of the object. > > Then, I'm confused about why you're interested in duplicating what .NET does > with DataSet objects. What do you expect Perl to do with a DataSet? That's > what you should expect _any_ client to do with the DataSet, including .NET > clients. > > > As for creating the WSDL file by hand, that is just crazy talk, esp with > > the IDE so happy to auto generate and overwrite any custom code you have > > written every time you go to build in the IDE. > > It's not crazy talk, it's the way I just wrote the web service I'm working > on. No overwriting of code, or any other such nonsense. Inherit from the > classes generated by WSDL.EXE, don't modify them. It allows you to be in > control of the WSDL. > > John > > > >
[quoted text, click to view]
"CBretana" <cbretana@areteIndNOSPAM.com> wrote in message news:3ACE0913-EA53-4743-A1AD-9E6EB50B567E@microsoft.com... > I'm also dealing with this issue, as I'm being forced to consume web > services > to interface with a Locally available Database, because of corporate IT > policy (Inadequate understanding of what Web Services are about, imho) > > I would much rather, (in my solution space) be dealing with a .Net > remoting > server, using a shared assembly containing well-defined data transfer > types. > > However, things being as they are, I am creating my own business classes > on > the client side of the web service, but instead of coding them as wrappers > or > adaptors, around the web service proxy generated types, I have coded them > as > stand alone types with constructors that take the web service generated > types > as constrctor input parameters. > > It bothers me though, to have to be creating an entire business type > structure downstream of the web service - The issues of using a web > service > (instead of remoting) are causing me to have build an entire layer of code > on > the client (perhaps in each client that consumes the web service) - that > in > a remoting solution would only need to be created once, in the business > layer, upstream of the remoting interface. Thank you for an excellent description of why certain members of upper management should keep their noses out of implementation decisions. John
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |