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
Toble Rone wrote:
> 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.
>
>
|
Similar Threads
