Hi!

I am new to web services. AFAIK, the advantages of using web services
are : interoperable, easy integration and reuse, text based protocols
and data formats - SOAP,WSDL,XML.

Also, I read this article:
http://www.theserverside.net/articles/showarticle.tss?id=Top5WSMistakes
I agree with everything this article says. Is there anyone (or anylink)
which proves otherwise? I have read quite a few times about using web
services as data access layer, but somehow I am not getting - why ?

If I have to design a web based application using ASP.NET, accessible
only in an intranet environment. Is it a good idea to use web services
as data access layer ? For example: for a customer data entry screen -
I'll have web services like : getCustomerbyIDWS(),
IsCustomerUniqueWS(), AddCustomerWS(), UpdateCustomerWS() etc. It just
sounds to me like an overhead to use web services.

Thanks in advance,
Best Regards,
Rashmi

[quoted text, click to view]

Hi Rashmi

You're on track :-)

but only, if your business workflows, do not need the CUD services.

Mostly, you actually want these services (methods) as part of your
service, but again, it depends solely on the needs of your business.

For the datalayer thingy one common way of doing it is this:

Request:
Client->UI logic->Service->DataLayer->Database

Response:
Database->DataLayer->Service->UI logic->Client

That way separation of concerns are enforced.
You could even split the UI logic in UI view logic and UI controller
logic for enforcing the MVC pattern style client.

The role of the datalayer is to provide *data* services to your
(web)services. So this layer concerns how to get the right data needed
(by using parameterized SQL, a stored procedure, read from a local file,
read from a cache, etc...).
Actually the (web)service doesn't care *how* the datalayer gets the
right data, it just uses them to pass on to client )or actually the UI
logic that resides on the client).
So you could say that:

- The UI logic is a service consumer of your (web)services, which acts
as service providers
- The (web)service is a service consumer of your data layer services,
which acts as serivce providers.

Just my thoughts. Does it make sense?

Regards

Hello Henrik!

Thankyou for replying.

I gather that - we need to emphasize on business functions and expose
them as Web services instead of creating CRUD web services methods.

Lets say, the current business needs for me requires any external
system (or 3rd party or any other organization) to just allow read
operations - no update,add or delete. In this case, I should be
exposing only the findCustomerByName, findCustomerById,
findCustomersWithinZipCode methods as Webservices. [The
add/delete/update opertions will not be exposed as Web Services
methods]

This is what I understand - that we should use WebServices carefully on
a case by case ("depends on..." factor) basis. Please let me know if I
am offtrack.

Thanks once again,
Regards,
Rashmi

Actually, the application which I'll probably be working on is an
intranet app (part of it internet accessible too).

For data entry a desktop app (Windows forms) - No external entities
allowed to access, only the windows domain users. [No web services
here]

A web based reporting system and a few interfaces to external systems
(accounting system) - [Web service methods for accounting system
interface - only Read operations].

Thanks a lot for your help.
Regards,
Rashmi

[quoted text, click to view]

Hi Rashmi

The first time I went down the WS way (or SOA way if you prefer) I
initially thought the same as you. Why bother using these services if
they're just CRUD methods to your database?

It is all about the term "service".

What is a service?
A service in my opinion is a component exposed via a well known
interface including well known method signatures, return types and
parameter types.

A client (form, web, other service) can interact with these services
(actually the methods exposed in the interface for each service)

Well, the trick is the *granularity* of the services (methods) a service
offers. Question is: "Which granularity will fit my clients?" And this
is almost always a "depends on...." answer.

I have found these "rules" often working surprisingly well in writing
service interfaces:

0) Think business
Think in terms of business needs. What is the business workflow. Give
that workflow a name, and you have a candidate for a interface method.

1) Will you need to have CRUD methods?
Mostly you do. Actually you often have createCustomer, disposeCustomer,
updateCustomer.
But what about read operations (the R in CRUD).
Mostly you'll have more readers (or finders). Example:
findCustomerByName, findCustomerById, findCustomersWithinZipCode.

2) Define the interface methods as precise as possible
The methods should be self-describing, including their parameters and
return types.

Hope to help.

Regards

Henrik
http://websolver.blogspot.com