Web Services and Application Architecture

[Robert Strickland]

We are developing a several web applications that use 'services' that
perform key business functions for our applications. These same 'services'
are avaible to paying clients through web services. To summarize, we have
clients that use our web applications (they need UI) and we have clients
that just need the 'services' where they integrate our 'services' with their
applications through the web services. We have a single server that houses
both types of applications (we have failover). My question involves the web
applications and the 'sevices'. Should we use the web services from the web
applications or call the implementation components directly from the web
applications through their interfaces? My concern is performance for the web
applications and the fact the web services reside on the same physical
machine. It is argued on my team that calling the 'services' through the web
service allows for better stability and performance. I am not so sure.
Building a SOAP request and response along with the
serialization/deserialization would generate a large amount of overhead and
cause scalabiltiy issues during peak demand (which we will get). We are
document centric (not RPC) and deal with Xml streams, schemas, etc.

If possble, could someone direct me to some general guidelines or sites that
cover this topic. I have gone through Microsoft's Best Practices and
Patterns but nothing surfaced.

Thanks

[Keenan Newton]

IMHO, insuring that you have logical seperation of tiers is the most
critical thing, whether you immediatley physicall seperate is not as
critical. You said that today this is on one server, then in my mind I
would just use the interfaces, however as time goes on and more
processing is needed it maybe necessary to scale out. This can be done
with Application Center, but if you keep your UI/Service layer,
business layer, and data access layer on the same physical machine
scalaibity will be hindered slightly. Performance of your application
is another critical piece, how important is it? Could you have a web
service farm, and a Web Application farm talking to a central data
access server via remoting, web services? I really think there is no
correct answer to this. You have to feel the bottle necks of your
application as it grows. Are they network bottle necks, processor
bottle necks, etc.. based on that you can then decide which logical
tiers should be seperated into different physical tiers. The best part
is every person you ask may give you a different answer on how to
architect this application. There is not a perfect formula. So to end
this I would say start of simple, and try togkeep thjings simple, make
sure your tiers are logically broken out, and you can refactor your
application as necessary.