Newsreel
Products & Services
Web Watch
Software Update Resource Directory
Events Diary
Articles
The Magazine
Subscribe
Contact Us
Advertisers
TechEd reports
Exhibitors
Fun stuff |

Inside Babylon and COMTI
July 9 - Kay Ewbank interviews Tad Parker,
midrange marketing manager for Microsoft.
Tad: Most people are fairly familiar with SNA as a gateway product, though they probably don't realise how much we've added to the facilities. Babylon is going to be released as a new product, with lots of enhancements for data integration and transactional integration.
As a data provider, I go out to DB/2 on an AS/400 and I request a data set, and manipulate that data set in Excel. In the Babylon timeframe, we're going to act as a server for other requesters. For example, AS/400 can now query SQL Server and pull down the data set, so we enable the bi-directionality of the data interoperability, and we do the same thing at the transaction level.
AS/400s and mainframes are going to be around for an awfully long time. The important thing is that our customers view them as long term, strategic, so if we're going to be a good participating enterprise player we need to understand and support those long term strategic goals.
The other message we want to convey is, if you look at a lot of application integration technology,
say for example DRDA Server, we're going to make SQL Server look like a DRDA server. If I'm using DRDA to remotely query DB/2, SQL Server looks like a DB/2 data source.
Kay: There are a lot of other companies out there with technology that already does this.
Tad: Yes, but the thing that we do that's unique is that we provide people with a toolbox. Instead of trying to force people to use a hammer for everything - screwdrivers, chisels,
whatever - we give them a whole range of tools.
For example, in the data arena, I still have the traditional requester model through OLE DB, so I can go out and request information. Then I can be a DRDA server, so if I'm writing to a distributed database application, I can query it that way.
We're enabling heterogeneous replication, both to and from, so if I want to be able to replicate from DB/2, I can do it at the data level. We provide transactional integration via our COMTI model, and we even support distributed two phase commit via our distributed transaction co-ordinator.
We support messaging, so if customers want to bridge between MSMQ and MQSeries, we'll do that. We're also supporting XML schema interfaces, so someone can send us an XML document that maps to a CICS transaction.
Kay: You've run several sessions on COMTI. Tell us more about it.
Tad: Basically, what COMTI does is to provide a COM interface to CICS transactions. So in
Visual Basic, for example, you could go out and initiate a CICS or IMS transaction without the need to learn CICS, and there's lots of code out there in the host that programmers want to be able to leverage. We've created an SDK for COMTI.
Kay: So how do you see it being used?
Tad: OK, I've got a great example. We have a product called a component
builder. It's a Cobol wizard - and that's probably the only time you'll see those two words
together! It takes your Cobol code, identifies the data field, and creates a type library that you simply drop into MTS. So in VB, it's just another COM
object: they need know nothing about CICS, or what's going on on the back end. What the VB person would see at the end would be:
'invoke this COM object; pass it these parameters.'
We have customers who, once they have this COM object, build Web applications with ASP pages that invoke CICS transactions with full transactional integrity. So the thing we want developers to realise is that there's a lot of mainframe apps out there, and by using the components we're providing, and the facilities in Babylon, you can work on applications using modern facilities such as COM objects, and provide familiar interfaces in Web browsers, or using Visual Studio.
|
|