468,110 Members | 1,524 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

Extending web service proxy classes

Hi all,
tough question. Apologies for the cross posting but it is an interesting
architectural problem and I think deserves a wide audience.

What is the best way to extend web service proxy classes so we can add
our own methods and properties?

We have an application that passes a deep hierarchical structure (four
nodes deep) between a webservice and a smart client.
We have built the web service using the Contract First Web Service Tool,
which essentially builds nice web service proxy classes from a WSDL and xml
schemas, nothing new here. This tool uses the xsd.exe generation tool + IDE
integration, rather nice.
On the client side of the application we need to do some complex / semi
real time processing on this hierarchy before sending it back.

We would like to extend the web service proxy classes without modifying
the generated class files directly as we know that these things tend to
change and code generation is a big help in this manner.

We need properties and methods to be added to the individual web service
proxy classes

Attempts
We have tried inheriting from the web service proxy class.
This didn't work so well for two reasons
a) we can't down cast from a super class into sub class. i.e can't
cast from a type Dog into type Dalmatian
b) we have a hierarchy of classes so even if we can get a successful
cast into a Dalmatian class if we have a collection of FriendsToSniff they
would need to be cast as well...

Another option is to recreate the whole hierarchy, this seems to be an
expensive option after all the xmldeserializer has just kinda done all this
creating.

Another other option is use some kind of helper class which we could use to
help with the processing, this would be possible but complicated and would
not support the addition of properties easily as new properties would need
to be implemented as hashtables inside the helper class or something like
that. Helper classes are good for processing but not properties and state.

So you code hounds and architectural sleuths what do you think??

Thanks in advance

Mark


Nov 23 '05 #1
1 2014
Hi Sarge,

Thanks for your posting. Regarding on this post , I've found your another
duplicated one in the
Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es

I've posted my response there. Welcome to continue followup and discuss in
that thread.

Thank you!

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
From: "Sarge" <en*******@newsgroups.nospam>
Subject: Extending web service proxy classes
Date: Tue, 1 Nov 2005 09:33:01 +1300
Lines: 53
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Message-ID: <uN**************@tk2msftngp13.phx.gbl>
Newsgroups:
microsoft.public.dotnet.framework.aspnet.webservic es,microsoft.public.dotnet
..framework.webservices,microsoft.public.webservic es
NNTP-Posting-Host: 222-153-144-207.jetstream.xtra.co.nz 222.153.144.207
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msft ngp13.phx.gbl
microsoft.public.dotnet.framework.webservices:8417
microsoft.public.webservices:1236
microsoft.public.dotnet.framework.aspnet.webservic es:8210
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Hi all,
tough question. Apologies for the cross posting but it is an
interesting
architectural problem and I think deserves a wide audience.

What is the best way to extend web service proxy classes so we can add
our own methods and properties?

We have an application that passes a deep hierarchical structure (four
nodes deep) between a webservice and a smart client.
We have built the web service using the Contract First Web Service
Tool,
which essentially builds nice web service proxy classes from a WSDL and xml
schemas, nothing new here. This tool uses the xsd.exe generation tool + IDE
integration, rather nice.
On the client side of the application we need to do some complex / semi
real time processing on this hierarchy before sending it back.

We would like to extend the web service proxy classes without modifying
the generated class files directly as we know that these things tend to
change and code generation is a big help in this manner.

We need properties and methods to be added to the individual web
service
proxy classes

Attempts
We have tried inheriting from the web service proxy class.
This didn't work so well for two reasons
a) we can't down cast from a super class into sub class. i.e can't
cast from a type Dog into type Dalmatian
b) we have a hierarchy of classes so even if we can get a
successful
cast into a Dalmatian class if we have a collection of FriendsToSniff they
would need to be cast as well...

Another option is to recreate the whole hierarchy, this seems to be an
expensive option after all the xmldeserializer has just kinda done all this
creating.

Another other option is use some kind of helper class which we could use to
help with the processing, this would be possible but complicated and would
not support the addition of properties easily as new properties would need
to be implemented as hashtables inside the helper class or something like
that. Helper classes are good for processing but not properties and state.

So you code hounds and architectural sleuths what do you think??

Thanks in advance

Mark



Nov 23 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Marty McDonald | last post: by
reply views Thread by John O'Neill | last post: by
7 posts views Thread by Lumina | last post: by
15 posts views Thread by Joseph Geretz | last post: by
1 post views Thread by =?Utf-8?B?UnVp?= | last post: by
1 post views Thread by Solo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.