Please check out our primary ExperiaSphere wiki-based website for a blog of ExperiaSphere status and much more material!  CLICK HERE to visit the site.  Look for the details of our Alpha-One prototype and our partnership with Extreme Networks.

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 "ExperiaSphereTM ".  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 a complete framework for the creation of NGN Services Architectures (NGNSAs)  that can include how service features operate (a Service Logic Execution Environment or SLEE) and 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 complete NGNSAs or components.  The ExperiaSphere 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:
Are you hungry for more information?  Here are some downloads available to the public:
Please visit our ExperiaSphere wiki to see what else we have to offer!

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

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

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