467,879 Members | 1,236 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,879 developers. It's quick & easy.

Custom Serializable Objects

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?
Aug 30 '06 #1
  • viewed: 1567
Share:
8 Replies
"Techno_Dex" <no**********@osi-corp.comwrote in message
news:eV**************@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.
Aug 31 '06 #2
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.
"John Saunders" <john.saunders at trizetto.comwrote in message
news:uo**************@TK2MSFTNGP03.phx.gbl...
"Techno_Dex" <no**********@osi-corp.comwrote in message
news:eV**************@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.


Aug 31 '06 #3
(Comments inline)

"Techno_Dex" <no**********@osi-corp.comwrote in message
news:%2****************@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
Aug 31 '06 #4
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.

"John Saunders" <john.saunders at trizetto.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
(Comments inline)

"Techno_Dex" <no**********@osi-corp.comwrote in message
news:%2****************@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


Aug 31 '06 #5
"Techno_Dex" <no**********@osi-corp.comwrote in message
news:eZ**************@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


Aug 31 '06 #6
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.

"John Saunders" <john.saunders at trizetto.comwrote in message
news:eT**************@TK2MSFTNGP04.phx.gbl...
"Techno_Dex" <no**********@osi-corp.comwrote in message
news:eZ**************@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


Sep 1 '06 #7
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.
"John Saunders" wrote:
"Techno_Dex" <no**********@osi-corp.comwrote in message
news:eZ**************@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


Sep 15 '06 #8
"CBretana" <cb******@areteIndNOSPAM.comwrote in message
news:3A**********************************@microsof t.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
Sep 16 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Thomas D. | last post: by
7 posts views Thread by Ken Allen | last post: by
1 post views Thread by leodippolito | last post: by
8 posts views Thread by a | last post: by
reply views Thread by a | last post: by
11 posts views Thread by =?Utf-8?B?bWljaGFlbCBzb3JlbnM=?= | last post: by
reply views Thread by MrMoon | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.