It was fun to see the announcement today by SCO
of the SCOx Web Services Substrate. As the Solutions Architect
and later Chief Technologist at SCO I was central to the design and
architecture of the product. I worked with an incredible team,
led by Bruce Grant, in solidifying the concepts and implementing the
code. We were able to get the product out the door just before I
left SCO.
I was really surprised in one way that this particular press release
seems to give so much credit to Ericom. They are a key partner,
with an incredible product, however they are a very small part of the
overall “substrate” idea.
Our product actually comes from a larger idea that I called the
Biologically Inspired Application Substrate – BIAS. I presented
this to the public for the first time last year at SCO’s Forum event
that was held in Las Vegas. In my keynote and presentations, I
spoke about a substrate that consists of a core set of “substrate
services” that enable the creation and execution of distributed
components across a diverse set of platforms. Think of this as an
alternative to “grids” and other forms of distributed processing.
To create this environment, we first started by creating a set of
“encapsulators”. The first of these were the “Host Encapsulator”
(based on the Ericom technology) and the SQL Encapsulator (developed at
Vultus and bought by SCO). These encapsulators provide solutions
for exposing services as SOAP web services. The Host Encapsulator
can transform “green-screen” application interaction as a set of SOAP
web services. The SQL Encapsulator can transform a simple set of
SQL CRUD (create, read, update, delete) operations into SOAP web
services. Both are extremely simple to use and require little
real programming expertise.
Another core component of this release of the SCOx Web Services
Substrate is the Web Application Manager – WAM. This was a cool
little web application that manages the configuration files of Apache
and Tomcat to automate the deployment and configuration of the SOAP web
services that you create with the Encapsulators. Both
Encapsulators create .war files that are ready to be deployed under
Tomcat. The WAM allows you to upload the .war to your server
through a browser interface, and then make some simple selections to
chose to deploy it non-SSL or SSL, and the path that you want it
accessed through. A user or integrator no longer has to know all
of the complex entries in the various configuration files to do this …
What was not announced in this press release was any effort to complete
the broader vision of the BIAS. This included the UDDI directory
components, and the other components that further automate the
BIAS. Our intention was to create an alternative way to create,
deploy, and manage applications that was completely independent of
language, operating system, and hardware.
In any case … it’s fun to see the initial uptake by the market of
what we did get completed. I would have enjoyed taking this
project a lot further!