Web Service Concepts Confirmation?

[Keith Chadwick]

Morning folks (Dan),

Been doing a lot of reading on web services and will be going out to
purchase a book today specificaly on web services. Any recommendations on a
book?

Been reading a lot on creating a proxy of a web service which seems to me to
be nothing more than a pointer to the actual compiled web service dll?

Here is my scenario. I will have about 10 or 12 web services each providing
access to specific classes within my application, for example:

wsContacts
wsMail
wsCalendar
wsRegistrations

Each of these web services has there own unique name space, for example:

wsContacts namespace=http://www.evententerprise/schemas/2004/contacts
wsMail namespace=http://www.evententerprise/schemas/2005/mail

The primary consumer of my web services is the same web application that
contains the web services. For example my contacts interface uses dim
contact as new wsContacts. Obviously I do not need a proxy class in this
case, correct?

If I wish to expose these services to other applications do I need to do
anything special? Am I correct in my understanding that the consumer would
create a proxy reference to the service they need? But can not the consumer
simply create a http request to the service to get and submit the
information? Each of my web services supports HttpGet, HttpPost and
HttpSoap. Each service requires a login key they get from a base web
service I have created. Are there security concerns I need to look out for.

My consumers could and will be the following. Other web sites both server
and client side in any language and most likely some windows CE devices. Is
there anything I need to do in order to make my web services available to
these consumers?

My web services also make use of a common class within my web application
that manages login , session and querystring parameters along with
application state and some other issues. Am I going to run into problems
because my web services do not really stand alone because of this?

Cheers
Keith

 

[Dan Rogers]

Hi Kieth,

A proxy is not exactly a pointer to the original class. It is instead a
tool that runs in the client space and provides a local facade that appears
to have the same methods and types used by the actual service. The
difference is that this tool packages the requests you make to the service
into the SOAP request, transmits the call, and then waits for the results.

As a result, the behavior is optimized for chunky communications. In the
caller - which uses a proxy, you can create an instance of the proxy, but
this is not analogous to creating an instance of the service.

When you do a local reference, say from within your web service, such as
having one of your web methods directly call another local method, then
there is a shared instance of the service and a local method can access
private member variables that may be effected by the other method. When
you create an instance of the service class (it's just a class, after all)
from another applicaiton on the same machine, you do have the option of
using the local assembly directly and not use a proxy. The way you do this
is to add a reference to the assembly, and not add a web-reference to the
service. When you do this, the service class runs in the context of the
calling application, just like any other class.

If your web methods are primarily intended to be used by a single
application, I'd urge you to concider why you have chosen to expose your
methods as web services. Using the local class lets you get the local
behaviors just as you would with any other class, and you can even do
"extra stuff" like accessing public members and methods that aren't web
service exposed.

As for books, there are a number out there. My favorite - the one I have on
my shelf with dog-ears and all - is Scott Seely's book on writing web
services in Visual Basic. All of the concepts in the book translate to any
CLR language, so it's not just a VB book, it's a how to book for going from
the ground floor to advanced concepts.

I hope this helps

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

 

[Keith Chadwick]

Thanks Dan,

You strongly urge me not to expose my methods as web services but this is a
necessity of the application.

In the next phase, which is very soon, we will be creating windows ce
applications in tandom with bar code readers to send validation requests to
the web services. We will also be designing kiosk interfaces to integrate
make calls to the web services. We also have some requirements from
prospective clients to provide access to particular objects, actually just
about all of them, so that they can design there own sites around our data.
Basically we end up being a data store and that is about it.

Another reason was also came to me is the ability to seperate out interface
from logic on two or more seperate physical machines. So we have several
web sites running on different machines that make calls to a central web
server that hosts the web services. I would much rather spend more time
doing it right then having to rewrite code to meet specific circumstances as
they arise as you end up with a real rats nest.

For security all of our web services are returning xml data that does not
relate to any specific database key. They are all guids which we translate
back to the identies of the database within the users session xml before
doing the db call.

Nice thing is the timeframe to complete the application is up to me solely
and there is no real pressure so I would much rather do things right than
not. One of the reasons I set namespaces to a year was to allow for
versioning because no matter what things will change.

My thoughts are I am working on one single web service at the moment with
basic fetchItem, fetchlist, updateItem and deleteItem methods. I will spend
as much time on this single web service until I am satisfied it covers all
the bases. When that is complete the rest of the services are very similar
so will not take long.

I hate having to go back and rewrite code because you find a better way of
doing it so I am taking my time and doing it right the first time for once.
Best way to learn

Cheers
Keith

 

[Dan Rogers]

Hi Keith,

These reasons all make sense to me. It is this kind of thinking that is
required to determine what methods are exposed or not. Without an in-depth
understanding of your code, I have been trying to just frame the basics.

Some more things to look for in your design (these would need to be
changed) if you want this migration to work over web services:

1. The web service classes cannot expose fields or properties directly.
These will not make it to the proxy. Any requirement for data must be
fully encapsulated within the contracts as defined by the exposed method
signatures. In this way, the sum of the data types returned or sent to
your methods defines what a remote caller can expect to have access to.

2. The web service caller should not expect the proxy to behave like a
local instantiation of a class. That is, it isn't safe to assume that
because one does a "new" on the proxy, you have an instance of a class on
the server. The service only exposes methods.... that said, if you
absolutely need state, you can get it by enabling session management, but
this requires configuring the proxy to accept cookies, or other data
passing mechanisms that get around the fact that each instance of a method
call works with a new instance of the service class.

These things may be obvious, but if you are coming from an existing set of
objects and simply trying to convert them to web services, these are common
areas where such ports trip up.

If you are writing anew, then these are things to avoid, if you don't
already know them. I do like the added translation to GUID that you've
done - as long as this makes the key an immutable aspect that references
the same data over time. The added layer of indirection lets you do some
interesting things on the back-end, and since you've done this, I'm sure
you appreciate these already.

It sure looks like you're putting the right amount of time into thinking
this through. Good show

Dan
--------------------

 

[Keith Chadwick]

Thanks Dan,

My original web services that returned xml had the actuall db keys and that
frightened my a bit. I have a big sign in my office that says Security
Security Security! Hence going to guid.

As for session and state not to worried. I do a matched pairing of login
guid key with session key. So every request you must submit your login
guid. This is stored in your user account in the db with a expiration time.
If you make a request the system checks to see if you already have a
session, which is xml by the way , if you do compares the guid and the
timestamp of the guid. If you need a new one the database provides, if not
away you go. If you do not have a session then the guid is sent straight to
the db in order to create a session under the current request. This is all
automatically done by my director class. Had to do some fiddling for method
of http call, i.e. soap, post etc. Basically I make no assumptions about
the stateless world and trust no one.

As for exposed methods they are all very simple. You call the core web
service to login and get your key. Every call after that you have to submit
your key whether your doing a soap package, form post or simply http
request. I try to build everything in blocks and go easy on db througput
whenever I can. Use the middle tier for its intended purpose I allways say.
As an extra level of security the guids stored in the db are routinely
changed via a scheduled stored procedure to ensure that consumers don't
start hardcoded the calls.

Think I'm covering everything

Thanks for all the feeback. I get the impression I am on the right track
and that is a very good feeling to have!

Cheers
Keith

 

[Keith Chadwick]

As a side note. None of my web services will have properties only methods
and you allways provide your credentials to get in. The web service methods
provide interfaces into my actual classes. Each class represents an object
in xml from the database and requires credentials as well.

Right about the session though, would be nice to keep the server memory down
by not creating new session when necessary. This will also reduce db calls.
Will do some testing to see if new sessions are being created on XMLHTTP
calls and other methods via tracing the sql server. Memory may be cheap but
it still a resource one need not use frivolously.

Again, thanks for the feedback been great.

Cheers
Keith

 

[Dan Rogers]

Hi Keith,

Sounds like you're very happy with where you are at.

Glad to help

Dan
--------------------

From: "Keith Chadwick" <[email protected]>
References: <[email protected]>

<[email protected]>