I am in the process of working with two applications that provide overlapping functionality. I have been charged with pulling as much common logic from the applications out and creating a common platform so that both can leverage these common components and share the business logic they contain. In addition, there may be cases where other products will be able to benefit from these components as well. As a result, I am looking at a service-oriented design for these components - i.e. Software as a Service. Oh, it would also be nice to support third-party integration, which SaaS gives us.
The model I am considering is to create a set of distinct services that can be added or removed from a product. Each of these will be a "project" of its own so that they are completely modular. In several cases, there will be UI utilities developed for the service that provide the same access to the service behavior. A good example is a unified security service that provides user management features for a consuming application. This will allow multiple applications installed on the client's system to share security settings and information. We will have a small client application that allows users to perform tasks such as adding or modifying users, etc.
I have researched a number of different approaches looking at various design patterns and some real-world applications such as MS-Project and CRM to see how their architecture is implemented. My initial thought is to create the services as WCF and/or Web services that are consumed by the applications. Any utility application would also communicate through the service interface. However, I have two questions/issues that are making me hesitate:
1. Is this the right approach versus a direct reference to the dll in each application? In other words, rather than installing the service, provide each product team with a copy of the dll and have them add references directly to the assembly in their projects. This is how the ProjectTracker sample app is implemented but not how I see Microsoft doing it with their server applications.
What are the advantages of having the service interface (WCF/Web) between the application and the common component? This IS how Microsoft does it in Project Server 2007, for instance, where the Web Access application communicates through the PSI rather than directly referencing the server dlls. Using this model, the WPF Project Tracker application would be redesigned to use the WCF service interface rather than referencing the ProjectTracker.Library directly.
2. Deployment when there are multiple services. As I mentioned, we are looking at a lot of common logic that could result in many of these common components, each with a distinct purpose. Any or all of these components could be consumed as part of a product. I would need an easy way to package and distribute then deploy each of these services on a customer's system. I am having a hard time envisioning how this would work without a bunch of individual installers and a list of URL's (one for each service), etc. I like the idea of a PSI that contains each of the services installed on that system - one base URL for all of them. But, with an ala carte architecture... I dunno.
Does anyone have any experience in this area? What are your thoughts?
Copyright (c) Marimer LLC