by Russell Kohn
Chaparral Software & Consulting Services, Inc.
After years of hype about the technology, and much focus on the bits and the bytes, what are the real business imperatives that can be addressed, in the real world, with the "XML thing", where client organizations can make money, save money, and therefore be willing to pay money?
As the Office suite becomes more and more XML savvy, the possibilities for exchanging data between Office and FMP are staggering. Currently, without XML, such integration is what I refer to as "tightly coupled", meaning you need to set up (generally) a very specific series of ODBC connections, VBA code within documents etc. that are harder to build, deploy and maintain than what XML offers (though they can be very powerful and definitely still have a place). Applications that I can see now in this area include:
According to Microsoft: XML Web Services are units of code that allow programs written in different programming languages and on different platforms to communicate and share data through standard Internet protocalls such as, XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discover, and Integration (UDDI). (http://www.microsoft.com/net/business/it_pros.asp)
Given the momentum of the .NET initiative, I think we can count on there being lots of "web services" coming onto the market. What does this mean to us and our clients?
Since FMP6 can read and write XML, this will not be a problem. Existing and future FMP-based solutions will be able to communicate with these other systems.
Given the investment in XML by Microsoft, Oracle, and IBM in their database units, and predictions of XML storage in these database products reaching perhaps 25% of total application usage within the next few years, it is safe to assume that XML as a data type is indeed here to stay. (http://www.zapthink.com) More and more, we will see XML files, data streams, and sources coming from many different places.
For any given industry, we can expect there to probably be some competition between several providers of key data, and differences in the way they provide that data.
To the extent our clients want to use this industry specific data, wouldn't it be nice if we didn't need to rev our core FMP code every time a data source was added or format changed?
With XML support, we can build structures into FMP based solutions that anticipate multiple data sources. We'll need to modify an XSLT document to map that source to our way of handling the data internally, but that's it. Deployment across an entire user base is accomplished via an email with the XSLT attachment and a few words of instruction regarding where to put it on their server.
Clients can seamlessly see new data flowing into existing FMP systems without requiring a major conversion & import/export cycle.
Clients who publish data to others can similarly become a data publisher if they so desire, and possibly gain market share by the quality and consistency of their data.
|Copyright 2002 Chaparral Software & Consulting Services, Inc.|
EZxslt is a trademark of Chaparral Software & Consulting Services, Inc.
Filemaker Pro 6.0, FileMaker Server, FileMaker Developer, FileMaker Unlimited are trademarks of FileMaker, Inc.
Microsoft Word is a trademark of the Microsoft Corporation.