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