Services and Interface

[Pranav]

Hi All,
Q - Does it make sense to use web service as a facade to my
Application Server for integration with outside world while retaining
an alternate route for the clients written by me?

Context - We have a solution comprising of
1. Backend Database
2. Application Server (AS) that talks to the DB and offers services to
the client
3. Clients talking to the AS. There can be different kinds of client
viz. a rich win32 power client installed in LAN, a web client written
using asp.net and finally external components written to integrate
with our system.

Our (win32/web)clients communicate with the AS using XML document,
however this is a native construct understood by the AS and the
client. The code in the AS decomposes the xml to data structures and
the Business objects work with this datastructure.
Now in order to provide integration point to outside world I was
thinking of writing a web service. In the web method I would take well
defined parameters and construct the same data structure and delegate
the call to the business objects in the AS.

I am not sure if this is the right approach as it means maintaining
two interfaces. However, the reason I am keen on keeping the xml
document route is the flexibility that I get. I know that the document
is coming from one of our clients so its going to be well formed, the
tags can be as terse as possible. I can make certain assumptions from
security/validation perspective. I can batch calls and have my AS
iterate over each operation and provide response. I would keep my web
methods simple/granular while the document route could be more complex
and chunky.

Would appreciate any thoughts for/against what I am doing.
Thanks for your patience.
Pranav

[Daniel Carbajal [MVP]]

Well, as I understand, your web service clients would be sending a different
data that your local clients...., I think the best way is to have only one
business facade to your service, this would be the interface to your local
clients, then your web service facade would be only one thin facade with no
code to your business facade, with the same interface, so all your clients
will be sending to you the same kind of information and you have to program
only one time.
Regards,
Daniel Carbajal
MVP
"Pranav" <pr*****@hotmail.com> wrote in message
news:e2**************************@posting.google.c om...

Hi All,
Q - Does it make sense to use web service as a facade to my
Application Server for integration with outside world while retaining
an alternate route for the clients written by me?

Context - We have a solution comprising of
1. Backend Database
2. Application Server (AS) that talks to the DB and offers services to
the client
3. Clients talking to the AS. There can be different kinds of client
viz. a rich win32 power client installed in LAN, a web client written
using asp.net and finally external components written to integrate
with our system.

Our (win32/web)clients communicate with the AS using XML document,
however this is a native construct understood by the AS and the
client. The code in the AS decomposes the xml to data structures and
the Business objects work with this datastructure.
Now in order to provide integration point to outside world I was
thinking of writing a web service. In the web method I would take well
defined parameters and construct the same data structure and delegate
the call to the business objects in the AS.

I am not sure if this is the right approach as it means maintaining
two interfaces. However, the reason I am keen on keeping the xml
document route is the flexibility that I get. I know that the document
is coming from one of our clients so its going to be well formed, the
tags can be as terse as possible. I can make certain assumptions from
security/validation perspective. I can batch calls and have my AS
iterate over each operation and provide response. I would keep my web
methods simple/granular while the document route could be more complex
and chunky.

Would appreciate any thoughts for/against what I am doing.
Thanks for your patience.
Pranav

[Matthieu Siggen]

Hello Pranav,

I'm not sure to have the right answer for you but I'm going to try to
give you a good answer.

When you speak about Service Oriented Architecture (even if it's not
the case here) you normally admit that the Service interface will be
separated from the Service implementation. In fact, one of the reasons
to do this separation is that it gives the possibility to call the
implementation with several different interfaces.

As in your example, you will have an "outside interface" and an
"inside interface". So you could have Web Services for the outside
interface. With all WS advantages and disadvantages. And .NET remoting
for example for your inside interface.

Some usefull information about the guidelines to build services are on
the following page :
http://msdn.microsoft.com/architecture/soa/default.aspx

And if you're searching a framework to do so, keep an eye on the
Enterprise Development Reference Architecture at :
http://www.gotdotnet.com/Workspaces/...5-576198df8058

My 2 cents,

Matthieu

[Pranav]

Thanks much for your inputs Daniel and Matthieu.
From what I understand so far its ok to have a thin web service facade
with no business code.
I had a related question wrt interfaces, If my method has to return a
non trivial data (say a tree), is it ok to return it as xml document.
What kind of support is present for defining complex data type that
has to be consumed by scripting language in a browser, the xml route
works easily but I was wondering if its the right way.

Thanks,
Pranav