|
We're entering the Third Age of the Internet,
according to Microsoft. We will no longer build first age static Web-sites. We will no
longer build second age sites that generate dynamic content from homogenous data systems.
Instead, we will program applications to speak directly to each other across the Internet.
We will program them to speak to each other despite their different operating systems,
their different protocols and their different programming environments. And building it
will be a mighty challenge.
Interoperability
Microsoft has been developing solutions for the cross-platform issues raised by Windows
ubiquity since it launched SNA server. But Redmond's emphasis on interoperability has
increased over the few months as it has turned up the burners under the two-year old
Windows DNA (Distributed Internet Applications) initiative. That's because WinDNA is more
than just a marketing concept to sell the BackOffice family of servers into an
increasingly networked world. It is also a reflection of the intimacy distributed
applications will share.Redmond's reasoning is simple: the more BackOffice products there
are out there, the more NT will be connected to Unix, to AS/400s and to IBM mainframes.
WinDNA and the coming of the Third Internet Age will also stoke demand from medium to
large enterprises looking for ways to hitch their Web-based e-commerce solutions to their
legacy databases; legacy databases that are already running on Unix, AS/400 and IBM
mainframes.
And they add up to a big market. Microsoft estimates that two million Unix servers,
300,000 AS/400s and 50,000 IBM mainframes currently host the databases that underlie so
many large corporate applications. It also recognises that few of them are likely to yield
up their data to a quick conversion to SQL Server 7.0. The economic and technical
arguments against it are too strong. While NT's threading is as good as most Unices
(provided you develop applications that use NT's APIs rather than standard Unix calls),
NT's relatively slow and unscalable NTFS file system is unlikely to impress the techies
who stalk database centres. Especially if those techies are being asked to open up very
large databases to the unpredictable loads associated with public e-commerce.
Instead Microsoft accepts that they're more likely to implement scheduled replication of
databases into Web-accessible data warehouses, then replicate them back after users have
carried out their transactions. That's an option that is, in itself, more likely to bring
Microsoft's Internet Information Server into direct contact with an enterprise’s
non-NT servers.
Customer demands
"Right now we're hearing that interoperability is just critical to our
customers," says vice president of Microsoft development Tod Neilson. The fact that
they already want to build links between applications running on heterogeneous operating
systems is already clear. A glance at Microsoft's directory of third party data
interoperability alliance partners (at
http://www.microsoft.com/sql/solutions/DataInteropSol.htm) shows 12 different companies
supplying OLE DB providers and ODBC drivers for connecting databases, tools for
simplifying replication, for carrying out application analysis and design and for
administering databases. The fact that it all becomes too costly for some is indicated by
the list of seven companies offering database migration tools. The arrival of the
networked application would almost certainly have meant much more business for those last
seven companies if Microsoft had restricted its heterogeneous programming efforts to
developing COM-CORBA bridges. Instead, it has realised that it must now invest heavily in
COM and OS interoperability.
Babylon – the Enterprise Interoperability Server
Babylon, (SNA 5.0 and COM combined) Microsoft's Enterprise Interoperability Server will
offer data integration with OLE DB providers and ODBC drivers. Microsoft sources at TechEd
‘99 said these features alone should simplify database connectivity. Data exchange
between SQL Server and IBM DB2, Oracle and Sybase databases will be ‘seamless’,
they said. If this happens, Babylon should make it as easy as it ever could be to enable
the kind of bi-directional replication across heterogeneous systems that database managers
will need to use if they are to hitch Web-enabled applications to Unix/ AS/400 / mainframe
databases.
So, what else does Babylon have to offer? Network and platform integration over direct
TCP/IP access or through an SNA gateway should bring peace of mind to anyone planning to
web-enable data that they traditionally made available through SNA Server. Babylon's
feature-set will include as-yet unspecified enhancements to SNA Server's terminal
access-style support for 3270 and 5250 and their TN3270 and TN5250 protocols.
This could be truly revolutionary - integration with COM Transaction Integrator and an
MSMQ-to-MQ Series bridge. For developers hampered by the poor Unix support for COM, this
promises to simplify building distributed applications. Bear in mind that most Unix
vendors do support COM; what they are unable to do is support it in a way that allows it
to scale without expensive hardware upgrades. It's also difficult to port VB and MTS-based
applications that companies may have already developed on to Unices. A recipe for bridging
an NT application to CORBA code running on Unix might involve having MTS components using
DCOM to talk to COM-wrapped CORBA objects on Unix. Alternatively, developers might have
MTS components talk to an object bridge on NT and have that system talk to an object
bridge on the Unix system. But there has to be an easier way.
The HTML and ASP database approach to building Web applications introduces the following
problems of integrated Internet application development:
1. Availability (Read: how long do users have to wait before you
deliver an error message?)
2. Exception handling (Read: is it sophisticated to deliver an error
message for each exception?)
3. Performance and scalability, (Read: both of the above)
4. The human element (Read: the problems IT staff create when
developing applications to deadline)
Problem solving
Babylon's aim is to help you overcome all of the above problems. Around 90 days after
Windows 2000 ships, Babylon should ship as part of the Back Office range. Microsoft claims
Babylon will help IT staff and developers integrate legacy applications where an HTML and
ASP solution would have crumpled under the strain. It would do it by allowing them to
exploit the benefits of XML, MSMQ and MTS.
Through bitter experience most of us recognise the four big problems outlined above. One
of them is the tendency to rewrite entire suites of legacy code because we think our new
code will be less buggy than the old. Another is that because we wrote the new code, we
think we'll be able to troubleshoot and fix our own bugs quicker than we could hunt down
and fix them in that old COBOL suite.
Babylon is designed to solve another problem that often prevails in an Internet world, how
to scale transactions with data sources when the only safe prediction we can make is that
application loads will be unpredictable. SNA gateways usually accept a limited number of
connections at one time. It's the nature of the Internet that the number of user
connections may be unpredictable. Related to the unpredictability of connection rates is a
problem that is fundamental to transaction processing across the Internet: inherently
unreliable TCP/IP connections - and how to secure transactions across them.
Most newly-built database-centric applications will also need synchronous connections or
connections that simulate synchronous connections to maintain the ability to submit to the
database and perform roll-back without disrupting valid entries made by other users.
Whether or not you've run your own Internet applications tests, you'll already have heard
of brave, groundbreaking Internet applications that squealed to a halt when they were
released to the public. For example, Hotmail when it was transferred to NT.
MSMQ and XML
However, we could get around these problems using MSMQ and XML. MSMQ will happily accept
thousands of requests and store them until it can connect to the data source application.
XML promises to bring order to data streams so that legacy applications can understand
them.
We can't do this at the moment because in its current form, MSMQ is MS product specific.
To get around that, Microsoft licensed the MSMQ-MQSeries Bridge (previously known as the
FalconMQ Bridge) from Level 8 Systems to interoperate with IBM's MQSeries.
Currently, the only vehicle for the MSMQ-MQSeries Bridge is SNA Server 4.0 SP2, which
lacks the ability to integrate with either COM, the Unix world, or to deliver the
scalability required by Internet applications. Babylon, however, will include SNA Server
5.0 as well as the MSMQ-MQSeries Bridge. The details of how it will do that remain a
mystery. Babylon was scheduled to go into beta by autumn but Microsoft has been
uncharacteristically quiet about its progress. That may well be because Babylon's
feature-set is inevitably tied up with Windows 2000 and its support for COM+. In the
meantime, details of how much Babylon will cost, its hardware requirements and its final
feature list will all emerge over the weeks leading up to Christmas, after the marketing
teams have turned Windows 2000 over to its users.
Even now though, it is obvious that Babylon promises to help you buffer those legacy
applications from customer-hungry (for which read ‘load-heavy’) and asynchronous
Internet front-ends, whatever system your legacy application runs on. Its ability to
interface any part of any legacy application with any Web client or thin client means that
true n-tier applications may at last be on the way.
For further information:
MS white paper on interoperability - http://www.microsoft.com/technet/interop/ndam/ndam.htm
Detail on interoperability for applications - http://www.microsoft.com/technet/interop/applications/
Third party SQL interoperability companies - http://www.microsoft.com/sql/solutions/DataInteropSol.htm
Interop is so challenging that a host of third party suppliers have
sprung up to service it:
Unix interoperability - http://www.microsoft.com/ntserver/nts/exec/overview/NTInterop/3_UNIX.asp
|
