HomeAboutBlogNew ArchitectureOriginal ProjectOriginal ArchitectureContact Us
ExperiaSphere
Think Outside the Bit
Original Architecture

ExperiaSphere's basic architecture is best understood by understanding how it would be used, so let's go over the basic steps.

First, the organization that wants to deploy ExperiaSphere-based services would collect service resources. Service resources consist of any of the following:

  • Management APIs that are to be used to control the networks, servers, applications, or other service components.
  • Partner Experiams that are available to build services.
  • Internal Experiams that have been used to build other sources or control other resources.

The first class of resources, the management APIs, then have to be encapsulated for use, which means that a Java developer would use ExperiaSphere to create "ControlTalkers" for each of the unique APIs. This would allow them to be referenced by service components.

The second step in the process would be to define Service Factories for each of the services. The service factory structure is defined for ExperiaSphere and there is documentation and sample logic available to partners on how to to this. Each Service Factory is a structure of Experiams that represent the components of an experience or service and their relationship to each other. When a Service Factory application is run, it creates a Service Order Template that, if filled in and posted to the Factory, creates the service. This Service Order Template can be filled in anywhere, and in addition any Factory that has the same structure as the application that created the template can be used to fill the order.

The third step in the process is to create an application or linkage between the Service Order Template and an ordering entity--a user, a customer service rep, or whatever. This application receives the Service Order Template and creates an instance from it.

The final step is to post the Service Order from the earlier step to a compatible factory for execution. When this is done, the service is created as defined in the order.

These steps are a complete description of how ExperiaSphere works in a single-provider framework. Where services are composed across provider boundaries, ExperiaSphere supports a powerful notion we call the Proxy Experiam. Proxies represent externally supplied components of a service and link to them abstractly. When a Proxy calls on service, it obtains it from a matching Host. The Host Experiam is an element in another Service Factory, and when a Proxy and Host connect they are in effect linking a retail and wholesale order. Each of these is managed independently, with their interdependence managed by the links between them, which is created by a special Messenger process.

Service Composition


Many services, and most services today, are static in that their feature components are fixed. That means that the "structure" of these services in a Java/Experiam sense is also static. But the market is evolving toward a more flexible model of services, one that is designed to embrace broad partnerships among feature providers and multiple variables in service structure. Both these create a requirement for flexible composition of services from Experiams.

As a high-level principle, ExperiaSphere's Experiams are all independent finite-state machines and they also have the ability to control the state of their subordinates and to use subordinate state in their own state processing. For example, a parent Experiam can advance to the DELIVERING state only when its subordinates have all similarly advanced. It is also true that Experiams are normally explicitly composed, and that the composition process is conditioned on structural issues and not order issues. However, even in a Hosted model (see below) an Experiam can instantiate multiple subordinates (making them a part of the hierarchy) and thel selectively ACTIVATE them based on order parameters.

The second high-level principle that is important in composition is that Experiams can be "represented " or Proxied in other domains by a Proxy Experiam. This Proxy links back to the Host via any protocol the two agree on, and the two can then synchronize their behavior. Thus, Proxies provide a kind of "virtual" Experiam, and that can be bound to a "real" one through a flexible binding model (our second model below).

The other models are based on authoring flexibility and can be developed and refined as needed.

ExperiaSphere supports the following dynamic models of flexible composition:

  1. The Experiam-Hosted Composition model, where a parent Experiam in a hierarchy contains the logic to select subordinate Experiams based on technical or commercial criteria. In this case the dynamism is built in to the structure, and applies only where it is explicitly included.
  2. The Flexible Proxy Binding model, where Proxy Experiams that are placeholders for "real" implementations are bound through the services of a flexible Broker that makes the selection on what Experiam to bind with based on those flexible criteria. Any Proxy/Host relationship can be bound via a Broker to add flexibility.
  3. The Model-Composition Method, where software builds an entire Experiam hierarchy based on commercial criteria, using XML files as imput.
  4. The Order-Bid model, where a service order in XML form is dispatched to partners to support a bid on the execution of that model.


 

ExperiaSphere's Approach to Personalization in Communications--the ENTITY


In ExperiaSphere, an "Entity" is something that is a user of or component of a service or experience. Entities can be individuals or groups of individuals, and each is known by an EntityName.

 

What's an Entity?

The term "ENTITY is used to indicate the singular label and set of properties that describes some specific element within ExperiaSphere, which may be a user or consumer of services or may be an element of such a service. The notion is that the label can be used to unambiguously reference the set of properties associated with the referenced entity.

 

How Does ExperiaSphere Treat Entities?


Flexibly, in short. In ExperiaSphere, an Entity is a hierarchy that builds from an EntityBroker. The way it works is best understood by assuming that we have an individual named "Bill" who enters into network, service and financial relationships. Bill purports to "be" someone meaning that there is a physical thing that the name "Bill" references, and individual. When Bill creates an account with someone, he likely defines the notion of "Bill" as some collection of properties, like the name, address, etc. Bill, however, is really a nickname that has been created by the real individual; Bill may not even be the correct name. Thus, ExperiaSphere presumes that EntityBrokers store Entities.

Entities have properties that are specified or inferred. Each property is defined by a name, a value, and a source. Properties can be grouped arbitrarily, but the standard grouping that ExperiaSphere assumes is as follows:

 

  • EntityName; the name or nickname

  • EntityAssertedName, the name given as the "real" name of the persona

  • EntityDescription, including address, and demographic information

  • EntityLocation

  • EntityFinancialIidentity, meaning credit card numbers, etc.

  • EntityAliases, the other EntityNames the individual is willing to link here

  • IdentityState and IdentityAuthority, which indicates whether the identity of the Entity is certified, and if so by whom

     
ExperiaSphere allows any designated EntityBrokert to create and sustain Entities, but only hosts with certification authority can verify the asserted name and other attributes of an identity. When someone wants to access Identity data they make a request to the EntityBrokers under a EntityName and obtain the information they are entitled to have.

An EntityBroker is a form of an ExperiaSphere Broker, which is then a subset of Messenger/Handler.


 

Basic Application Development with ExperiaSphere


An ExperiaSphere application is a J2SE program that conforms to basic structural rules at the minimum, and there are also certain “best practices” that may be helpful in guiding prospective developers.

First, the must-have rules:

  • Every application must contain the ExperiaSphere Context object, which provides the basic tools, and also the Service Factory object that provides the linkage between the application’s Experiams and the outside world.

  • Every application must have at least one Experiam, the “Prime Experiam” that represents the structure.

The structure of the underlying Experiams depends on the nature of the service. We believe it’s best to reflect two different kinds of “structural division” in the Experiams—differences between your own resources and those of partners, and differences between logical components of a service—connections, content, processing, etc. This figure shows an example of this sort of structuring:

ExperiamHierarchyExample.jpg

You will note that there is an implicit third logical division here—the division between “services” and “resources”. ExperiaSphere is based on virtualization and abstraction. The first step in creating an Experiam structure to represent a service is to create a “tree” that divides the service according to our structural divisions of ownership and logical components. At the end of each branch of those trees is what is effectively a “virtual resource”. The higher part of the tree organizes the service in an abstract way, and the virtual resource is a placeholder for the real resource needed at that particular point.

The final part of the process is to make that virtual resource real, which means including an Experiam or set of Experiams that provide a link to a management API, to a partner’s Experiam-based application, etc. This process can be a simple non-selective linking to a management API or an Experiam representing a complex selection process--something we use in cloud computing and call a Resource Broker.

Each Experiam in this structure that has a subordinate is called a nodal Experiam and these are responsible for processing the events directed at them and decomposing and redirecting these events as needed to manage the behavior of their subordinates. This state/event management is what creates the flow of activity associated with the lifecycle of a service or experience.

The above slide is one from our ExperiaSphere in Depth partner presentation, and further details on application structure are available to partners only.



Principles
Abstraction/Facilitation
ExperiaSphere
SocioPATH
Integration
HomeAboutBlogNew ArchitectureOriginal ProjectOriginal ArchitectureContact Us