Business logic- best approach ?

[Adrian Parker]

Currently we have a client server application that calls DLLs to perform business logic on the client, but we're in the process of
developing software to run on the web. At the moment, the web software does not need to call the same business logic, but in
future it will need to. I'm thinking that creating a webservice to hold the business logic to be called from the client/server
application and the website would be the best approach.. But not having written a webservice before, I don't know the limitations..
any comments ?

 

[Michael Giagnocavo [MVP]]

WebServices are ok for passing data around. The thing to realise is that
they are really just forwarding simple XML messages. No powerful magic is
going on. For instance, they have problems when it comes to exceptions.
They are also loosely bound (which can be nice or not). The main "problem"
is that they are an "open XML standard", which means no .NET-specific
enhancements. This can be nice for interop scenarios, but when you want to
take full advantage of .NET, the Web Service layer can break down some of
the nice things (for instance, it's impossible to have events or callbacks
with a web service).

I did a medium size (110,000 lines) site that had 18 "applications"
intercommunicating with each other via webservices. In some ways it was
nice, but I think .NET Remoting would have done a much better job (as far as
development goes), by giving us early-bound compile-time checking.

Depending on the app, performance can be an issue too (since binary TCP is
quite a bit faster than XML over HTTP).

If you design a nice business facade, and perhaps the auto-generated
webservice proxy to reconstruct the right exceptions, it could be a fairly
elegant architecture.

-mike
MVP

Currently we have a client server application that calls DLLs to perform

business logic on the client, but we're in the process of

developing software to run on the web. At the moment, the web software

does not need to call the same business logic, but in

future it will need to. I'm thinking that creating a webservice to hold

the business logic to be called from the client/server

application and the website would be the best approach.. But not having

written a webservice before, I don't know the limitations..

 

[Adrian Parker]

What we have now is 1200+ business rules written in a language we developed that gets translated to C and compiled into a DLL. The
DLL is then called directly from our client server application. Each rule is a linear process i.e. no need for events or
callbacks etc. all we need is to be able to access the db and return a result from the funciton to the caller whether it be a client
srever app or a web app.

When you say exception handling is a problem, do you mean that the apps just die when they happen ? We can ensure we add try-catch
blocks around anything that might have a problem.

-Adrian Parker

WebServices are ok for passing data around. The thing to realise is that
they are really just forwarding simple XML messages. No powerful magic is
going on. For instance, they have problems when it comes to exceptions.
They are also loosely bound (which can be nice or not). The main "problem"
is that they are an "open XML standard", which means no .NET-specific
enhancements. This can be nice for interop scenarios, but when you want to
take full advantage of .NET, the Web Service layer can break down some of
the nice things (for instance, it's impossible to have events or callbacks
with a web service).

I did a medium size (110,000 lines) site that had 18 "applications"
intercommunicating with each other via webservices. In some ways it was
nice, but I think .NET Remoting would have done a much better job (as far as
development goes), by giving us early-bound compile-time checking.

Depending on the app, performance can be an issue too (since binary TCP is
quite a bit faster than XML over HTTP).

If you design a nice business facade, and perhaps the auto-generated
webservice proxy to reconstruct the right exceptions, it could be a fairly
elegant architecture.

-mike
MVP

Currently we have a client server application that calls DLLs to perform

business logic on the client, but we're in the process of

developing software to run on the web. At the moment, the web software

does not need to call the same business logic, but in

future it will need to. I'm thinking that creating a webservice to hold

the business logic to be called from the client/server

application and the website would be the best approach.. But not having

written a webservice before, I don't know the limitations..

 

[Michael Giagnocavo [MVP]]

The actual Exception won't bubble up. So if your app throws a
CustomerNotFound exception, that won't get passed as an object over web
services.

If all you need is a simple result from a function, web services should work
fine. From the sound of it, you aren't using a lot of .NET specific
features anyways.

-mike
MVP

What we have now is 1200+ business rules written in a language we

developed that gets translated to C and compiled into a DLL. The

DLL is then called directly from our client server application. Each

rule is a linear process i.e. no need for events or

callbacks etc. all we need is to be able to access the db and return a

result from the funciton to the caller whether it be a client

srever app or a web app.

When you say exception handling is a problem, do you mean that the apps

just die when they happen ? We can ensure we add try-catch

blocks around anything that might have a problem.

-Adrian Parker