Browse DevX
Sign up for e-mail newsletters from DevX


Using XML Glue to Solve Big Integration Problems

You know that enterprise application integration is a big problem that has various possible solutions, including packaged applications, software adapters, and EDI. But none of those technologies has the flexibility of XML. Find out why IT has pinned all its hopes on XML and industry-specific XML extensions for enterprise data integration.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

he core asset of any company is its business data. In a typical company, business data is stored in many formats and across many systems and databases throughout the organization. Data related to one business object, such as a customer's contact or ordering information may reside in multiple locations and formats. The dispersed nature of a typical company's data forces applications to connect to many different systems to build a view of business information.

Recognizing this problem, business managers attempted to increase efficiency and use existing data more effectively through automation. This resulted in additional custom developed data stores and new data warehouses being installed over legacy ones.

The distributed nature of a business's data makes a streamlined access approach—and a single customer view, for example—nearly impossible. Any new development project must overcome the initial obstacle of obtaining the necessary business data.

Traditional Approaches
To solve the data exchange problem, IT departments began to experiment with ways to exchange data across their company and with partner companies. The solutions they found fell into three basic categories.

Packaged ApplicationsSome companies opted to use third-party packaged applications. Packaged applications often replaced dozens of applications within the company and relegated software maintenance concerns to the vendor. The implementation times measured in years, and the packaged application often required businesses to modify their common practices to conform to the preferred methods defined by the third-party application.
Software AdaptersOther companies turned to vendor-supplied adapters that connected older database formats to available software interfaces. These adapters contained the logic to make older data sources appear to be relational data sources. These companies discovered that, between the cost of the adapters (which could be fairly high-especially for mainframe sources) and the significant effort required to install and configure the packages, this was an expensive solution.
Proprietary Data Exchange Many companies created proprietary binary and text-based formats to facilitate data exchange. These companies soon faced the problem of having to create parsers and adapters for their various systems in addition to the proprietary data exchange formats. One such format, Electronic Data Interchange (EDI), was developed to exchange business data. EDI messages contain a string of elements, each of which represents a single item, such as cost or version number, separated by a delimiter and framed by a header and trailer. Companies could exchange EDI transmissions only over a high bandwidth subscriber network called a Value-Added Network (VAN). This solution resulted in a costly proposition including custom code, the proprietary EDI over VAN, and the subsequent transmission fees.

These varying solutions have resulted in a patchwork of odd systems and subsystems with no clear roadmap and a general inaccessibility of business data. Creating a single view of business data remains a significant requirement in the business world today—and it is still a problem. What's needed is a simple way to view aggregated structured and unstructured data pulled from multiple data sources scattered across a company or industry. Extensible Markup Language (XML) provides this capability.

Thanks for your registration, follow us on our social networks to keep up-to-date