z!™ is ICONOCI's innovative software architecture - clustering technology and advanced distributed algorithms for solving real time decision making problems. z!™ is designed to help solve complex planning, scheduling, optimization, forecasting, simulation, pattern recognition and classification, and diagnosis and monitoring problems in real time by distributing data as well as processing across commodity hardware. The z!™ technologies form the foundation of ICONOCI's product suite.

 

z!™ (pronounced zee-bang) Simply put, it means "z-best!"

 

Yes. More accurately, we are an intelligent, real time, decision support technology company.

With z!™ we are able to solve complex problems instantaneously, problems that usually take anywhere from minutes to hours to figure out. And z!™ operates on commonly deployed technologies, is massively scalable and provides continuous availability as well as exceptionally fast response times. We have already proven z!™ with results that are orders of magnitude beyond anything available today.

z!™ promises to have a considerable impact in a world with an ever increasing need for real time decision making. Acceptable standards for what constitutes real time have shrunk dramatically in recent years. The revolution in e-business highlights this change in expectations.

z!™ products are applicable to many industries, of which e-commerce is a prime example.

 

z!™ employs a distributed memory resident data model that has, at its core, innovative clustering technologies and distributed algorithms. Hence data as well as processing are truly distributed. Issues such as atomicity, concurrency, and durability are solved by z!™ in a manner that allows a much higher transaction rate than can be found in traditional database systems.

 

While z!™ uses advanced networking protocols to achieve a scalability across clustered machines, it runs on top of industry standard and readily available network technologies. Collectively, we have many years of experience in both writing network software and deploying networked applications. This experience has been used internally in z!™'s clustered architecture to provide extremely high throughput, scalability, and availability.

 

Architecturally, z!™ can be viewed in three tiers:
  z!™ API (Application Program Interface)
  z!™ Coordinator
  z!™ Solver Clusters

z!™ API

Users of our z!™ interface via asynchronous function calls to z!™ API - a comprehensive set of C function calls that perform problem specific requests. For example, for fulfillment planning these include customer requests such as quotations, orders, cancellations and reservations, and also vendor updates to the supply availability.

z!™ API can be integrated within user applications using XML, Java, CORBA or COM objects. The interface between z!™ API and z!™ Coordinator is many-to-many via protocols that run on top of TCP/IP.

z!™ Coordinator

z!™ Coordinator performs two primary functions:
  - distribution of requests to the solver clusters
  - global optimization of the fulfillment algorithms

The interface between z!™ Coordinator and z!™ Solver Cluster, and within the solver clusters, is via ICONOCI's innovative clustering protocol - z!™ Net.

z!™ Solver Cluster

z!™ Solver Cluster consists of two components:
  - z!™ Master
  - z!™ Replicas

z!™ Net facilitates failure detection, fail over and role changes. For example, if a master fails one of the replicas will dynamically assume the role of the master, with no visible impact to the customer.

 

z!™ is currently deployed and tested in the Windows NT 4.0 and Windows 2000 environment. We will be porting to UNIX platforms according to future planned releases.

 

Here are the reasons:

1. CORBA throughput for passing a structure is approximately 30% to 50% of the throughput that can be achieved using a low level message passing interface on top of TCP/IP. This is mostly attributable to marshalling and de-marshalling of the structure and excessive copying of the data.
2. CORBA latency is about 2X the latency of a low level message passing API. Major contributors are chaining of virtual function calls and excessive copying. As networks and protocol stacks get more efficient, the overhead in CORBA becomes more significant.
3. CORBA uses synchronous message invocation. In other words, the calling thread blocks until a reply is returned. This impacts the scalability because of the requirement to instantiate a large number of threads in a client to achieve a meaningful level of concurrency (i.e. several thousand outstanding requests).
4. CORBA provides no support for high availability. In particular, if a server fails, the state of any client connections will be lost. There is no facility to automatically rebind a client to a new server in the presence of such a failure. In addition, there is no support in CORBA to guarantee correct behavior in the presence of network partitioning.

The primary advantage of CORBA is the fact that it is a widely accepted standard with a lot of tools available. In addition, it provides a very high level interface that makes it simple for a programmer to create a distributed object. Unfortunately, most people seem to believe that just because something is a standard it must be the "right" thing to use.

If ease of use, portability, and industry acceptance is the primary concern, CORBA is the way to go. If performance and high availability are the primary criteria then CORBA is not the way to go.

Keep in mind that it is entirely possible that CORBA might be appropriate as an external interface to our system. In other words, it might make sense to provide a CORBA wrapper around the front-end API.