Pipeline Publishing, Volume 4, Issue 4
This Month's Issue:
Maintaining Network Health
download article in pdf format
last page next page

Self-* Networks: Helping Networks
Help Themselves

back to cover
.
article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

throughput and availability considerations expressed as runtime SLA's associated with each business service. Self-repair, self-scaling, and self-protecting, a next generation "Service Fabric" will have no single points of failure, and will adapt in response to the volatility it experiences in the underlying resource landscape.

A "Service Fabric," rather than forcing business services into a specific execution pattern (GRID, ESB, etc), will instead adapt in a manner appropriate to support the requirements of each instantiated business service. Within a next generation "Service Fabric," initial deployment, service recovery, service adaptation and manageability considerations coalesce, and so can be seen for what they really are; simply different facets of the same fundamental management task, at each point in time ensuring that each business system achieves "target state."

Alarm Processing, a Self-* example approach

With all the existing infrastructure which is already deployed on the paradigm of broadcasting alarms, the current fault applications are not going out of business anytime soon. But service providers could start to draw down on the problem by demanding intelligent devices with active programmatic interfaces from their vendors. By deploying switches/routers which find networks, register themselves, automatically download software updates, get configurations from directories or XML servers, and then push their management interface into the management infrastructure, providers would be on the way to self-healing networks. Devices can be made to do this; two vendors did this in the TMF Fine Grain NGOSS Catalyst demonstration.

Alarm processors and other OSS could be rewritten to be self* but more advanced models can provide a generational jump. As described above, devices are modeled in a virtual/logical representation of a system which connects to the devices, which supply constant state updates. This network model then becomes an active control interface and a ‘picture’ of the health of the network. This model is a set of distributed services within the self-* grid. As the self-* services maintain their own health, these services maintain the health of the network. By replicating services in the grid, standby, regenerative OSS is created - as well as policy-driven scaling to meet real-time demands. By placing an application pattern or a connection pattern into the meta-data of the Registry or Network model, the real instance is created and automatically maintained by the system. It stays up until either there are no more healthy resources available anywhere, or you request it to be ripped down.

.

Companies and Open Source Libraries

There are several open source movements that target self-* systems. Notably these include the Java community projects for Jini and RIO. Perhaps the largest organization is the Global Grid Forum which produces not just interoperability “standards” but also supports an open source code library. Internet II and OASIS have strong overlaps with these aforementioned groups.

Most of the first generation self-* startup companies and internal corporate initiatives have already failed. Sun’s Jini, MCI’s NewWave, Valaran, and IntaMission all broke technical ground, but were unable to turn this into market success. Fortunately, industry progress still occurs, these approaches just will not die. In these articles we try to not endorse any specific vendor solution as better than another; rather to list places the interested reader can go for follow up and solutions - where you can go to get the needed tools, platform, and equipment. Today, 2nd generation self-* products exist and are available for commercial deployment. All these companies have successful deployments past them. Most have endorsed the Grid model and ubiquitous computing as frameworks for their marketing message. While probably not the complete list, these are companies with whom the author has experience:

  • Blitz (modified model of supported open source Javaspace): out of England
  • Gigaspaces: moved from Israel to the US; also a principle supporter of the open source RIO project
  • Majitek: out of Melbourne, Australia
  • Netcaboddle: out of England.
  • Paremus: out of England
  • Univa Corporation (supporting GGF open source): out of the US

In addition, among established, mainstream vendors, IBM has a strong expertise in business support grids and also T-spaces, a space-based product; however, you must be really persistent with the IBM account teams to get them to propose these products. CapGemini Europe has an “integration” sub-practice that is based on self-* software, but again it is hard to extract from their mainstream practice. HP and Sun have long been associated with the concept of agile systems; but neither offer specific self-* products as part of their mainstream offering. Many Japanese companies have active research and projects deploying this technology internally, but have not made any strong commercial push as self-* software or hardware vendors. We know Motorola, current home to policy pioneer John Strassner, also has a program, but it is buried very deep for the moment and we do not know when it will see the light of day.

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
last page back to top of page next page
 

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.