Should remote UI be implemented using SOA?

Question

Previously we had desktop applications but given the fact that accessing the server (either physically or remotely) was undesirable for the client we turned them into windows services that will run in a (theoretically) 24/7.

Now we need to provide a remote user interface to that services in order to keep the old functionality and the old interface.

For that we've though about developing several SOA services using WCF. We'll have one service for configuration, another one for, for example, network information, statistics and so on, so that the sum of all services provide the same functionality as the old interface, but separated into different areas of functionality.

I don't have much experience in SOA so, is this design correct? Is SOA appropiate for remote UI? Should there be only one service or there should be logical groups?

Note: We have several applications that access some part of the information on the service, that's why we make this logical divisions.

Edit: Is it worth it to implement any security over who can connect and to what may have access early on? I kind of see it with a big YAGNI warning, but maybe I'm wrong.

I'm interested in all kind of suggestions about how to implement the remote UI, existing frameworks, best approaches, advantages and drawbacks of using SOA, etc

Answer 1

It sounds like you're on the right track. Your problem is essentially the same problem I have, and I've designed mine in much the same way as you described - Windows service hosting three WCF services (to date) and a front-end application for the user to use for interacting with the WCF services locally or remotely.

If the logical divisions that you describe are truly independent of one another, then having each one of them be its own WCF service module makes a lot of sense. However, if there is some overlap (for example, the configuration service needs to interact with the network information service in some way), then I would impose the logical divisions at the WCF contract level, not necessarily as completely separate WCF modules. It'll make things a little easier to deal with inside the Windows service.

If you do not have Juval Lowy's book, Programming WCF Services, I would highly encourage you to get a copy. It is THE great WCF reference book. You can also visit his site, IDesign.net, for a lot of freely available WCF code examples.

Answer 2

When you say "Remote UI" I think you actually mean that you have some operations that are executed on a remote server, but are invoked remotely through an API.

A remote UI would imply that the userinterface is running on the service machine, and users were interacting with the service through a projected UI, e.g. something like Terminal services.

Exposing the work the service does in an SOA api is probably the best path you want to take. You can then implement a UI in Winforms, Silverlight, ASP.Net or anything else in the future. SOA is so many things to so many people, but I like to just think about it as boundary point in the system where each party has no knowledge of the implementation details of the other side.

Deciding the granularity of the services is not always obvious, but if you try to think about the functionality you are providing to consumers of the service, and not only the UI application you are tasked with implementing at the present moment. These things are of course not set in stone, and you can refactor as things progress. A single application can consume multiple services, so there are no issues in that respect.

At the place I work, we usually implement the functionality first, then take the security questions later. Your security requirements will of course be specific, but you need to take into account things like the sensitivity of the data being accessed, or the functions that a user can invoke through the service. if the service is used internally on your network or made public over the internet, and the likely hood that users will attempt to act maliciously. for example its highly unlikely that a business user will download a copy of Visual studio and create their own WCF client in order to cause havoc, but anything is possible.

Answer 3

My opinion is for front end User interface, SOAP based web service may be heavy and performance may become a concern when load increases, instead user REST based service for front end and SOAP based service for you business logic and orchestration so that you achieve highly scalable application with good performance.

I think WCF supports both SOAP and REST services, REST Services are light and technology neutral as they are based on plain HTTP.