Teiid User Scenarios
Teiid can be used by different people in a variety of scenarios. This page describes some of the most common scenarios for users of Teiid.
The typical Java J2EE developer is expected to have a moderate level of experience with Java, JDBC, one or more databases, and SQL, and a fair amount of experience specific to their current application server (assumed to be Weblogic, Websphere, or JBoss).
The J2EE Developer uses some form of IDE (JBDS, WSAD, Eclipse, NetBeans, IDEA) the majority of the time while building and testing their applications and is fairly dependent on the setup of that environment. The development machine is likely to be Windows or Linux with deployment occurring on Solaris, Linux, or Windows.
J2EE Developers already have the ability to manage and retrieve data from multiple JDBC sources via multiple JDBC connection pools. Teiid is useful in that it allows the J2EE Developer to query over those data sources in tandem without writing custom data access code. J2EE Developers expect Teiid to integrate smoothly into their application server and operate as a JDBC driver with minimal fuss and configuration.
Being able to use existing JDBC connection pools in the application server rather than manage new connections would be desirable as the system administrators can only see what appears via the application server administration tools.
- Seamless integration into the app server
- Ability to query over multiple databases with one query
- Simplicity and minimal configuration
The Java Developer is similar to the J2EE Developer, but are working either partially or completely outside a J2EE environment. The most common frameworks of use are likely Spring and Hibernate.
The Java Developer uses an IDE the majority of the time but may not be quite as dependent on it as the J2EE Developer. The development machine is likely to be Windows or Linux with deployment occurring on Solaris, Linux, or Windows.
The Java Developer is likely to have a higher degree of Java proficiency and more detailed knowledge of JDBC than the J2EE Developer, as the J2EE Developer is often abstracted from JDBC by the app server container. However, they may themselves be dependent to some degree on a framework such as Spring or Hibernate.
Java Developers want to integrate multiple sources and may find abstraction also somewhat compelling depending on the project. Like the J2EE Developer, the ability to query against multiple data sources in a single SQL statement can potentially be a huge benefit in designing their application and getting it working quickly.
The Java Developer can use custom JDBC APIs or other Teiid features more easily as there is no application server in the way, thus they may try a broader range of features.
The Experienced Architect is often evaluating products for use in one or more projects. The desired product may actually be JBoss Enterprise Data Services Platform in this case but the architect is trying out Teiid because it is available for download from the web. In any case, their goal is to test out what Teiid has to offer and the focus is on rapid data integration, not on interoperability with a particular existing framework or application.
- Ease of installation and short time to results
- Well organized documentation
The Admin Developer is involved in integrating Teiid into an existing application using a programmtic API. They are focused on how to automate Teiid-related activities necessary to the project such as metadata import and assembly, deployment, and administration.
- A clean, well-defined API
- Descriptive error logging
- Thorough documentation in the form of JavaDocs
The Tool Smith is involved in integrating Teiid into an existing application or process. They are focused on how to automate Teiid -related activities necessary to the project such as metadata import and assembly, deployment, and administration.
The Tool Smith is likely an expert at one or more flavors of Linux/Unix and less familiar with Java, other than from an invocation point of view. Tool Smiths are likely to be highly proficient in Ant, Perl, shell scripting languages, etc. Tool Smiths are also proxy users for automation as their engagement is typically transitory while things are automated, then hands off after that.
Tool Smiths value:
- Scriptable execution (Ant tasks, command line utilities, etc)
- Descriptive error logging
- Thorough documentation