Should a remote user interface be implemented using SOA?
We used to have desktop applications, but given the fact that accessing the server (physically or remotely) was not desirable for the client, we turned it into Windows services that would run (theoretically) 24/7.
We now need to provide a remote user interface for these services to keep the old functionality and the old interface.
For that, we have at least about developing a few SOA services using WCF. We will have one service for configuration, another for network information, statistics, etc., so the sum of all services will have the same functionality as the old interface, but split into different areas of functionality.
I don't have much experience in SOA, is this design correct? Is SOA suitable for a remote interface? Should there be only one service or should there be logical groups?
Note. We have several applications that access some of the information about a service, so we make these logical sections.
Edit: Is it worth implementing any protection over who can connect and what could be accessed early on? I kind of see this with a big YAGNI warning, but maybe I'm wrong.
I am interested in all the suggestions on how to implement remote UI, existing frameworks, best practices, advantages and disadvantages of using SOA, etc.
source to share
When you say "Remote interface" I think you really mean that you have some operations performed on a remote server but called remotely via an API.
Remote user interface would mean that the user interface is running on the service machine and users interact with the service through a projected user interface, for example. something like Terminal Services.
Exposing the work being done by a service in the SOA-api is probably the best way you want to take. Then you can implement the interface in Winforms, Silverlight, ASP.Net, or whatever in the future. SOA is so many things for a lot of people, but I like to think of it as a boundary point in a system where each side doesn't know the other side's implementation details.
The decision about the granularity of services is not always obvious, but if you try to think about the functionality you provide to the consumers of that service, not just the user interface application that you are currently implementing. These things are certainly not set in stone, and you can reorganize as things evolve. One application can consume multiple services, so this is not a problem.
Where I work, we first implement the functionality, then we take on security issues later. Of course, your security requirements will be specific, but you need to consider things like the sensitivity of the data being accessed or the functions the user can call through the service. if the service is used inside your network or is made public over the Internet, and the likely hood that users will try to maliciously attempt. for example, it is very unlikely that a business user will download a copy of Visual Studio and create their own WCF client to cause havoc, but anything is possible.
source to share
It looks like you're on the right track. Your problem is essentially the same problem as mine and I developed mine the same way as you described - a Windows service serving three WCF services (as of today) and an external application to be used by the user to interact with WCF locally, or remotely.
If the logical divisions you describe are truly independent of each other, then each one is its own WCF service module makes a lot of sense. However, if there is some overlap (for example, the configuration service needs to communicate with the network information service in some way), then I would overlay logical units at the WCF contract level, not necessarily as completely separate WCF modules. This will make it easier to work inside the Windows service.
If you don't have Juval Lowy's book, Programming WCF Services , I highly recommend that you get a copy. This is a great WCF reference. You can also visit his site, IDesign.net , for many freely available WCF code examples.
source to share
My opinion is for the user interface UI, SOAP based web service can be heavy and performance can become an issue as the load increases, instead custom REST service for frontend and SOAP based service for your business logic and orchestration to you provide a scalable application with good performance.
I think WCF supports both SOAP and REST services, REST services are lightweight and technology neutral as they are based on plain HTTP.
source to share