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

Important!  Because of the issues related to the use of Java on mobile devices and the fact that ExperiaSphere uses a Java framework, we recommend anyone considering running ExperiaSphere on any mobile device insure they comply with Oracle's license terms.  We do not represent to have a right to re-license Java to mobile users!

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 technology part is pretty settled; NGN is based on optics, Ethernet, and IP instead of TDM or ATM or frame relay. But the service part, and the business model, is far from settled. All that we know is that it will be something dynamic, something that can match velocity with an ever-changing, web-driven world.

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.

The Original ExperiaSphere Open-Source Java Project

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. That means that ExperiaSphere is an implementation model not an interface model, so if you adopt it you do so by writing programs in it. There is no middle-man delay here.

This is the critical difference between ExperiaSphere and standards activities. ExperiaSphere is about functional behaviors and creating functions that are linked through interfaces. The interfaces are secondary to the ExperiaSphere process, not because they're unimportant but because they are easily changed. Any functional model in ExperiaSphere can be exposed through any interface that can convey its required parameters. In general, that would mean supporting the exchange of an XML template of some sort, but even that level of standardization isn't necessary. You can send and receive data in any format you like. If there were no parameters required to invoke a functional model that represents a service or experience (because nothing was variable), you can activate it with anything convenient--a REST/HTTP call, a SIP message, an SMS or email--it doesn't matter. The experience is written once as a model and interfaced in any way that's convenient. Thus, standards (which focus on interfaces) can be easily accommodated as they develop or change, and multiple standards can be used to support the came processes.

ExperiaSphere is a project to try to help define the Next Generation Network Services Architecture, or NGNSA. There are three primary components to ExperiaSphere:

  1. The Service management and abstraction component that is the core of ExperiaSphere's ability to create services by orchestrating components.
  2. The Broker model, which provides a flexible way of linking services to users.
  3. The Entity and social communications framework component that forms the basis for Identity management, process management, and relationship management.

These three components also define the three phases of our project, the first of which is now complete in Alpha-One, the second partially demonstrated there and to be completed in Alpha-Two, and the final phase which will be completed with Alpha-Two, leading to release of our beta code late this spring. At that point, we hope many people will play with the concept and develop it to full potential.

The basic notion of ExperiaSphere is pretty simple. If you construct a good set of Java classes, you can define a service or experience as a simple hierarchical structure that can be "insulated" from the physical devices and software tools that support it. You can activate the service or experience by sending a message to that structure. What kind of message? Any kind that can be communicated to Java through some standard set of network classes, and can carry the information needed to define what the service is. If the service or experience is "self-defining" meaning that it doesn't need any parameter values, you could activate it by a key sequence on a cellphone, or any other event. Remember, we're focused on functional behavior, the area that standards forgot.

The language of the Experience can be ported to any software framework that runs a Java virtual machine (JVM). ExperiaSphere can author IMS applications, but those same applications (if property written) can be run without IMS. It can work inside a carefully structured and managed network operator OSS/BSS framework, but also "over the top" in a standard Internet service context. It supports voice, data, video, fixed, mobile, portable, standard, non-standard, multi-standard...you name it. The goal is to secure service logic and management abstraction to the fullest sense.

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 difference between the two is that a SMEE is used to set up, modify, and take down services but doesn't participate in the service itself, where an SLEE defines actual service logic. The two are very separate today, but ExperiaSphere lets you write one, the other, or both at the same time.

 

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.
  •  

We have recently added cloud computing and virtualization to our list of things that ExperiaSphere can do! Experiams, as we have noted, can "proxy" for a resource or activity that's hosted somewhere else, creating a kind of "master/slave" relationship. This lets ExperiaSphere support grid/cloud computing in three distinct ways:

  1. The "remote" side of an Experiam can be hosted in the cloud or on a grid, with the binding between it and the proxy Experiam that is actually written into program logic created only when the Experiam is activated. That means that any application that is hosted in a virtual resource sense can be represented by an Experiam, and the user of the proxy Experiam need not know about the hosting at all, or where it is realized. With ExperiaSphere, there is no difference between a cloud/grid experience and any other, so it facilitates deployment of cloud/grid applications.
  2. ExperiaSphere can deploy service logic in grids or clouds transparently, so grid or cloud resources can be used to support service logic.
  3. Experiams can be authored to represent abstract functions that are to be fulfilled in grid or cloud resources and bound to local functions in testing, then rebound to real cloud/grid resources when production operations are initiated.

Enter Our Process


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.
  •  




CDDL
Partner Area
Downloads
HomeAboutBlogNew ArchitectureOriginal ProjectOriginal ArchitectureContact Us