Referencing Web-service (2005)

[Mantorok]

Hi all

I have a web-service that references another project (the component) that
actually carries out the work, the web-service is simply acting as the public
interface.

The web-service on occasion may return a class that is defined in the component
project.

When I reference the web-service from a new project will it pick up these
classes that are defined in the component project? Or will they be ignored
and I'll end up with a broken web-service.

The reason I'm asking is because Beta 2 failed to do this and I'm not sure
if the released version will work, and unfortunately I haven't got time to
check it.

HTMS
Any ideas?
Thanks

Kev

 

[Ray Booysen]

Hi all

I have a web-service that references another project (the component)
that actually carries out the work, the web-service is simply acting as
the public interface.

The web-service on occasion may return a class that is defined in the
component project.

When I reference the web-service from a new project will it pick up
these classes that are defined in the component project? Or will they be
ignored and I'll end up with a broken web-service.

The reason I'm asking is because Beta 2 failed to do this and I'm not
sure if the released version will work, and unfortunately I haven't got
time to check it.

HTMS
Any ideas?
Thanks

Kev

If your web service returns objects that are defined by the component
project, you'll need those classes defined in the project that is
calling the webservice. The project cannot figure out what is being
passed otherwise.

 

[Mantorok]

If your web service returns objects that are defined by the component
project, you'll need those classes defined in the project that is
calling the webservice. The project cannot figure out what is being
passed otherwise.

My work-around before was to create some classes in the web-service itself
and only pass them back to the caller, this seemed to work fine.

Maybe I shouldn't be passing back types that have been defined in the component
project - are there any general guidelines for this sort of scenario?

Thanks
Kev

 

[CMM]

If your web service returns objects that are defined by the component
I'm not sure if that's entirely true. If the class in question is a simple
structure of primitive types or arrays (sometimes called a "document"), any
client (.NET, Java, or otherwise) will recontruct the class without any
extra help (it's automatically defined in the WSDL).

However, if the class is "fat" and does work (sometimes called an "entity")
then you're right... and you'll need to put your entity class
implementations in a complimentary DLL that is installed on both the client
and server.

 

[Ray Booysen]

I'm not sure if that's entirely true. If the class in question is a simple
structure of primitive types or arrays (sometimes called a "document"), any
client (.NET, Java, or otherwise) will recontruct the class without any
extra help (it's automatically defined in the WSDL).

However, if the class is "fat" and does work (sometimes called an "entity")
then you're right... and you'll need to put your entity class
implementations in a complimentary DLL that is installed on both the client
and server.

You're right. My brain switched off for a while.

 

[CMM]

VS2005/.NET 2.0 does a really good job of serializing classes. A lot of the
types and collections (like the infinitely very useful List(of <T>)) and
even deeply nested classes are recognized by the serializer and turned into
XML primitives and arrays and defined in the WSDL. The client (.NET, Java,
or whatever) should have no trouble reconstructing these classes... they're
described quite well in the WSDL.

However, this is only practical for classes that contain only data (document
paradigm)... not for classes that contain built-in validation or otherwise
do "work" (entity paradigm).

 

[Mantorok]

VS2005/.NET 2.0 does a really good job of serializing classes. A lot

of the types and collections (like the infinitely very useful List(of
<T>)) and even deeply nested classes are recognized by the serializer
and turned into XML primitives and arrays and defined in the WSDL. The
client (.NET, Java, or whatever) should have no trouble reconstructing
these classes... they're described quite well in the WSDL.

However, this is only practical for classes that contain only data
(document paradigm)... not for classes that contain built-in
validation or otherwise do "work" (entity paradigm).

Thanks for that - I thought as much, I'll try and stick to the document paradigm
for returned types.

Kev

 

[Russell]

The web reference generates proxies that reflect public variables and
properties of the class the web method is declared as returning. Even
if you add the reference to the original class, what you'll get back
from the service is the proxy class. If you want to work with an
instance of the original class you'll need to construct one from the
proxy object that is returned.