Dynamic by design

So when we think about loosely coupled services that compounds bigger complex services and expects resiliency, high availability, security and performance, between other key qualities. All single component of the tissue should behave to address those premises. Some functionality should be provided by the tissue DNA and the services should inherit those functionality without knowing how to do this.As a dynamic system the tissue use the service movement as a key function to increase availability and security, without interacting with the tissue core repository is not possible to know where is what, only the tissue itself knows that and protects this information from outside. Even a service don't know the whole tissue dimension.To implement the service movement architecture, some premises needs to be achieved:

• Migration between datacenter providers
• DNS service based on service availability
• DNS TTL on entry reduced while service migrations/recovery
• One DNS entry by service (TCP port) 
• This is a restriction not a functionality, to adapt to TCP/IP thinking way.
• All listening service should be load balanced (this is a requirement for high availability)
• Socket Listening services should implement a tissue listening API, that provides the same behavior for all listening components.
• Load Balancer registry using service tissue DNA.
• Load balancer balancing using service performance and availability information in the tissue DNA.
• One empty DNS service is started. There is not services available into the tissue yet. Is uses the tissue DNA as DNS entry catalog.
• When a load balancer service starts it registers itself into tissue DNA and is automatically available throught the tissue DNS service.
• When a listener service start it registers itself into tissue DNA and is automatically available to receive traffic routing from load balancing services. 
• The tissue DNA is replicated among the tissue and following the DNA service requirements.
• All load balancers are able to start forwarding for new listening services as it appears in the tissue DNA.
• Client do a DNS query to locate service (one hostname means a service).
• DNS service uses the tissue DNA to locate the  load balancer responsible for the service.
• DNS service answers the query with the IP of one loadbalancer.
• The client opens a socket to the IP received of a load balancer.
• The load balancer looks a listening service into the tissue DNA:
• More attributes are used to define the best listening service to forward the request to.
• If no listening service available throws an error.
• The load balancer creates a new socket to the listening service and forwards the client request:
• Wait for a determined timeout for the service.
• If the listening returns and error tries to open another socket to other listening service (connection errors).
• Tries to establish the connect a determined number of times.
• The listening service receives the socket and deals with it (forwarding or calling other sub-services).
• The listening service answers the request to the load balancer.
• The load balancer service answers the request to the client.

Sample service instantiation:

Sample service consumption:

This is a very simple task list of service flow, the way that is is divided, it can be used to scale horizontally maybe between datacenters, using load balancing for high availability and DNS roud robin for contingency. The DNS contingency can guarantee the right name resolution for valid IP address because it is based on a dynamig catalog (tissue DNA) istead of a static catalog.

One cell is a tissue

When the first cell of a tissue starts, we already have a tissue, this tissue does not have some expected characteristics like resiliency and fault tolerance, but implements some basic services needed for tissue grow.

To one cell be started is should have at least three parameters available:

• the tissue name, to join to an specified tissue, or an empty tissue name to join the first tissue it founds.
• the cell name, to identify itself , this name maybe tissue generated in the time of tissue registration.
• the tissue DNS servers, the IPv4 or IPv6 address to the DNS that provides tissue services name resolution:
• the DNS servers could be provided by three ways
• command line at cell startup
• cell.xml configuration file.
• broadcast on local network work DNS query (like DHCP broadcasting)

Cell startup general steps:

• if a cell starts and cannot locale the tissue DNS in any way and have a tissue name defined it assumes being the first cell in the tissue and:
• starts the tissue catalog service
• this services holds the catalog of services and ip addresses where are running
• starts the tissue DNS service
• this service queries the catalog to resolve hostnames for services (where the service is running)
• starts the tissue DHCP service
• this service listens for broadcast queries for tissue DNS service, specific or not and answer with the DNS IP address.
• the cell looks a hostname called dna.<TissueName> to reach the tissue catalog service.
• when the cell have a tissue catalog service available it registers itself in the tissue
• it provides information about itself 
• once registered the tissue provisions all cell services to the cell, and ask the cell to start them all.
• services the any cell should have:
• cell self monitoring service.
• cell tissue DNS pooling against tissue catalog service.
• cell tissue ask for change service.
• once with core services up and running the cell is able to receive queries about the ability to receive tissue services.
• the tissue can ask the cell for external resource accessibility, like databases and application servers or even being in and specific network segment.
• the tissue can deploy service code to the cell, enabling the to receive that service instances.
• the cell can receive temporary services to help the tissue to achieve the minimum service level requirements.

The tissue computing and ubiquitous computing

With the dynamic behavior of tissue computing another "by design" feature is to use very different devices for processing services. In one side we can have cell phones as clients or using components that are integrated with the tissue, like identity or single sign on agents or XACML PEPs, or one tight integrated agent for any kind of service (the tissue does not force any kind of client software but protocols like HTTP, STMP or other proprietary protocols). In other side we can rent anonymous machines processing power, in private set of machines or in a public set of machines.

Renting processing power example:

Imagine that one government geographic system needs to calculate the area from many polygons. This is a massive processor computing task, instead of allocate a high performance machine to do this task a tissue of area calculating services can be allocated to do this work, this tissue can be located inside a department desktop machines or over the internet, the requests can be done in a way that do not exposes sensitive data to the service. With a simple relation between number of polygons and the medium time to calculate each one is possible to calculate how many cells is needed to reach a response time for the whole task. Many other activities can be done in this way, like CERN experiments processing or geological information processing (there is already many examples working). This creates the possibility of people renting its home desktop and internet connection while not at home and earn money with this and in other hand peak demands being resolved without acquiring more processing power to the computing environment.

The bigger concern is about data security over anonymous processing power rental, but this I will talk about in another message.

The tissue computing and processing capacity management

The problem:

From the firsts centralized, "dumb" terminal based interfaces to the actual cloud computing with rich interfaces almost everything changed, interfaces, database software, operating systems, computer architecture layers, communication protocols, but in my point of view the big change is how users have access to the system functionality. In older mainframes someone that wants to run a program and receive the output as a printed list, should submit a batch request and way for free machine time to run, forms are written in paper sheets and then typed into system screen by computing skilled people. With the evolution of technology, part of the computing power goes to the user desktop, with client-server architecture but it still need software installed in his machine by some skilled person, this takes time and generates complexity in the environment and now we have the HTTP protocol that change radically how user obtain access to some system, he just need a network connection and a very generic software, one internet browser software.

So the mainframe architecture provides a very predictive demand planning, only those connected terminals can generate processing demands on the server, with the "opening" of the systems more users can easily reach the system and use it when it needs, this, in the user point of view is much better than job schedulers, but to the administration point of view generates lots of problems, with one internet open system is no more possible predict how many users will use the system in certain point of time, how much processing power will be needed to handle all requests, a concept of capacity planning becomes more and more important. Companies that handle with global customers does anymore nightly maintenance, always is day somewhere.

Proposed solution:

The tissue computing paradigm addressed this problem by design, the idea of a system that grow by demand and learn with his own history, ensures that the management of processing capacity is no more a (humans) system administrations but a system function, the tissue should be able to detect and react or forecast and prevent processing shortage and processing wastage situations.

Using this approach for system paradigm is feasible use big datacenters and rent resources for many tissues that coexists time-sharing resources as needed. Some classical cases that this is very useful are season changing behaviors like hotel systems and commerce system just before Christmas. Or some "sun following" systems that have more usage while this in its timezone and less while night.

The key features to solve this question are service migration, service scaling and service high availability in the  tissue.

The cell DNA is the tissue DNA

Like a biological tissue, the computing tissue should have one DNA (Deoxyribonucleic acid is a nucleic acid containing the genetic instructions used in the development and functioning of all known living organisms), it rules the behavior of tissue components, this DNA can be divided in two main areas, the DNA of the tissue rules each member behaviors, to be part of the tissue should follow the DNA directives, cell that does not follow the DNA for one tissue can be considered anomaly and killed.

Is expected the interaction between different versions of DNA, this is important for tissues version upgrade and downgrade.

The two parts of the DNA are:

- Static DNA part
    This part of DNA is defined by the version of the tissue DNA, if one tissue is compliant with one or more versions of DNA it should understand a those versions of DNA messages and should have DNA compatible behavior, as an evolutionary system each new version of a tissue should inherit previous DNA and enhance it. It cannot be changed without killing the cell.

- Dynamic DNA part
    This part of DNA is defined by the environment, changes in the environment causes changes on tissue DNA, other tissue premises, like response time for one service can change the tissue DNA (to guarantee those premises), the dynamic DNA part rules the externalized tissue services, any change in the dynamic part of the DNA should work without killing the cell or interrupting any service.

Some DNA configurations can be pushed from tissue to member cells or from member cell to the tissue, in this environment one cell can join a tissue without being created by the tissue, in this case the cell should present himself and proof that it is trusted by the tissue, int those cases some DNA content is forwarded from cells to the tissue (respecting the tissue version).

The DNA can be defined with different scopes, it can have a scope of cell, service or tissue, and one with more precedence over others.

  Higher level - tissue:

    Defines tissue level information communication and storage, defines the tissue services behavior

• defines the data structure for the tissue
• defines the services provided to member cells interfaces
• minimal number of services instances (availability of tissue services)
• cell reliability policies.
• expected availability for tissue services
• tissue history interpretation algorithms

  Medium level - cell:
    Defines cell level information communication and storage, defines the cell behavior

• maximum of host resources usage
• maximum of cell resources usage
• notification frequencies
• service acceptance policies (if a cell can receive a service or not)
• local cell configurations
• installation and work directories
• cell configuration files location
• tissue catalog service location

  Lower level - service
    Defines service level information communication and storage, defines de service behavior

• expected availability of the service
• ports and load balancing algorithms
• specific service configurations

DNA in this system does not represent code, but how any implementation for one tissue should behave. The tissue should hold all the DNA information with all details, this allows the tissue to replicates lost cells or clone cells for growing. The DNA should open to permit many vendors interact in the same tissue providing complementary services.

The steps to reach a mature level

Extending the Autonomic Computing concept, Tissue computing is not about a revolutionary technology but an evolutionary technology, it should be open and heterogeneous,
to easely be adopted by different vendors. The implementation of the tissue and cells but the information flow and persistence should have a well defined format.

Those tissues can be private or public, symmetrical or asymmetrical, homogeneous or heterogeneous, aware of cell implementation technology, location, network distance.

The experience demonstrates that the XML/WS combination is the most powerful way to expose and transmit information between loosely coupled components, so
the definition of the tissue computing will be done using XML/WS language.

To reach a good maturity level of this systems architecture paradigm, is important that the information flow and information storage have very well defined formats,
the information handled by this system can be divided in 2 categories:

Information flow examples:

• Cell administrative communication with tissue
• Services availability information
• Cell help ask to the tissue

• Tissue administrative communication with cells.
• Ask for resource availability (internal and external)
• Cell death detection
• Service relocation

• Service administrative communication.
• Service status information
• Service history notification

Information storage examples:

• Cell self information
• Cell services information
• Cell resources information
• Cell external resources information

• Cell self environment information
• Host resource used by cell
• Host resources available
• Host availability history

• Tissue self information
• Cells information
• Services information
• External resources information
• Dependencies information

• Tissue environment information
• Information about the cell's hosts
• Information about tissue network elements topology

• Service self information
• Information about service 
• Service configuration

• Service environment information
• External resources failures
• Service usage history

There are many other information about tissue tiers that should be well defined, the be compliant with most computing technology platforms, the best way is to define "xml schemas" through XSD files,  by this way the core of the tissue (his DNA) will be defined by a set of XSD files. Also the interaction between

The steps to reach a tissue maturity

Extending the Autonomic Computing concept, tissue computing is not about a revolutionary technology but an evolutionary technology, it should be open and heterogeneous, easy be adopted by different vendors. Not the implementation of the tissue and cells but the information flow and persistence should have a well defined format.

Those tissues can be private or public, symmetrical or asymmetrical in terms of service distribution or host characteristics, homogeneous or heterogeneous in terms of hardware platform, operating system, , aware of cell implementation technology, location or network distance.

The experience demonstrates that the XML/WS combination is the most powerful way to expose, store and transmit information between loosely coupled components, so the definition of the tissue computing will be done using XML/WS language. It is very useful for high abstraction definitions.

To reach a good maturity level of this systems architecture paradigm, is important that the information flow and information storage have very well defined formats,  the information handled by this system can be divided in 2 categories:

Information flow:

  - Cell administrative communication with tissue
    - Services availability information
    - Cell help ask to the tissue
 
  - Tissue administrative communication with cells.
    - Ask for resource availability (internal and external)
    - Cell death detection
    - Service relocation

Information storage:

  - Cell self information
    - Cell services information
    - Cell resources information
    - Cell external resources information

  - Cell self environment information
    - Host resource used by cell
    - Host resources available
    - Host availability history

  - Tissue self information
    - Cells information
    - Services information
    - External resources information
    - Dependencies information

  - Tissue environment information
    - Information about the cell's hosts
    - Information about tissue network elements topology

 
Note that those communications are not related with the services implemented by the cells, only the tissue adminitration information communcation or storage is considered, if a cell provides a SMTP listen service, all communication with mail relay services is not covered here, only the information about those inderdependent services are related is relevant to the service tissue.