Data Sources
From jVantage
In the truest sense, data sources can be many things. With regard to jVantage, data sources are relational databases. J2EE applications access databases as application server resources, meaning, application servers provide data source connection pooling, sharing, and management capabilities that can be leveraged by hosted applications as external resources. This means that unlike traditional (non-J2EE) applications, database resources can be better controlled and leveraged in ways that are independent and less intertwined with application logic and code. The full benefits of this approach are certainly outside the scope of this document, however, one direct benefit that does impact jVantage, and your applications, has to do with how applications find and communicate with databases. To developers who are not accustomed to J2EE, deployment descriptors can be a tough topic to understand. jVantage helps minimize the extent to which developers are exposed to deployment descriptors, but no J2EE application can escape the need to deal with them altogether. One deployment descriptor that is particularly relevant to our discussion is the Data Source Descriptor. How data sources are defined varies from one application server to the next. However, regardless of those differences, the fundamental purpose and function of data source descriptors are the same: they simply provide a mechanism whereby applications can locate and communicate with databases.
- Again, a data source does not necessarily have to be a relational database. J2EE provides the means for connectors of varying types and purposes to be created, which could allow communication with other resource types. However, although there is nothing to prevent applications built with jVantage from utilizing other types of data sources, these scenarios are not applicable to our current discussion. Henceforth, when data sources are mentioned in this document, assume that we are referring to relational databases unless explicitly indicated otherwise.
A data source descriptor is an XML document that contains a JNDI name, along with other pieces of data that identify a database. An application looks up a data source descriptor by its JNDI name, then uses the associated information from the document to locate and bind to the database itself. Each jVantage application must specify a data source, which provides a path to the database it will use to store data. Although each jVantage application can be assigned a unique data source, it is not a requirement. In fact, all jVantage applications could be configured to utilize the same database with no particular performance ramifications. The only benefit lost is the manageability of the data. Still, for smaller installations, or for applications with smaller data requirements, this is a viable and valid option.
Illustration 9 depicts how data source descriptors are used. Keep in mind that depending on your application server (that is, which vendor you use) the actual descriptor file may never be visible, although most provide a way to view the descriptor if you choose to. Also, be aware that the format of actual data source descriptors is entirely different than those shown for illustrative purposes in the diagram. The data source name, indicated by the orange #1 tag, shows the data source name as it is specified for a given application from within jVantage (compare with Illustration 8). Notice that the data source name specified in the data source field in Illustration 8 is prefixed with java:. This is a designation that indicates where to look in the name space for the data source JNDI name. Illustration 9 shows how this value is used to map the data source name (tag #1) with a particular database (tag #2). This may seem somewhat convoluted on the surface, however this decoupling of database client applications from the databases they use is powerful and essential for managing deployments of any significant size or complexity.
