When to Use SQLJ with Java Application Servers
Because of the issues related to multiple mappings of Java objects to tables and vice versa, it is best to use SQLJ with Java application servers when the data being mapped is quite simple. For example, SQLJ would be an excellent way to look up simple account information based on an account number. There would be little mapping of data needed in this case.
If your data mapping may be complex, however, you should look at either JDO or EJB accelerators:
There is one exception to this recommendation; if you do not have an existing database and plan on entering new data directly from an application server, see how SQLJ can be one of the options for EJB accelerators.
For more information on SQLJ issues related to data mapping, see SQLJ Data Conversion.
Also, if you are not familiar with the concept of complex data, see complex data.
Context for When to Use SQLJ with Java Application Servers
Related Articles for When to Use SQLJ with Java Application Servers
Related Articles for When to Use SQLJ with Java Application Servers
Author
Douglas K Barry
Principal
The Savvy Manager's Guide
Douglas K Barry is also the author of a book that explains Web Services, service-oriented architecture, and Cloud Computing in an easy-to-understand, non-technical manner.
Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (Second Edition)
by Douglas K Barry with David Dick
This is a guide for the savvy manager who wants to capitalize on the wave of change that is occurring with Web Services, service-oriented architecture, and—more recently—Cloud Computing. The changes wrought by these technologies will require both a basic grasp of the technologies and an effective way to deal with how these changes will affect the people who build and use the systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of both the changes that we are now seeing and ways to deal with issues created by those changes.