This is a short paper on the concept of Multiple Service Environments. Users will have to work in multiple environments: at home, at the office, at school, etc. How does that impact how we want to design a Service-Oriented Architecture?
We’re all hearing about Service Oriented Architecture (SOA). The general idea is that applications will be constructed from and reliant on underlying services. These services will range from basic authentication & authorization to more complex business transactions.
As a user, you like to learn one user interface for each type of function no matter what context or environment you are in. You don’t want to use a different word processor for home and work. We are confronted with issues of using computers in more than one capacity, home, work and school, so what will it look like in the new world of services? Users will need to operate in multiple service environments provided by different organizations they are affiliated with. This will be an important factor in how SOAs are built and used. Let’s take a closer look at an example from a user perspective.
You may already maintain calendars in more than one place, often on a home computer and an enterprise calendar at work. In addition people often use a PDA and the ability to “synch” these different sources of Calendar information makes this manageable. However, as a user you might want to use a single application to view and manage all your calendar information regardless of the context. We don’t expect that a single system will manage all our calendar information; we don’t expect to share our doctor appointment and soccer schedule in the workplace system.
If you think about this problem in a Services Model; you will need applications that can use multiple Calendar Services. This would allow you to view calendar information from all the relevant calendar service sources; work, home, school, Red Sox etc. There might be several different front-end applications tailored in different ways, that all perform similar functions. These different applications could provide choice for the user if they could be integrated with multiple calendar services.
You’d be able to schedule things through a single interface and have a choice as to which calendars services your information was stored into. This separation of user-facing application from back-end services is a radical shift from the current “synch” model. Currently most people constructing applications using services construct them without imaging that these applications might be used with multiple service instances. If the application is designed without the expectation that the underlying service will change than the full benefits of SOA won’t be realized. Service technology use alone doesn’t insure you’ll have the benefits promised by SOA. If programmers construct an application based on the use of a specially created service, then it won’t be any easier to port this to use another service, than it was in the old days to make the application work with another database schema. It won’t be practical to have many front-end applications that can easily integrate with multiple back-ends, because the cost will still be too high. This means the old paradigm of tightly coupling the front-end application with the back-end will continue only using different technology.
What we’re really after is a way that different applications can be designed with clear enough assumptions about the services that they can be used with different service implementations. The largest obstacle to implementing an SOA isn’t the technology, but how we think about software in a new way.
Open Knowledge Initiative
http://plectrudis.mit.edu/okicommunity/article.php/20060109152142992