Another Cool Administrator Feature

This one courtesy of the Rocket development staff.

With Manage 2000 release 8.1 service pack 2 the webserver connector moves up to Rocket Web DE 5.3.0 Javascheduler.  This makes the service pack roll-up from service pack 1 a little bit more involved but not only results in a faster connection but a really cool administrator portal.

Going back through the administrator guide I got to wondering about this apiserver thing that I keep running into.  Is it a development API?  Is it a user interface?

Turns out it is both:

Admin API server - The new Admin API web server hosts a Web API and a web-based user interface, which you can use to control configuration and monitoring functions of the Java Scheduler. Enhanced monitoring and logging API improves tracing and supportability, accessible via a an HTTP-based API and UI. Prior to v5.3.0, these administrative functions were performed through an Eclipse-based interface and anchored into the U2 Web Designer. Now, you can easily update configuration, monitoring, and security preferences in Web DE via an open API and new web-based user interface.

Rocket Web DE 5.3.0 includes a fully functional mobile ready REST based user interface to the Javascheduler  console for administrators.  This is much more convenient than the snap-in to the Web DE eclipse environment.  Definitely worth investing in setting up and securing.

https://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew20/webde/v5.3.0/webde_installguide_v530.pdf

Page 15 for Windows, page 20 for UNIX.

In Defense of the Multi-Value Database

Reading Andrew E. Wade's chapter "Business Objects in Object Databases" of Andrew Carmichael's anthology of OO practitioners "Developing Business Objects" from 1997 I am struck by the parallels between the advantages of Object Oriented databases and Multi-Value databases over RDBMS for complex business modeling such as ERP systems.

RDBMSs provide a simple, flat, tabular view of all information. The user must map his application data structures, whatever they might be, into those tables. Other traditional database systems require similar mapping down to simple, flat records. The user must work at the level of only the table data structure and only a small set of simple operations (select,project,join). Now, if the application data structures is naturally simple and flat, and the application operations are also simple, this mapping is straightforward and not an issue. On the other hand, when the application structures and operations become complex, the RDMBS approach forces the user to deal with this directly. An ODBMS offers the ability to model an application in terms of objects, which may have any user-defined structure and any user-defined operations. Applications that require nested structures, dynamically varying sized structures, many-to-many relationships, and complex operations can map these directly to objects. Not only is the support far more efficient, far faster at run time, but the user may work at higher levels of abstraction. Instead of translating the application down to records and tuples with joins, the user can work directly with objects such as customers or manufacturing processes, and the natural, application-defined operations on these. The result is easier and faster for the developer and the end user. ...

When to Use an ODMS

... Second, if the application's information is complex and interconnected, an ODBMS can provide much better performance and ease of use. To contrast, if the information being modeled consists of simple, flat, fixed-length field, that fit nicely into tables, an RDMBS can be a fine fit. On the other hand, if the information contains complex structure, nested structures, dynamically varying sized structures, including images, audio, and video, all these can be represented directly as objects. Saving the need to translate not only eases the developer's load, but also eliminates the need to translate at run time, making it faster. To some users, the interconnections in their information model are even more important. In an RDBMS, such relationships are represented by creating secondary data structures, foreign keys. At run time, the system searches down two tables, comparing key values, until it discovers two that match.This search-and -compare process is called a join, an it's the weak point of relational technology. Even with the help of indices, it's slow, and the bigger the database, the slower it gets. In an ODBMS, there is no need to create and manage secondary data structures... Referential integrity, a difficult issue in traditional database systems, comes along automatically and easily. Moreover, the traversal is direct, with no need to search or compare, resulting in performance that is orders of magnitude faster. The more relationships, the more the application will benefit from an ODMBS.

Although to my way of thinking the most critical advantage of Multi-Value databases is their elasticity. They accomodate change. And change is the greatest challenge to software development and software field operations. One example of this is the ability to add domain specific vocabulary to a database in the field. The I-Descriptor feature in file dictionaries allows one (among other things) to describe how the system should retrieve a single foreign field. This is, effectively, a class definition for a field level join. Once defined the foreign sourced field may be used as if it were local for query and record selection purposes. Some users shy away from creating new custom dictionaries, but I see this as teaching the database how to be more useful to the users, how to be more functional in the users natural business vocabulary. Some argue that Multi-Value is dead. I hear this mostly in context of sales and marketing. But the absolute dominance of the healthcare sector by Intersystem's Cache and its predecessor MUMPS would seem to contradict this assertion. Critics will point out that Cache is not Multi-Value, but it most certainly is NOT first normal! In fact, one can argue that the Multi-Value database design is a subset of Cache's architecture. I would argue that the default Multi-Value Telnet based UI is the major problem for sales and marketing. Cache supports HTML as an immediate client protocol. This has been a conspicuously missing piece in U2 and other Multi-Value vendors offerings. While there are many ways to mix-in HTML client protocols such as UO, RBO, BlueFinity, or developing your own data components as we did on the Manage 2000 team, these all introduce tons of extra complexity. On most Multi-Value platforms there is no native MV Basic way to simply and directly code HTML UI's.

REST Web Services from UniBasic

In the midst of working up some labs for Perspectives I started thinking about REST web service access from UniBasic. The lab I happened to be working-up is on SOAP based RPC web service usage, for which we have a number of working examples and implemented projects.

But in creating services for Manage 2000 internal consumption I have all but abandoned SOAP RPC in favor of the far more elegant JSON REST model. I am usually working in ASP.NET and IE DOM client land, thankfully with the prototype.js library. So the question of the day was what would REST JSON access look like from UniBasic and what are the central issues in using it?

Well in addition to all the SOAPRequest support added with the UniBasic Extensions are a couple of simple little commands for retrieving the content from a URL. Now URLs often return HTML intended for human consumption and are not very easy to parse. The JSON REST model however returns very nice orderly string serializations.

With something as simple as:

CREATE.REQUEST.RTN.CODE = createRequest(URL:"?":QS,HTTP.METHOD,HTTP.REQUEST.HANDLE)

SUBMIT.REQUEST.RTN.CODE = submitRequest(HTTP.REQUEST.HANDLE,'','',HTTP.RESPONSE.HEADERS,HTTP.RESPONSE.DATA,HTTP.RESPONSE.STATUS)

you can get orderly responses like:

HTTP.RESPONSE.DATA = {'oValItem':{'FileName':'CM', 'TableNbr':'', 'ItemId':'1024

', 'NewItemId':'1024', 'Valid':'True', 'Display':'Sears Systems, Incorporated',

'ErrorFlag':'False', 'ErrorMsg':''}}

UniData does not yet include a JSON DOM to match the XML DOM of the UniBasic Extensions, but the parsing difficulties of JSON serializations are relatively minor. And if you need to directly access JSON REST services in the middle of UniBasic code this seems like nice direct approach.

The real stumbling blocks aren't coding difficulties, but security of your application server if you open up the HTTP or HTTPS ports for UniBasic to "see" services on the Internet. One answer to this is to go through a proxy server. This also points out one of the benefits of the architecture of Manage 2000 with its ASP.NET arm which may be used in a similar manner to delegate interaction with the messy world away from your closely guarded business database into a DMZ area.

7.2 Release and Looking Ahead

Entry for February 11, 2007

After 10 days of negatives temps, some days with -5 for a high, I am ready to be out of the deep freeze. Past -10 my car sleeps with a trouble light under the hood to make sure I can get the kids to school in the morning. Maybe time to add that block heater.

The 7.2 release is currently in Beta. Lots of positive feedback, as well as, bug reports and clean-up work.

We are currently conducting training presentations to helpline, custom code and consultants. Last week I covered PageViewFilters and other tools enhancements, as well as, the new web ProductConfigurator interperter for implementing CTO on the web.

I continue to scout out the direction ahead with Visual Studio 2005 and ASP.NET 2.0. The way looks rough but passable at the moment, though where we all end up is sure to be filled with complaints. There are some tools I can write to smooth the way, but there are significant short-comings in the VS2005 IDE. The VS team seems to have fixated on codeless access to SQL and forsaken all other paths. Everything is focused on stateless, first-normal data updates between flat UI components and the SQL database, or some other object which must be organized along the same CRUD lines in a first normal world. They do not appear to have made any accomodation for web base applications with rich hierarchical complex UI's. Apparently we are supposed to use winforms unless we are implementing an Amazon.com web site. There are web sites and then there are web applications. Microsoft appears to be pressuring the web application camp back to winforms.

In particular databinding UI from hierarchical datasets to webcontrols is just plain gone. They have drastically different models for winform data access as compared to web forms. They are pushing ObjectDataSource and SqlDataSource as codeless access to databases and great productivity enhancements. But these depend on new TableAdapters within the dataset to orchestrate flat table accesses back and forth to the DB. They are tightly coupling the UI to the DB.

For thoses of us with ACID processes based on hierarchical datasets there is no room to fit in. The idea that first normal database requirements are going to start driving UI design is just plain scary. It may be ultra productive for the person creating it, but it's going to be butt ugly for the poor soul who has to actually use such software.

On another front I am watching Orcas with amusement. They are so hyped about LINQ and the ability to hook up SQL query statements to gridview. Manage 2000 has been delivering web query capability for over 5 years which include embedded sub-tables and hyperlinking. Our queries can even be defined from a report generator UI. I predict that when LINQ gets to field everyone will discover there is still a lot of problems because they will often want a three dimensional query result and you can't get that from a first-normal database without a lot of effort.

The reign of quality fights for a hierarchical object oriented UI. The reign of quantity fights for simple flat table models. Who will win?