Welcome!

Helping Developers Master PowerBuilder Classic and .NET

Yakov Werde

Subscribe to Yakov Werde: eMailAlertsEmail Alerts
Get Yakov Werde via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

Vendor Independent Data Access in EAServer 3.6.1

Vendor Independent Data Access in EAServer 3.6.1

It's well known that Sun Microsystems' Enterprise JavaBean (EJB) specification is an industry-standard, vendor-neutral, portable architecture for middle-tier transactional components. In an industry starved for standardization, both the server vendor and the development community have embraced EJB. Sybase is a leading member of the J2EE consortium.

Sybase's EAServer version 3.0 supported EJB 0.4, version 3.5 supported EJB 1.0, and the recently released J2EE-compatible EAServer version 3.6.1 supports the latest EJB 1.1 specification.

The EJB 1.1 specification offers many enhancements and improvements over previous releases. Among the major new features are:

  • Entity beans are now mandatory.
  • Support for container-managed persistence is mandatory.
  • EJB now uses a standard Java API (JNDI) to access container-managed resources such as connection caches.

    This article focuses on the last point - using JNDI to access an EAServer connection cache from within an EJB.

    Let's first get a few basic definitions under our belt.

    1. Middle-tier transaction servers: They typically maintain a pool (cache) of preconnected database connections, which they rapidly recycle among many component instances. A connection cache guarantees maximum performance for data-centric components since expensive connect and disconnect operations are virtually eliminated. Another benefit is increased application scalability, since few database connections can service many component instances. EAServer supports connection caching.

    Middle-tier transaction servers provide name and directory services, which, similar to a telephone directory service (411), provide a logical mapping between a physical address (telephone number) and a logical name (a person). Name and directory services allow for location transparency by mapping a logical name to a physical object, binding (which can also be a factory object that generates other objects). This enables you to move a component from server to server without modifying absolute references in dependent code. EAServer provides CORBA-compliant name and directory services (COSNaming). An individual name space is referred to as a context.

    2. Java Name and Directory Interface (JNDI): A standard API for accessing any supported name and directory service. In JNDI a vendor builds a Service Provider Interface (SPI) that maps the standard Java API to its vendor-specific implementations. The benefit to the programmer is obvious; it's necessary to know only one API to access any supported directory service. In EAServer, JNDI can be used to access the CORBA name and directory service.

    3. Factory object: A static class that generates objects of a specific class.

    4. Data source interface: A new feature of Java JDBC version 2.0; a class implementing the data source interface is a factory for database connection objects. Sybase's JConnect JDBC driver, included with EAServer 3.6.1, supports data sources.

    What Was Life Like in EAServer 3.5 and EJB 1.0?
    EJB 1.0 didn't specify a vendor-independent way to access server resources. A component needing access to a database connection via a connection cache had to invoke vendor-specific methods. In EAServer these methods are grouped in the Java package com.sybase.jaguar.jcm. Specific methods used were JCM.getCacheByName(cacheName), which returns a reference to a specific cache, and JCMCache.getConnection( ), which returns a reference to a connection managed by a cache. These methods perform wonderfully, but, alas, they're vendor-specific. Any bean invoking them is no longer standards-based and implementation-independent, missing out on a prime goal of the EJB architecture.

    What's the J2EE Standard Way of Doing
    It in EAServer 3.6.1 with EJB 1.1?

    EJB 1.1 specifies a directory name space called the default naming context for an EJB. The default context provides access to a set of immutable, bean-specific entries. It's also used as a repository for linking to predefined server resources as well as other EJBs. The default context is accessed simply via the JNDI lookup( ) method. lookUP( ) standardizes the process of acquiring a JDBC connection from a cache. No more vendor-specific calls. It's up to the bean developer to define the resources needed by a bean. Preferably, resources are specified in a vendor-neutral manner in the XML deployment descriptor (Sybase's PowerJ creates the XML deployment descriptor for you), but can also be configured directly on the bean after deployment via the Jaguar Manager. Figure 1 shows an EAServer connection cache.

    Figure 2 shows a bean's resources being specified to access that cache.

    Finally Listing 1 provides the code inside the bean to acquire a connection and access data. The JNDI code is bolded.

    Observe that the bean needs to know only the logical name assigned to the connection cache. No server-specific references are present. This code is portable with no modification between servers from different vendors.

    Moving Data Client-Side
    Know ye that CORBA is the underlying transport mechanism between EAServer components and their clients. CORBA transport is both language- and platform-independent. Only CORBA-compatible data types can be sent over the wire. A native data type must map to a CORBA data type to be communicated. Java sql.ResultSets are eliminated because they're unique to the Java platform. To complete a one-two punch, Java ResultSets are not serializable, rendering them unfit to be sent as a pure binary data stream.

    Java ResultSets are readily converted into several popular transportable formats. Which format you choose depends mainly on what kind of client you support and how much performance you need.

    For pure Java interaction (Java client), iteratively place the data elements of each row into the properties of a serializable class, then add the class to a collection. Complete the operation by returning the collection.

  • Positive aspect: No special mechanisms are required - it's pure Sun Java.
  • Negative aspect: Java serialization is a time-consuming process.

    PowerBuilder clients don't understand Java data types. They do, however, understand CORBA result sets. EAServer provides a "helper class" with a static method to convert a Java result set into a CORBA result set. PowerBuilder provides a method datastore.-CreateFrom that will create a PB DataStore result set from a CORBA result set.

  • Positive aspect: It works with any type of "rich" client and is fast performing.
  • Negative aspect: It requires a vendor-supplied (Sybase) helper class, so it's not totally portable. This method is illustrated in Listing 1.

    When the client type is totally unknown or a completely generic solution is required, Java result sets can be converted row by row into XML. The component will then return a String.

  • Positive aspect:Total client independence - XML potentially works with everything.
  • Negative aspect: Performance - there's overhead in creating XML.

    Listing 2, pure vanilla Java, returns a ResultSet as a collection of data classes.

  • More Stories By Yakov Werde

    Yakov Werde, a 25 year IT industry veteran, is a member of TeamSybase and the newly formed Sybase Customer Evangelist Team. Yakov is a recognized author, speaker and trainer who has been designing and delivering PowerBuilder, .NET, EaServer, Web App Development, and Java training for over 14 years to corporate, military and government developers. Prior to discovering his aptitude as an educator, Yakov worked as an architect, project manager and application coder in the trenches of application software development. Yakov holds a Masters in Education with a specialty in instructional design for online learning from Capella University and a BS in math and computer science from Florida International University. Yakov, managing partner of eLearnIT LLC (www.elearnitonline.com), authors and delivers workshops and web based eLearning tutorials to guide professional developers toward PowerBuilder Classic and .NET mastery. Follow Yakov on Twitter as @eLearnPB

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.