In Mundo the service oriented architecture (SOA) paradigm is applied to ubiquitous computing environments. This means that any party that participates in the environment is a service and uses services. Services are realized by a service implementation that can be accessed via network through a computing interface.
Services are on one side very specialized but on the other side application independent. Further services can be discovered and changed at application runtime. This makes SOA very suitable for UC. So, building applications is defining the control and data flow between the services. This supports the realization of applications that are:
- adaptive
- dynamic and
Issues
When looking into detail there are many problems to solve:
- Sematic Service Description: What does a service? Under what circumstance can it be used? Publishing an computing interface and some properties describing the service is inappropriate for large scale systems. More sophisticated and expressive semantic enriched service descriptions are needed.
- Scalable and Distributed Service Discovery: In near future zillions of services will be published. Many systems assume either that a single well known registry will hold all the information or that because of local proximity a discovery based on multicast will to the job. There are scenarios where both schemes fail therefor a newly distributed, server less service discovery has to be developed.
- Service Execution Layer: The strength of SOA may sometimes turn into its weakness. A programmer has to specify the services needed, handle the crash of services, transform inputs and outputs of services… This causes much managing programm code that makes a programm harder to read but adds nothing to the functionality of the programm. A parameterizable “service execution layer” may help a programmer. The programmer defines what to do unter certain circumstances and may keep this off the programm code.
- Easy and rapid application development: Because all the functionality is in the services application development can be reduced to “wire” the services this means define the data and control flow between the services. An application than can be seen as a state machine or a petri network thats state transitions are triggered by results and events from services and thats outputs are method calls or sending of messages to services. A GUI based “drawing tool” may improve the speed (and quality of) application development.
