PalCom Open Software Architecture
PalCom is about software. Software, that fits the age of pervasive and ubiquitous computing.
The Palcom Open Software Architecture is continuously enhanced and developed by a large group of collaborating software developers from University of Aarhus, Lund University, Malmo Högskola, University of Siena, Siemens, 43D, EPFL, and Whitestein.
The architecture is developed through real life settings.
Compared to ‘constructed examples’ (examples thought up for the occasion), the real world kicks back and informs the architecture with real life challenges.
The challenges are addressed in order to meet the vision of palpability and in stages turn it into a reference implementation of the software architecture. In short: To make computing palpable.
Service oriented architecture
The nature of the software systems in PalCom is that they consist of small subsystems that are self-contained and communicate with each other to solve the tasks needed by the users. Therefore, the choice of architectural style gave itself as a SOA architecture.
SOA: definition
A service-oriented architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within distributed systems architectures.
As an example, The PalCom Geotagger application consists of a GPS-service, a camera service, a digital compass service, a geoconverter service and so forth.
This separation allows services to be distributed to different machines and different locations. At the same time it offers the possibilities for the user to bring together any services in so-called assemblies with explicit representations.
The notion of Assemblies
The notion of assemblies is to support understandability, flexibility and inspection.
- The assembly mechanism makes the systems open to unforeseen combinations.
- It makes them more flexible because the users can put them together in different ways.
- And it makes them inspectable.
Inspection is extremely important, for example, if users should be able to deconstruct an existing assembly in a sensible manner. To support e.g. sharing of assemblies among colleagues, it demands an explicit representation of the services combined as a whole.
What sets assemblies apart from other composition mechanisms is that an assembly more or less is represented explicitly in the software.
This means there is something that can be subject of inspection. Rather than just setting up connections between individual services.
The vision in PalCom is to develop a more understandable, easy-to-use mechanism for constructing, de-constructing, and re-constructing when, for example, one is reusing parts of other systems in unforeseen new combinations by using this assembly mechanism and managing contingencies.
A way to handle contingencies
The PalCom Open Software Architecture provides means to handle contingencies. Contingencies are not to be considered as errors, but a fact of life in a pervasive era.
The main reason for addressing contingencies is to unite the user and the systems. It all comes down to coping with the world of ever changing environments.
PalCom is getting there
To read more about the PalCom open architecture, the challenges and solutions please address the selected headlines from the top-right box on this page.