Noel,

Here's the problem:

You are sending in obj, which is of different type than the proxy type:

wsEmp.GetData(obj)

It is expecting: EmployeeWebService.EmployeeObject -- this is a proxy type,
whereas your EmployeeObject is in a different namespace.

To remedy this, you need to manually change your proxy class, remove the
type EmployeeWebService.EmployeeObject from the class, and add a reference
to your Employee library in the proxy class (using Imports). This tricks the
compiler into thinking that you are using the proxy type, while it is
actually using your custom type.

Hope that helps.

Noel

Not a problem, but can't do it this evening, Man City vs Bolton and I've got
a date with the pub, I'll post some more detail tommorrow morning (GMT ).

Cheers

Glenn

Noel

The XML part or exposing the employee.dll functionality as a web service?

With regards to XML serialization

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/htm
l/xml01202003.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemxmlserialization.asp

If your using VS.NET you could use the rather good XML Designer to build
your schema definitions.

As for exposing functionality on the web for an existing DLL, a personal
preference is to create a thin web service wrapper type around the existing
class.  Any overloaded methods can be handled using the MessageName property
of the WebMethod attribute.

I've have to say that most of the work I've been doing with XML and web
services in general has been processing data in a single hit.  Dealing with
rich client applications may not lend itself to using a serialisation
mechanism.

Thinking about it a bit more, DataSets may be a better solution than having
to worry so much about the serialisation mechanism.  I've not personally
used them in web services having been told by a supposedly more learned
colleague not to, but it may be perfect for what you want to do.

I'd check out these articles before attempting to use DataSets with web
services

http://www.oreillynet.com/pub/wlg/2142

http://weblogs.asp.net/aaguiar/archive/2004/06/03/147208.aspx

Sorry if I've not been much help, I'm extremely hungover.

Glenn

Could you please throw some light on how the versioning needs to be done for
the proxy class?

One more question regarding the custom class:

I'm not sure what's the preferred/best method to retrieve the records from
the webservice. Which one is better when deciding to retrieve data from web
service?

1. Using Datasets (Multiple datatables can be returned. But could this make
the web service slower than when using custom objects)
2. Custom objects

BTW, when deciding to use custom objects. How should the records be stored
inside the object (I mean what's the industry standard or preferred method
of storing multiple records in a custom object?) Should a dataset/datatable
be used inside the custom object to store data or is there another better
method?

Another question/topic:

The architecture that I want to follow is GUI -> Web service -> Business
Objects -> database.

I would like the application to be highly scalable and load balanced.
Therefore I would like to scale it at the business objects level. If I have
multiple servers with the Business Objects installed/running. How could I
let the web service know

1. Which server to use (depending on load balancing.) BTW to load balance
should I incorporate any logic to the application/webservice?
2. How to supply/notify my web service at run-time the servers that have the
Business Objects running?

Thanks in advance for your valuable inputs.