May 13

Written by: Robert Houben, CTO
5/13/2010 12:56 PM 

First There Was Liberty ODBC

Our first corporate identity was as a company called Liberty Software, Inc.  Several of our principles were involved in the early SQL Access Group efforts and provided the people who wrote Microsoft's first ODBC drivers (the Simba drivers).  Because of our close involvement with Microsoft in the development of ODBC, we were the first company outside of Microsoft to release an ODBC driver.

ODBC required ANSI SQL-92 conformance, so we wrote a relational engine that provided mathematically correct SQL results against mapped views of your MultiValue data.  We were able to provide inline data cleansing, multi-file reads and lots of other functionality.

One of the things we did was to enable a user to write a subroutine that would define metadata for a result set and then return data from MV/BASIC.

Web Publisher for PICK

When Netscape Server first released their Netscape API (NSAPI) we started work on an NSAPI extension that would call our ODBC driver, access MV/BASIC subroutines and allow the return value to be HTML.  This was a good first step, although primitive by today's standards, and we had customers who built very rich and powerful websites, some of which processed millions of calls to their MV POS system per day.

We quickly followed with an ISAPI based solution when Microsoft published the ISAPI interface. This leveraged the same back-end functionality. 

These two products collectively became our two editions of the Web Publisher for PICK product, still under the Liberty label.

Best Practices Intruded

Two things began to affect the then-rapidly-emerging market for our product.  The first one was that the market quickly came up with the 2-tier, then N-tier approach, and then started describing best practices. Having a database producing HTML, which was really GUI, was quickly becoming seen as the "wrong" approach.  Intelligent IT departments sought a separation of 3 things:  Presentation, Business Logic, and Data Services.  Furthermore, over time, the Data Services layer (originally known as Data Access) became two parts: Data Services and Data Access.

Performance of Relational vs. Non-FNF

The other issue that we were running into was the development of new "standards" for accessing data from Microsoft.  First, with OLE DB, then with ADO.NET, Microsoft, who had always admitted that over 80% of the business data in the world was not in a relational format, relaxed the requirements for ANSI SQL-92 syntax in their standards.

Enforcing full ANSI SQL-92 syntax at a core conformance level on a non-FNF MultiValue database had a performance penalty.  Allowing multiple statements per connection (multithreading) behavior on MultiValue's single-threaded environment also carried a penalty.  Both the OLE DB and ADO.NET standards allowed us to work directly against the true MultiValue data, offloading the processing of this data to the client system, as opposed to the shared resource of the often resource-constrained MultiValue system.

Direct Data Access Server and OLE DB

With these issues weighing on us, we went away and did some research and planning, and the result was that we developed a whole new Data Access Server (DAS), called the Direct DAS. 

The Direct DAS was designed to allow you to access mapped views of your PICK file.  The metadata defining the mapping would be sent to the client followed by the data.  The client would then parse out the data and process it as needed. 

You could also call MV/BASIC programs, execute TCL commands and capture the results, even stack data to them, all without having to do any mapping. 

This environment provided very direct access to your MultiValued data, from a very data-centric MulitValue-programmer-friendly perspective.

Results when returned could come back as raw results, or as mapped data. In either case, it came back as a RecordSet.  If there were MultiValues, they came back as a hierarchical recordset.

In addition to providing excellent performance and scalability, this allowed the user to build a Data Access Layer, in accordance with industry best practices, and to do the access using industry standards.

Java Data Adapter

Right about this time, one of our biggest customers was looking to do data access for some critical processes of theirs, and when they saw what we had done with the OLE DB provider, they wanted the same functionality on their SGI Irix systems running Universe 5.  Because we were determined to stay with standards, but there was no Java-based standard for returning multivalued data, we decided to provide the Java Data Adapter (JDA).

This product leveraged the power of the Direct DAS, but used Java to access it.  The data that came back could be returned in XML format, which allowed us to return MultiValues and SubValues, but was also an emerging industry standard.

You could also do an accessor-based approach to getting the raw data that avoided the overhead of XML processing.

And then there was ADO.NET

Then, with the advent of Microsoft's .NET platform, a new standard for data access emerged.  ADO.NET did not support the old ADO Recordset with it's Hierarchical Recordset structure that supported MultiValues and SubValues, but it had a new DataSet structure that allowed us to create a table for the single values, plus one for each MultiValued or SubValued related set.  These tables were all interlinked in a way the allowed you to apply views and filtering to link them.  These views and filters could be used with object binding.

In many cases a strongly typed dataset based on the data returned by our ADO.NET provider was a good Data Access Layer.  In other cases, it made sense to wrap it further in custom code, or customize the generated strongly typed dataset.

Some Additional Changes

Over the years, we have built Reporting Services providers, mv2SQL for data warehouse or data mart creation, pooling layers, and other enhancements, products and features.  Reporting Services is a key part of Microsoft SharePoint 2010, and we fully support it as a way to access your MultiValue data.  You can also use mv2SQL from within SSIS to move your MultiValue data into a SQL Server data mart to enable web dashboards.

We've provided some specialized features in the Direct DAS to enable using LIST/SORT type syntax to produce data without having to do any mapping.  We've enhanced performance with block mode transfer and other features.

And That Brings us to Today

Today, FusionWare's Direct Product line provides you with the richest product line for leveraging your MultiValue data in a web environment.  We support web development using industry best practices and standards for Microsoft Visual Studio from version 6 to 2010, NetBeans, Oracle JDeveloper, Sun Java Studio Creator, Cold Fusion and many more. 

FusionWare Direct Product Family

The FusionWare Direct product family includes client providers that enable access to your MultiValue data from Java, .NET and Legacy COM/COM+ environments.

Client Platforms Supported

Client Platforms supported for .NET and COM clients include:

• Windows 2000, 2003 and 2008, 32 bit and 64 bit
• Windows XP, Vista and Windows 7, 32 bit and 64 bit

Client Platforms Supported for Java client include:

• Windows 2000, 2003 and 2008, 32 bit and 64 bit
• Windows XP, Vista and Windows 7, 32 bit and 64 bit
• IBM Platforms:
  • IBM i (AS/400)
  • System z (mainframe)
  • System p (AIX)
  • Certified "Ready for IBM Systems with Linux"
• Linux
• Unix
• and more...

MultiValue Platforms Supported

• Rocket (formerly IBM)
  • U2 (Universe and Unidata) including Universe back to version 5
  • PI Open
• Raining Data
  • D3
  • mvEnterprise
  • mvBase
• Northgate
  • Reality
  • Reality/X
• Temenos Group
  • jBase
• Ladybridge Systems (coming soon)
  • QM
  • Open QM
• Others (older or unsupported MultiValue Systems
  • UltPlus
  • Power95
  • and more...

Copyright ©2010 Robert Houben, CTO