Orchestration/Design Concept - Service

= Design Concept - Service =

Overview
Focusing on services can be quite simplistically motivated - service is one half of 'Service Robotics'. Digging deeper though, this context can be seen to provide strong motivations for this decision. Developing service robotics solutions requires taming of two difficult to control problems. Having a focus will help focus direction and management of both.

Diverse Development Groups - throughout the process of building a service oriented solution, the groups involved are significantly diverse and often remotely connected. Designers, android/web app programmers, software developers, robot developers - even the user/customer should be considered part of the process. The concept of the service is the blueprint for which each individual group's role can be specified and a broader picture inferred.

Distributed System - orchestration will ride on a layer of distributed robotic and device resources, shared software nodes and human interactions which can quickly become complex and difficult to manage or control to produce desired outcomes. The service blueprint can provide a way of formalising the requirements and also as a means of testing, validating and monitoring the system in a human compatible way.

= Service Oriented Workflow =

Focusing on the role of the service, the following will attempt to capture the process of orchestrating a solution from start to finish without delving into the technical details. The aim of this is to provide a clearer picture the intent for orchestration.

https://docs.google.com/drawings/d/16olEFJiqYwW2KDEe7xv06T6XbLuCkEARDg10jlDgYnU/pub?w=696&h=125&.png

We have four groups of people involved in this process (from left to right):

We hope to provide assistance with the management process via a Social Authoring Suite and tools that assist in common app development.

Service Modelling
The goal in this phase is to translate the real world problem/service into models appropriate for the context of the problem.


 * Utilise modelling languages such as BPMN
 * Generate snapshots of the proposed service from sufficient varied perspectives (workflow, actor views, state, etc) to describe the service.

Composer
The next step requires mapping the models into a specification that can be used as a guideline for arranging and configuring the necessary requirements for client resources, software nodes, services and interactions. The key point here is to compose the service. The actual development (programming) and implementation configuration will come later.

Development
If you are only doing services with two or three robots, then you can potentially consider service development without any need for real development (in the sense of software or hardware development). In this case, the service developer's role is very simple and just a matter of rearranging components to do what you wish. This is a fairly common assumption, however we expect, that this will not ordinarily be true. Especially with the introduction of interactive human clients, services will typically involve at least some custom design and web app/android development tailored to the specific solution. Beyond that, given the permutations that can arise and the fact that the service robotics industry is far from reaching a critical mass, one should reasonably be able to expect that any solution provider will have to get 'dirty'.

Solution Configuration
This step involves preparing an entire solution ready for deployment.