Some people call the Internet the "network of the future".  Others just use the term "NGN" for "next-generation network".  Whatever we call that network, it's pretty clear it will be very different from today's networks both in technology and business model.

The driver for this change is a fundamental shift in what a network is for.  When public networks first deployed they were exclusively designed to support communication between users.  You called another party and not "the network".  Data services flowed from site to site, not from site to cloud.  The Internet changed all of that, providing us with an experiential service model that has not only totally revolutionized the consumer space, it has spread its impact into the enterprise.  The most significant issue in all of networking is the support of this new model.

There are many people working to do just that, of course.  Some have proprietary visions and others are working within standards groups.  It's obvious that the health of the market as a whole would benefit most from standard architectures for experiential services and so most would hope that the latter effort would succeed.  The problem with this was stated decades ago by Andrew Tanenbaum:  "The wonderful thing about standards is that there are so many to choose from" (Computer Networks, Tanenbaum, Prentice-Hall 1989).  In a recent "team call" for the Telemanagement Forum, itself a standards group active in this area, work by the IPsphere Forum (IPSF) and the Open Mobile Alliance was cited as being related and relevant.  Three standards groups on a single call, on a single issue.

Too many standards are no better than none at all; it fragments the market and slows implementation.  That problem is particularly acute in the area of experiential services, because the very Internet phenomena that spawned those services are now driving the market issues forward at an accelerating pace.  Both the IPSF and the TMF are proposing trials of architectures in 2008, and it's clear they can't trial the same architecture because the issues have not settled, and there are still debates over how far a "management model" will go in defining service behavior in any case.

Sometimes you have to step back and take another look at the issues, and that's what we are proposing, in an open source initiative that we call "ExperiaSphere^TM ".  The goal of ExperiaSphere is to "surround" an experience in a set of objects, and in this it may appear to be very much like IPsphere, the TMF, the OMA, and others.  But ExperiaSphere is a top-down data-model-independent Java-based approach that is based on the principles of object-oriented programming and object modeling.

ExperiaSphere defines an Execution Environment (EE) that can be used to describe how service features operate (a Service Logic Execution Environment or SLEE) or to describe how service lifecycle management and operations management functions (a Service Management EE, or SLEE).  It's our goal to allow service architects to develop service and management logic using ExperiaSphere tools and create SLEEs and SMEEs.  The ExperiaSphere EE framework is unique in that it supports not only traditional computing models (any that have a Java Virtual Machine implementation) but also any remote computing model, including and especially grid and cloud computing.

The architecture is simple; it contains only one really visible object, an Experiam.  An Experiam is an "Experience module", a component of what somebody wants to experience through a network relationship.  Experiams are hierarchical, so you can assemble a group of them to create a complex structure.  This same notion of decomposition is also supported by standards bodies like the IPSF and TMF, but it's support is at the data model level.  Remember, ExperiaSphere has no specific data model.  An Experiam is a Java object (what some call a "POJO" or Plain Old Java Object) that, when used, creates the experience.  If an Experiam collects others into a structure, it must decide how those others are to be organized.  They, in turn, may organize and control any structure under them.  Since Experiams are open-source code, anyone can create one to support any sort of experience they want to offer.  All that's needed is that the Experiam conform to the structural rules so it can interoperate with Experiams created by others, and that somewhere at the bottom of the hierarchy there's a set of one or more Experiams that can, through some interface to real resources, bring about the experience that the structure represents.

ExperiaSphere is a software framework, in short.  Anyone can author Experiams, and because of that they can put any behavior they like inside as long as they conform to the structural rules for interoperability.  An "experience" can be a voice call, a content delivery, a game, a download, an email, even (with the proper control logic) the sounding of a bell or the launching of a rocket.

There will be people who argue that this kind of thing could be done using "SOA" or "BPEL" or something else, and that is both true and false.  Yes, both of these could be used, but they haven't been successful so far.  In SOA first case there would be no interoperable structure assured.  To quote a service provider, "No matter how well intentioned, the answer 'it is SOA' is not enough, it may work in a single vendor environment but the world is not that simple and we need interoperation on a B2B scale such that we can interact with other SP networks and beyond."  In the BPEL case the number of BPEL-literate workers is limited, the flexibility and performance is limited, and the whole thing ultimately rests again on SOA.

The same provider we cited above says that they have "stated in the past that we want unambiguous concrete and implementable" standards and that "when I use the word 'abstract' I mean a higher level of indirection not ambiguity!"  The problem is that data models and standards are by their natures abstract, and unfortunately the implementation is most definitely ambiguous.  That is why ExperiaSphere is a programming-driven object model and not a data model.

Here are some of the key properties of ExperiaSphere:

• It is data-model-independent and thus can be used with any data model or even with several at once.
• It is implemented in Java using only the basic package tools and so it does not require special extensions like J2EE, though it would be compatible with them.
• Service components and services are represented by a simple object (an Experiam), and they can be "atomic" and not divided into any structure at all, or represent a complex linked structure of Experiams.
• Anything that can be controlled by a software interface can be controlled by an Experiam and thus be a component of an experience or service.  While that certainly includes network resources and IT resources like software, servers, and SDPs, it also includes applications, disk storage, management tools, operator and user displays and inputs-pretty much anything.
• It is fully extensible since it is open source, but it is based on the CDDL (Common Development and Distribution License) and so derivative commercial products are supported.
• It can model a service from a management perspective (for lifecycle support), from an execution and signaling perspective (to implement service logic) or both at the same time.  ExperiaSphere can implement the components of IPsphere or TMF's eTOM.  It can also invoke those components as a part of the delivery of a service or experience.  All of the use cases currently defined or suggested for either IPsphere or the TMF can be delivered through ExperiaSphere.
• Components of a service or experience can be assembled in one spot or distributed worldwide.  Where global components are used, the components can be "reflected" and abstracted to a local image for manipulation.  In fact, several different "slave Experiams" can be linked to one "Host Experiam".  Any popular messaging standard can be used to provide this linkage, and through this linkage Experiams can support any standard management interface as well.
• Experiams can support Java concurrency and threading as needed, and each ExperiSphere experience is labeled to indicate if it supports concurrency.
• Experiams can support grid and cloud computing models, and in fact can represent even non-Java applications or application components.

Networks of the future will be based on services and not on transport. It's time to " Think outside the bit^TM". We're looking for partners and sponsors for this project in the following specific areas:

• Equipment vendors (network and IT) who will work with us to expose their low-level management interfaces using Experiams.
• Software vendors who will work to expose software components and interfaces using Experiams.
• Enterprise software or hardware vendors with ideas on how to apply ExperiaSphere in enterprise applications, including collaboration and unified communications.
• Java developers, particularly those with experience with J2SE Version 6 features for concurrency, threads, and blocking queues, who want to work on transforming the network experiences of the future.

If you are interested and qualified you'll contact us for details!

ExperiaSphere and "Think outside the bit" are trademarks of CIMI Coropration.