In the world of Data-Flow Management™, the fundamental task is to get usable information into the hands of business users. Such information is distilled from raw data that can be scattered across an organization, held in repositories in many locations using different storage technologies.

Although every data integration problem is unique, there exist recurring patterns among the solutions to those problems. Over the course of doing business, Labrador has accumulated a collection of 'building blocks' that capture those patterns. These building blocks are comprised of both software and methodology.

Perhaps the most direct way to get data to a business user is to create a desktop (or workstation) application.

Labrador has experience creating desktop applications for the Win32, Java, .Net, and Unix platforms.

Business users now tend to turn to the Web when they need information. As a result, there is a growing movement of end-user applications away from the desktop toward the web. There is a surprisingly large number of ways to deliver application functionality over the web.

On the server-side, all web servers deliver static content in pretty much the same way. Dynamic content, by contrast, can be generated by such diverse technologies as CGI, J2EE/Servlets, portlets, ASP, PHP, and ColdFusion.

On the client-side, things are even more complex. At one end of the scale, applications may work with pure "thin" clients, which is a way of saying that users' web browsers need only understand the standard web protocols (HTTP, HTML, CSS, etc). Alternatively, applications may require "scriptable" clients that support the thin functionality, but also provide dynamic features such as Ecmascript, DOM, DHTML, or SVG. On the next rung of the ladder, some applications may demand that users install "plug-ins". Although hosted in web browser windows, these are really desktop applications that exploit web-based installation mechanisms. Examples include Netscape plug-ins, ActiveX, and Java applets. Finally, there are "thick" or "rich" clients that are used in place of web browsers in order to provide a better user experience than is possible within the confines of browser windows.

Labrador has experience with:

Servers

Apache, IIS, Sun ONE, WebSphere, Tomcat, NCSA, Jetspeed

Dynamic Content

CGI, Servlets, JSP, ASP, ASP.NET, portlets

Browsers

Internet Explorer, Netscape, Mozilla/Firefox, Opera, Pocket IE, Mosaic, Lynx

Client-side Technologies

HTTP, HTML, XHTML, XML, CSS, XSLT, DOM, DHTML, SVG, Java applets, ActiveX, WML

Users are not the only ones who turn first to the web when they need information. Increasingly, software components are looking to the web as well. Distributed computing is not a new concept, as technologies like RPC, CORBA, DCOM, and RMI will attest. The idea is that any consumer of data or services can communicate with a provider of same by means of a standardized interoperability layer. That layer brokers the communication between the other two. It also hides many implementation details of the endpoint components, like the platforms they are running on and, importantly, their physical locations. With the explosive growth of the web, and the universal availability of Internet access, it was inevitable that interoperability layers based upon web standards would arise. These standards, clustered around XML, are rapidly displacing their predecessors in the pre-web interoperability world.

One consequence of this displacement is a change in expectations about what 'distributed' means. Prior to the world-wide web, a distributed system might run over a LAN or dedicated WAN, with known and manageable latency. Now, however, people are used to hitting web sites anywhere on the globe. They build distributed systems with the same expectation. The performance of requests over the world-wide web is a much more variable quantity. The 'distributed objects' model that earlier interoperability layers assumed is very sensitive to network delays. The result is that web services standards place a much larger emphasis upon batching the information required for a transaction into a single request instead of issuing potentially large numbers of individual method invocations.

Labrador has experience with web services based upon XML, SOAP, and WSDL. It has also created solutions using CORBA, RMI, DCOM, RPC, and .NET remoting.

Development teams face mounting pressure to ensure that their applications can access the data they need, wherever it may reside. As the permutations are endless, a common strategy is to design applications to accept "plug-ins". This entails expressing the data needs of the application in terms of a fixed API (application programming interface). Data retrieval can then be performed by purpose-built components that are plugged into the application, communicating through the API. The net result is that plug-ins allow a clean division of labour when the time comes to adapt an application for the environment in which it is deployed.

Labrador has experience both designing applications that accept plug-ins and providing plug-ins for other applications. In this regard, Labrador has worked in Java, C#, and C/C++, using technologies such as COM/DCOM, JavaBeans, DDE, RMI, HTTP, Telnet, DLLs, dynamic class-loaders, ODBC, JDBC, ADO/ADO.NET, and Win32 messages.

Many EAI solutions contemplate the use of a central intrastructure that is responsible for facilitating communication between the major software systems within an enterprise. This backbone is frequently called the enterprise or integration 'bus', so named in analogy to the various address, data, and peripheral buses that one finds in contemporary computer architectures. The bus provides services such as messaging, publication and subscription, activity monitoring, transaction handling, and process management. Some kinds of enterprise applications will turn to the bus to obtain data instead of using the web or getting it directly. These needs can be satisfied by bus components that are specifically designed to push data onto the bus, or to modify data that is already flowing on the bus.

Labrador has done work with the J2EE framework, notably involving JMS.

Some data stores have very complex structures which are frequently poorly documented. It is not uncommon for members of a development group to work through these problems individually and to express point solutions in their code. For example, a team working with a relational database may accumulate SQL statements in various places throughout the application. Not only is there a measure of redundancy in this approach, but it also risks subtle incompatibility flaws if two team members come to different conclusions about the form of a particular query.

The solution to this problem is to isolate the main application code from the data queries and manage the queries in a centralized module. Application code could invoke queries by, say, a simple method call. The query module would be responsible for mapping the method call to an actual query suitable for the target data store. In the general case, this approach would be taken for all metadata, not just queries.

Such a metadata component could operate at design time as a code generator or at run time as an interpreter. It could also hide details such as where the data store is located and even which query language or dialect is used by that store. Finally, the metadata component could hide all but the most radical of changes to the data store's structure.

Labrador has experience creating and using metadata components for SQL (Oracle, MS SQL Server, DB2, Sybase), XML (Schema, XQuery, XSLT), JAXB, and ADO.NET.