webservice to expose existing app functionality

[Davey]

hi all,
I have a c# socket server application (console application) that is
responsible for maintaining an array of objects. The server does lots
of things but alot of it relates to the array of objects.
I want to add functionality to the server app by exposing some of the
methods as webservices. The webservices would allow other apps to get
info on the list etc..
The problem is that I am using visual studio, and I cant seem to
create a webservice without creating a new webservice project within
my solution.
But if I create a new webservice project, how can I access the array
managed by the main app???


i..e
+ Solution
| __ + ConsoleApplication (Main app)
MyArrayList managing state
Other functions
|
|__+ Webservice Project
AddToMyArrayList()
RetrieveMyArrayList()

is this kind of set up possible?
Thanks
dave

 

[Mujtaba Syed]

Davey:

If you insist on using VS.NET then you will have to move your array list
stuff into a separate library project. Then your console application as well
as your web service can reference and use your array list library.

If the usage of VS.NET is not required, you could make your solution
directory a vroot in IIS and write your web services as .ASMX (and
..ASMX.[CS|VB]) files without creating an ASP.NET Web service project.

I hope this helps,
Mujtaba.

 

[Dan Rogers]

Hi David,

I see some issues you're going to have to face.

First off, if you want to use ASP.net hosted under IIS as a way to expose
and manage your web services, then you need to create a web service project
to manage that interface. You could create an empty project if you like
as well, and then manually do all of the things that the web service
project wizard does for you (e.g. set up a vroot, set the application
settings, link the project to the vroot for deployment testing purpose,
etc).

The next problem you face is making the service running under a headless
IIS setting find your console application. As a rule, a console
applicaiton makes a poor multi-user server because the console application
typically requires that a user be logged in, have a winsession, and be able
to interact with the desktop. Crossing that secure user boundary between
the IIS sand-box (a good thing) and your application server will require
that you engineer some sort of communication layer so that your web service
code can access the instance of the data you are interested in.

Something to consider is creating a windows service project, and hosting
your data structure there (again headless). You would still need to make
your data management applicaiton have a communication layer so that you can
control/interact with the service from your new console application. The
benefit is that once you refactor your app in this way, you will have the
protocol you need to expose query/etc from your web service.

Think of the web service itself as a separate hosted appliction responsible
for dispatching requests to your data service.

Alternatly, you could write a web server/method dispatcher/security/soap
layer into your own application, but this is likely the harder path.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------