|
Standards based software development & services
|
 |
 |  | Find |
|
Abstract
|
No abstract was provided for this paper.
|
Contents
|
About DataChannel
DataChannel was incorporated in 1996. At the time of this writing it
employs about 180 people and it is still growing. While originally a purely
software-oriented company, it had to realize very early on that the world
is not a shrink-wrap one and that to solve customer problems, one has to augment
software with Professional Services staff which can successfully install and
deploy solutions, based not only on in-house products, but in combination
with third party software and custom code development.
This understanding ultimately lead to a merger with one of the leading
Professional Services firm of our industry - Isogen. Isogen brought to DataChannel
their very unique talent and philosophy of solving customer problems by using
international standards, including ISO, W3C, IETF and OASIS.
DataChannel was one of the first companies to make the strategic decision
to use XML - and related standards - to build better software and to solve
customer problems. The experiences of our endeavour is what I want to address
over the course of the next few sections.
Previous
Table of Contents
Standards based software development
The current shipping version of DataChannel's core product - the DataChannel
Server 4.0 - is an XML-based Enterprise Portal. A lot of work on the architectural
level went into making sure that wherever possible and sensible, open standards
should be used rather than proprietary inventions (our own or somebody else's).
Going beyond standards
While architecting the DataChannel server 4.0, we knew we needed a high
performance parser and stylesheet engine to drive the core of our product.
At that time, we could not find any parser available which would satisfy our
requirements with regards to speed and platform (Java). Thus, we decided to
build a parser and stylesheet engine ourselves. We engaged in a co-development
relationship with Microsoft to implement a Java-based counterpart to their
XML and XSL engine.
Developing a full-blown XML/XSL combo is a great learning experience.
It also has the advantage of giving us the opportunity to do certain optimization
necessary for the product right at the source level. However, it turns out
to be an enormous resource drain as well. While it was the right thing for
us to do when we started the project we finally decided that we will let tools-vendors
take care of tools.
Lesson learned : Unless you are in the tools business, don't
develop tools. Standardized interfaces to required components provide easy
integration and interchangeability of components.
While conformance to standards has always been a target for us, sometimes
we had to go beyond what a particular specification prescribed. The reason
for that was usually the requirements of both our developers which already
were working on our server product as well as general desiderata from outside
sources. Sometimes it was convenience functions, sometimes additions in feature
and functionality required by the product development team.
Lesson learned : As a development company sometimes you are
tempted/required to go beyond standards.
For instance, we implemented the XML Data Reduced (XDR) specification,
a first attempt at providing a next generation schema language. While this
was not a W3C standard we felt it was worthwhile to present to our customers
a technology outlook and enable early experimentation.
Lesson learned : Make sure to a.) mark clearly where you
go beyond standards and don't create the impression it is a standard and b.)
prepare both internal and external customers that certain code changes and
updates may be necessary if they want to move towards pure standards conformance.
Working with pre-standard specifications
Already in the release 3.2 of our server, one could return the relevant
portal metadata in XML format and apply XSL based stylesheets to create output
from that. However, then it was still a special case and not the bases for
the product. For the release 4.0 the decision was made to make XML based content/metacontent
the norm and to use XSL to create the user interface.
We were developing the XSL components when XSL itself was still very
much in fluctuation. Constant changes in the target specification made it
very hard to always catch up with the latest specification and to keep both
internal users and customers happy. Naturally you end up with a situation
in which some forces, trying to slow down the speed in which you introduce
new features and functionality (which are often not compatible with the existing
code-base), start to compete with those who want conformance to the latest
draft at the moment a specification is out.
When product development started, XSL was still far away from standardization
but we had to move forward and start our implementation, based on a draft
version, regardless. The only other option would have been to fall back on
some proprietary approach and possibly end up re-inventing the wheel.
Our next product release will be based upon the Apache.org XML parser
and XSL stylesheet engine (Xerces and Xalan) which are based on XSL-T. Now,
of course, non of the stylesheets developed for the old XSL is useful anymore.
Almost all the stylesheets have to be re-done in order to support XSL-T.
The DataChannel server uses the DOM - the Document Object Model - to
provide an abstraction layer between the actual datasource the product works
with and the application code a developer works with. Our experience with
the DOM is pretty much the same as with XML and XSL.
Lesson learned : Be willing to pay the price as an early
implementor.
It can really pay off ...
While reading the preceding paragraphs can show you how hard the life
of an early technology adaptor is, I hope the next paragraphs will be able
to shed a slightly different light on the subject matter.
WebDAV experience
Collaborative work on document across the Internet is one of the big
features of an Enterprise Information Portal. Instead of developing our own
approach and protocol, we made the decision to re-use existing research in
that area.
WebDAV - The Web Distributed Authoring and Versioning
Protocol deemed to be the right tool for the job. In the case of WebDAV we
were lucky, IBM already offered a WebDAV module (DAV4J) which turned out to
be very suitable for our implementation. Integration into our own modules
turned out to be fairly straight-forward and we certainly saved enormous time
by not having to invent and implement it ourselves.
Lesson learned : Reduce development time by licensing commodity
functionality for certain standards
One of the most important features of an Enterprise Information Portal
is that it allows our users to manage access controls lists to data resources.
In other words, who is allowed to see what. Developing a model for the management
of these permission can be tedious and is error prone. Instead, by following
the approach of an existing standard, such as WebDAV, we could rely on the
wisdom of numerous very intelligent people who have spend many months to think
through all the complexity of the problem at hand.
Lesson learned : Standards contain huge amounts of intellectual
property which can be reused.
Today we are in the fortunate situation that a number of software vendors
do already provide solutions that offer WebDAV compliant interfaces. Some
examples:
Microsoft Office 2000 : This popular suite of office productivity software
is WebDAV compliant. Thus, one can directly save from within, say Word, to
our WebDAV compliant server.
Microsoft Internet Explorer 5.0 : Webfolders use WebDAV to communicate
with a server application. This makes Webfolders a client application which
allows you to navigate and operate a portal.
Other solutions such as Excosoft's editor have not been tested for integration
but should plug into this solutions package just as well all other WebDAV-enabled
solutions. Granted, interoperability is not yet 100% across all WebDAV implementations,
but things are progressing.
Lesson learned : Open standards enable (almost) free integration
points for third party software.
Content re-use
One of the best advertised reasons for using XML is : Separation of
content from display. While this is XML 101, it deserves a special mention
here, as all too often people only mean data and documents when they speak
about this. Our decision to separate content from display (from programming
logic) in our software itself paid off big time.
Not only does this give us 100% control over the look and feel of our
user interface, but it also allows us to deliver content to devices we did
not even anticipate when we started developing the architecture of the product.
While certainly non browser-based devices were always on our radar screen,
we did not specifically plan for them. However, as we saw the emergence of
the market for wireless devices, it was easy for us to develop stylesheets
to convert the content of our user interfaces to WML and HDML as opposed to
only fancy (d)HTML.
Lesson learned : Separation of content from display not only
works for data and documents but also for user interfaces.
Even more payoff in the future
Adherence to standards requires often a higher investment upfront whereas
the returns on this investment only become visible over time. I believe we
have only seen some of the benefits of standards compliance so far.
Registries and repositories
When developing Enterprise Information Portals, we don't always know
beforehand what schema is being used for XML information inside a company
or between companies. It is also very hard to anticipate what schemas will
be predominant a year after a customer purchased our product. How can you
know what stylesheets you need to develop ?
As long as the schema is a cross-industry and standardized one, we
likely will also see standardized stylesheets for such schemas. These stylesheets
can also be stored in a registry and repository and retrieved as a "default"
style in case no specific in-house stylesheet is present.
Standards and Professional Service
Software development using open standards is only part of DataChannel's
business. Also our Professional Services group, especially them, are experts
in using non-proprietary approaches to solving customer problems.
ISO vs. W3C ?
While for a long time there seemed to be a chasm between the "old school"
of ISO/ANSI/IEC-driven standards, such as SGML, DSSSL, HyTime and Topic Maps,
and "new age" W3C and IETF-driven standards such XML, XSL, HTML and WebDAV,
we have come to the conclusion that this is a silly idea.
In reality many customers prefer the usage of ISO controlled standards
as they expect longevity and stability. ISO standards also come with the promise
of being less prone to be influenced by one single vendor or small group of
vendors. Sometimes corporate policies dictate the use of ISO approaches. Also,
as many of you may well be aware of, lots of our current XML standards draw
heavily from ISO ideas, often applying the general 80/20 rules and adding
ease of use and ease of implementation considerations. Still, some of the
concepts found there are very necessary to solve hard and complex customer
problems and are well proven approaches.
As web-technologies start to be combined with document/content management
solutions we also see more and more connection points between the typically
heavy-lifting oriented ISO based solutions and their Web delivery counterparts.
Integrating those two is less of a problem than it often appears.
Lesson learned : "Old" school ISO and "new school" W3C go
well together
Cost related
The use of standards reduce your overall systems costs. One of the typical
tasks of our professional services group is to integrate systems of various
vendors into an overall architecture which solves a particular customer problem.
A standards-based approach has proven to be a big cost-saving factor. Imagine
an - all to common - scenario in which systems without any standards-based
interfaces and data formats have to be connected. Mappings between different
document types become necessary, the development of which can be costly and
often hard to maintain.
Similar to the way the standardization of components like screws and
bolts fueled the industrial revolution, bringing down the costs of complex
machinery and enabling engineers to focus on more solution-oriented aspects,
it will have the same benefits for our information revolution.
Lesson learned : Use of standards helps customers save money.
Vendor dependency
Being exposed to proprietary data formats, one inevitably gets more
and more locked into the solutions of a particular vendor and that in turn
limits a free choice of application software and ultimately lets the vendor
dictate the price and introduces unnecessary risks to the system (what if
the vendor ceases to exist?).
Lesson learned : Proprietary approaches put the longetivity
of your system at risk.
Implementing the backbone
DataChannel, as well as many other vendors and organizations, is trying
to convince the IT community of today, that XML is the only way to manage
information across the enterprise and between enterprises. We, DataChannel,
suggest it in a form called the "XML backbone". It is the vision of the XML
backbone to provide a unified abstraction layer across all the systems of
a company. A crucial element in this puzzle is providing connectors to the
legacy systems which export (or even better, export and import) XML based
data. Whereas some of the connectors we build ourselves, we also have established
various partnerships to get others. However, at the end of the day, this is
a problem which only the entire vendor community can solve in an orchestrated
fashion. We need to work together to identify common schemes for integrating
legacy systems into XML in a standardized, uniform fashion.
We demand : Open standards-based XML connectivity for all
(legacy) data sources.
Almost every single industry vertical has already started to work on
schemas, trying to address the particular requriements of their environment.
However, all the often we see more than one group of people creating multiple
schemas which are sometimes overlapping, sometimes contradict each other.
For our customers this creates a very uncertain environment and may even delay
XML related projects, because of the fear of customers that they may be left
with schemas which nobody really supports in the long run.
We demand : Schema developing parties need to
work together towards convergence not only in their own industry but also
across industries.
Summary
Working with standards, from the perspective of a vendor is sometimes
hard and costly, however, it ultimately pays off - for yourself as well as
your customer.