Add Web Service advice

[Eric Guthmann]

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

[Douglas Adams]

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.

"Eric Guthmann" <Er**********@discussions.microsoft.com> wrote in message
news:eM**************@TK2MSFTNGP10.phx.gbl...

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

[Clemens Reijnen]

its better to use interfaces to construct webservices...

"Eric Guthmann" <Er**********@discussions.microsoft.com> wrote in message
news:eM**************@TK2MSFTNGP10.phx.gbl...

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

[Matt Dunn]

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/s...StrikesBackP6),
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/Resource.../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

[Eric Guthmann]

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

"Matt Dunn" <ma*********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

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/s...StrikesBackP6),
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/Resource.../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

[Eric Guthmann]

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

"Clemens Reijnen" <Cl************@hotmail.com> wrote in message
news:e$**************@TK2MSFTNGP12.phx.gbl...

its better to use interfaces to construct webservices...

"Eric Guthmann" <Er**********@discussions.microsoft.com> wrote in message
news:eM**************@TK2MSFTNGP10.phx.gbl...

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

[Matt Dunn]

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