Questions about Web Service applications (Architecture)

[Toble Rone]

Some tome ago, me and my team could carry out our first real distributed
project. It's a GIS application using a Remoting Host (currently a Windows
Service), with TCP formatter over HTTPS. There is a bunch of classes
published in that way, actually exposing methods from an ORM layer. The
client app (a Winform/C# app) is used by almost 100 users over the internet
(our customers), and the performance is great.

Now. I'm actually engaged in a quite big new project. The architecture is
quite simple now, with planned client apps (Winforms too) used inside a big
corporate LAN, with external access also, with ASP.NET "extranet" websites.

The point here is that in this new scenario we will have a lot of external
communication with other clients, interfaces with government financial
systems, and so on. and the "Service Oriented" idea came in. I have a lot of
technical knowledge about web service and SOA (mainly from reading not from
real experience). but I have some doubts about WHERE and WHEN to really
apply web services.

I'll probably have real "services" in this scenario (with all the know
tenets, isolation, explicit boundaries, etc). No problem with that.

The problem is with normal behaviors of a distributed application. Imagine a
complex Winform client app with a lot of CRUD operations on business
entities. there will be (logically) some BLL functionality to do that crud
operations. I.E. the normal form to update or insert new customers or
products in the system.

But, in a "correct architectural point of view", if I decide to implement
web services (to interface with other systems and services), I really need
to expose ALL those BLL functionalities with web services?, or its nice to
mix the technologies? (may be using COM+, Remoting, etc).

In real world scenarios using web services. they do ALL with web services?,
or just the points when interoperability between other systems are needed?.

Every answer here will be really appreciated.
Tnx in advance.

Jack.

 

[Henrik Gøttig]

Hi Toble

Well, in my opinion, you hit the head on the nail, right there... plonk!

I have done "Service oriented" systems like you for the commercial
market on several projects, both in the J2EE and .NET camp.
My opnion is:
Look at your WS layer as a way of "interoperablizing" your business
processes. Just another way to get to your business processes. Same way
you can expose the same or other business processes for more appropriate
protocols like remoting, custom TCP/IP channel, whatever. The business
process remains the same, but how the data gets transported to it differs.

So, you can build your system without the need for webservices at all,
but still construct it to be "service oriented". Have POCOs, COM+
objects, whatever to define the business processes and implement what
those does. Expose all (or some of it) to "the world" via Webservices.
That way any exposed interface (being Webservices, remoting) acts just
as a transport layer.

To your last question regarding all or some business processes as web
services, I would say: Implement as appropriate. If it is more suitable
for the client to use a custom TCP/IP based "protocol" use that, if it
is suitable to use Webservices, do that. As long as you isolate your
business processes from the actual transport, you can mix it in any way
you want.

That being said. The last project I worked on used Webservices as main
process entry point for clients, and Biztalk for integrating
(serverside) with other "services" due to it's outstanding schema
mapping functinality.

Is it clear what the point is... or id I misunderstand your question
totally.

Regards

Henrik