|
The slogan for enterprise application integration (EAI) projects ought to be: “The difficult we do immediately, the impossible takes a little longer.” Unfortunately, all too many application integration projects turn out to be more than difficult and take more than a little longer—while chewing up more resources than expected. Despite the difficulties, we continue to launch integration projects because the pressure to make applications work together is intense. This includes the integration of applications required by acquisitions and mergers, the increasing use of online business-to-business trading (EDI, JIT, and so on), the need to provide information from integrated applications to better serve customers, and above all the competitive race to integrate company applications into a whole range of e-commerce activity.
The need for enterprise application integration is greater than ever. A lot of application integration is still done the old-fashioned way, with batch file transfers under manual control. Often as not, teams of programmers write thousands of lines of code to make the integration dynamic or interactive. These handcrafted approaches, while still effective, are expensive and not efficient enough given the increasing demand for EAI. However, the last few years have brought several important technologies adapted for EAI: object orientation, application servers, and now lightweight directory access protocol (LDAP) and extensible markup language (XML). Many companies, including those specializing in EAI, are using these technologies to solve major problems such as data exchange standardization, security verification, and application code sharing. EAI is becoming more possible, if not altogether easier. Even so, there is no silver bullet for EAI. Application integration has too many variations for one technology to solve. Each of the new technologies brings something different to the table, which makes it tough to evaluate solutions for a specific EAI project. Which technology is important and useful in a given situation?
In this article, I’ll focus on two of the newest technologies, LDAP and XML, and suggest a general approach for evaluating them. The enterprise manager doesn’t need to be an expert in these technologies; but it helps to know what they are, have a feel for what they can do, and watch developments with a sharp eye.
The Role of Key Technologies
There’s nothing the computer industry likes to do more than tout a new technology. It’s a “latest and greatest” world. However, experience (sometimes painful) suggests that not all technologies are worthwhile. It’s tempting to wait on anything new, and let the pioneers suffer the hardships. The problem is, these days the pioneers are just as likely to annex your business. This adage may be especially true for EAI because the goal is (usually) to improve business and become more competitive.
Few technologies are developed specifically for EAI, so when a vendor starts making claims, it’s important to look behind the hype and ask what it means. More to the point, you want to know what it will do for your EAI projects.
Features drawing on a new technology are usually targeted at one or more of these types of applications: e-commerce, legacy systems, business-to-business apps (for electronic data interchange, for example), and intranets or LANs. Within these broad types of application integration, companies will use new technology to solve problems and make improvements in areas such as:
•Differences in data definitions among applications
•Complexity of the programming environment
•Difficulties with sharing code among applications
•Sequencing of data and processing
•Security.
You can hope vendors will do a good job of explaining the features and benefits of a new technology, but that won’t always be the case. You may have to interpret the capability of a technology, measure that against the vendor’s implementation, and fit your evaluation to your needs. If the technology touches hot buttons in your projects, then it’s time to take notice.
If it sounds to you like there’s a fair amount of study and research involved, you’re correct. Fortunately, we don’t get a-new-technology-a-day (yet), although changes and variations are coming more quickly than ever, especially around the Internet. As you may have noticed, most of the new technologies are Internet-oriented. This fact highlights how important the Internet—or more accurately, a TCP/IP network—is becoming for EAI.
EAI and OOP
If one thing distinguishes enterprise application integration, it is the attempt to link multiple applications, often on heterogeneous platforms. That implies not one or an occasional EAI project, but a series of projects. Obviously, if you do many EAI projects, it would be more efficient if you could reuse designs, procedures, code, and data. This reuse has always been possible, but until object-oriented programming (OOP) and the object model of application development, was very difficult to do. As a technology, object orientation didn’t automatically make all EAI projects reusable, but it does enable it; in fact, it encourages it. The shift to a programming philosophy of shared components and the development environments created around it have made a big difference in the ability to approach EAI as an architecture of reusable elements.
I bring up the role of object orientation because of its success. These days, it’s difficult to find a software development environment (in or out of EAI) that isn’t based on it. In the last couple of years, the role of OOP has been almost completely cemented in place by Java, at least around the Internet and intranets. Even so, I suspect many organizations take object orientation for granted and haven’t fully extended object reusability to EAI projects. No technology, not even one that’s been around a while and has become more or less fully accepted, fulfills its potential without somebody to champion and exploit it.
EAI and LDAP
Some technologies are ready before their time; LDAP is an example. In brief, LDAP is a solution to the problem posed by environments that support more than one directory service. Several years ago, when LDAP was introduced, most corporations were just beginning to use the directory services tied to their operating system platforms. With Novell NetWare Directory Service (NDS), Sun (Netscape) Directory Service, and now Microsoft Active Directory, it’s becoming more likely that enterprise applications will be built using directory services as the repository of information about company resources such as employees, computers, data, and software. Chances are also good that most enterprises will have more than one directory service, which makes access to multiple services—most likely through LDAP —increasingly important for EAI.
An example of where LDAP may come into play for EAI is the issue of rights; more specifically, who has the rights to access or operate the integrated software. Even within a single company, it’s obviously important to maintain security and control among applications. (You’d hardly want the folks in shipping to access the inventory accounting without control.) The problem with access to rights and other forms of security validation for applications is that it must be dynamic—people come and go; they change jobs and security clearances. While managing rights is a responsibility of the operating system, the directory service is the place to find rights information for applications. LDAP-enabled directory services, which currently include all the major players, provide access to rights information across platforms.
LDAP is a derivative technology, extracted from the more complex and heavy-duty ISO/ITU X.500 global directory system. X.500 was too big and cumbersome to use for the Internet and the desktop computing environment. So the University of Michigan developed a “lightweight” specification that uses fewer resources (memory and processor time) and is less complex to implement. LDAP is in its third version (LDAPv3) and is now under the auspices of the World Wide Web Consortium (W3C). The need for a less resource-hungry protocol is no longer terribly valid, but LDAP’s relative simplicity, standardization, and affinity to the Internet have maintained it as the first choice for accessing multiple directory services.
Based on what I’ve described, LDAP has several characteristics that signify it as a technology to watch:
•It solves specific problems for EAI projects.
•It is accepted as a standard.
•Its use is widespread (or at least used by most major players).
•There will be a distinctive and increasing need for it.
A good technology loves company—lots of companies—because that usually indicates the technology is sufficiently broad to support different implementations. While access to network directories particularly for security purposes seems to be the thrust of LDAP for EAI, it’s not the only direction. A good case in point is the direction taken by the soon-to-be released (at press time) RadiantOne from a startup company called Radiant Logic Inc. Using what the company calls VDAP technology—“V” for virtual—RadiantOne translates the structure (schema) of a relational database into an LDAP structure and publishes that structure as a set of URLs accessible over the Web. This approach provides a way for users to navigate the complexities of a relational system—for example, to let customers access their invoices online. (See my product review of RadiantOne, “Directorial Debut,” on page 54.)
As is often the case with enterprise computing, if you need scalability and horsepower for directory services—especially across multiple platforms—the LDAP-enabled operating system directory services might not be enough. You might want to consider Oracle Internet Directory (OID) instead. This LDAP-compliant server provides a scalable, cross-platform directory structure. It’s built on Oracle8i and Oracle directory management tools, which should give it a directory-processing capability few can match. Oracle has also announced a joint development project with Siemens Information and Communications Networks to link OID with Siemens’ DirXmetahub. The goal is to create a metadirectory (fancy word for a directory that holds all kinds of information) to enable global e-commerce. An interesting wrinkle to this new product will be support for XML (in the form of directory services markup language, or DSML) as the medium to exchange directory information stored in the LDAP server.
EAI and XML
A chance exists that the XML tail will wag the Web dog. XML got started because HTML is good for doing Web-page layouts and lousy at handling data. In a fashion not unlike the genesis of LDAP, XML was boiled out of a much larger markup system, standard generalized markup language (SGML), in order to work on the Internet. Version 1 of XML was a system of tags to identify data and its properties so that Web servers and other applications could properly handle and display it.
This goal is a good one, but there was a bonus. In order to make XML work with many kinds of databases and many kinds of data, it had to establish protocols for defining data—protocols that are platform- and database-independent. These protocols, called document type definitions (DTDs), have become an excellent approach to industry-specific data definition—a core problem in EDI and across e-business.
Because of the problems it promised to solve, XML came out of the technology chute (freshly minted by a W3C committee) already tagged as one of the most important new technologies since, well, HTML. But unsurprisingly, the need for data interchange within Internet applications is often much greater than simply displaying Web pages. What XML seems to offer is a way to standardize that interchange (on or off the Internet) without losing the individuality of the data.
I use the word “seems” because as XML’s horizons have broadened, so have the number of W3C committees and technology offshoots. These offshoots include Xlink and Xpointer, which attempt to describe ways to link documents; extensible style language (XSL), which describes how XML may be rendered in Web-page style sheets; the document object model (DOM) to standardize the content and updating of HTML and XML documents; XML namespaces, a method designed to head off problems with data having the same element name; and XML schemas to help developers define their own XML-based formats. There are more, but this list should convey the idea that this particular technology is difficult to follow.
You can add to that complexity the products and specifications from vendors. The best example is Microsoft, which did more than get on the XML bandwagon; it became a lead horse. The BizTalk framework offered by Microsoft includes design specifications for implementing business documents using XML schemas and XML tags that provide applications with document handling and routing information. The framework is intended to help speed up the integration of applications within a single organization or among trading partners over the Internet.
I can tell you right now that XML is going to become part of many EAI approaches, probably within two years. It fits all the criteria: It solves specific problems. It is accepted as a standard. Its use is widespread. There is a distinctive and increasing need for what it does. All true, but XML is one technology that must be watched carefully for fragmentation and product-specific implementation. It’s also not a solution for everything EAI.
In other words, XML is a “barge” approach to trading data. It’s relatively slow and cumbersome, but it can carry a load and doesn’t require a lot of fancy equipment. It works well to move data between two systems that know little or nothing about each other. Alternatively, a hydrofoil approach (as with internal applications and some EDI systems) can vastly outperform XML if the parameters of exchange are well known, relatively fixed, and the system can be optimized.
Ultimately, the value of XML to EAI may not be its miraculous powers of integration, but the fact that a lot of software companies, consultants, writers, and developers think it has great powers and will provide the world with a flood of products and support material. You may find that while some proprietary solution might actually be better for a specific EAI project, it may be much easier to find somebody who can actually do an XML project. That may be the last, but not the least criterion for a new technology.
And?
It’s tempting to try to formulate a pithy bottom line, but monitoring new technology is not like studying a P&L. OOP, LDAP, XML—besides being an alphabet soup—are huge technologies. Watching any one of them can be a career (no doubt why so many acronyms seem to spell consultants). EAI has arrived at a position where several technologies have something to offer, including overlap. Now what counts is the implementation: Who will step up and grab LDAP or XML (or LDAP and XML) and turn these technologies into useful, reliable products?
I’m not suggesting that you turn away from watching the standards committees; the eager beavers at W3C will be gnawing away XML, LDAP, and other related standards for quite some time, and the outcomes may be important. Rather, it’s time to focus on products that use these standards and measure what they offer against your EAI needs. The trick, as always, is to balance the new opportunities to do things you could not do well before against the risks involved. However, it doesn’t hurt the old competitive edge to routinely do the difficult and occasionally pull off the impossible.
Nelson King (nelsonking@earthlink.net) is a frequent contributor to Intelligent Enterprise. He has written nine books on database application programming and spends much of his time in the trenches of enterprise software development.
RESOURCESBizTalk: www.biztalk.org Oracle Internet Directory:www.oracle.com/database/oid Radiant Logic: www.radiantlogic.com University of Michigan LDAP page:www.umich.edu/~dirsvcs/ldap/#overview XML namespaces recommendation:www.w3.org/TR/REC-xml-names |
|
|
|
|
|