Technology and Community

Jim O'Neil

Subscribe to Jim O'Neil: eMailAlertsEmail Alerts
Get Jim O'Neil: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

PowerBuilder and EAServer: Uniting the .NET and J2EE Communities

Continuing their legacy of synergy and openness

Connection Object
Applications built for Win32 deployment that use the Connection object to access a non-secure IIOP port do not need to be modified when deployed as .NET targets. Since the Connection object abstracts the underlying implementations of the EAServer ORB, the interface exposed to the PowerBuilder developer is independent of the deployment target – Win32 or .NET. In fact, since the new .NET client functionality was not influenced by the now defunct Distributed PowerBuilder feature, the list of codes returned by the main methods of the Connection object – ConnectToServer and CreateInstance – is actually shorter! (see Table 1).

Listing 1 provides sample code (for any PowerBuilder target type) that instantiates a Connection object and invokes a few component methods. In this sample and the ones that follow, mathComp is a proxy reference to a component named SimpleMath located in the EAServer package PBDJ. Also assume that argX and argY are integral values passed as parameters or perhaps provided as input by the end user.

JaguarORB
The JaguarORB object in PowerBuilder is a lower-level wrapper of the client ORB functionality and provides finer control over instantiating and invoking EAServer components. When using JaguarORB, client applications are responsible for explicitly creating the EAServer session as well as instantiating the client proxy. A primary use of JaguarORB is to override the load balancing implicit in the Connection object, thus forcing component instantiation to occur on a specific EAServer instance.

Listing 2 demonstrates using JaguarORB to provide the same functionality as shown in the previous code example. Again, this sample code will work equally well regardless of whether it’s deployed as a p-code or machine code application or as a .NET target.

Unlike the example using the Connection object in Listing 1, this code can actually terminate execution of the client application if exceptions are raised in the intermediate components SessionManager/Manager and SessionManager/Session. To address this, TRY/CATCH blocks should be incorporated into the client application code to provide adequate error detection and recovery. PowerBuilder’s object hierarchy defines a number of CORBA exceptions that extend the RuntimeError class to trap for various error conditions. A sample TRY/CATCH block follows that could envelop Listing 2 and provide error handling for invalid credentials as well as for other remote and user-defined exceptions.

TRY
// ... include listing 2 here

CATCH (CORBANoPermission exc1)
// handle invalid user id/password combination

CATCH (CORBAUnknown exc2)
// handle invalid component name and other errors

CATCH (CORBASystemException exc3)
// handle other EAServer exceptions

CATCH (CORBAUserException exc4)
// handle user-defined exceptions thrown in component method calls

END TRY

This error handling code will serve you well when deploying traditional p-code or machine code applications; however, due to how exceptions are handled in PowerBuilder .NET targets, these CATCH clauses will not be triggered. In fact, even the all-encompassing clause

CATCH (Throwable t)

will not capture the exceptions raised in an EAServer .NET client application. Figure 1, extracted from the PowerBuilder documentation, shows why.

Note that most exceptions emanating from managed code implementations (C# and VB.NET) extend the base .NET System.Exception class so they cannot be caught from the built-in PowerBuilder exception types that descend from Throwable. There are a few deviations from this rule, such as System.NullReferenceException and System.DivideByZeroException, which do map to predefined PowerBuilder runtime errors. Although many CORBASystemException types are also defined in the PowerObject hierarchy, they are not currently mapped to the analogous .NET exceptions raised in the EAServer client assemblies. User-defined exceptions raised in component methods do, however, map appropriately to the CORBAUserException type (which extends Exception in the PowerObject hierarchy).

To address these exception-handling nuances in your PowerBuilder .NET targets, you’ll need to introduce a CATCH clause for the specific .NET exceptions you want to capture. For example, you could add the following CATCH clause to handle the exceptions raised from an EAServer .NET client application:

#IF DEFINED PBDOTNET THEN
CATCH (System.Exception exc4)
// handle .NET exceptions
#END IF

Note the use of the conditional compilation block to allow referencing a .NET class, here System.Exception. For this code to deploy successfully, the .NET assembly containing System.Exception, namely mscorlib.dll, must be referenced in your PowerBuilder target’s properties as shown in Figure 2.

While you might be inclined to provide finer-grained exception handling, such as

CATCH (com.sybase.iiop.net.CorbaMarshalException cme)
// exception handling code

CATCH (com.sybase.iiop.net.CorbaNetworkException cne)
// exception handling code

you cannot currently refine your processing in this way due to a compilation error that occurs when adding the com.sybase.iiop.net assembly to your target. This deficiency should be addressed in a PowerBuilder patch shortly after the release of PowerBuilder 11.2. In the meantime, you can discern the actual exception type by using the following code:

CATCH (System.Exception ex)
CHOOSE CASE ex.GetType().ToString()
CASE (“com.sybase.iiop.net.RemoteSystemException”)
// handle remote exception, e.g., incorrect password

CASE (“System.Net.Sockets.SocketException”)
// handle socket error, e.g., server not running
...
END CHOOSE

Secure Client Connections
Our last topic involves secure connections to EAServer via the SSL and IIOP protocols. SSL involves the use of Public Key Encryption and digital certificates to support two types of authentication in EAServer:

  • server authentication to ensure that the server being accessed is the one it purports to be, and
  • mutual (client and server) authentication that requires that the client also present trusted and valid credentials (an SSL certificate) to the application server.

EAServer implements its security infrastructure using the Java Secure Socket Extension (JSSE) API and exposes its configuration via security profiles. Each EAServer listener can be configured to support a security profile that defines the characteristics of a client-to-server connection in EAServer such as encryption requirements, protocol, authentication type, and hashing methods. The default instance of EAServer includes two security profiles: default and default_mutual. The default profile is associated with the IIOPS1 listener on port 2001 and supports server authentication using the Sample1 Test ID certificate. The default_mutual profile (associated with the IIOPS2 listener on port 2002) supports mutual authentication. It uses the Sample2 Test ID certificate for server authentication and the Sample1 Test ID certificate for client authentication.

Win32 Client Applications
For PowerBuilder Win32 (as well as C/C++) applications, using SSL on a client machine requires the installation of the Client Runtime from the EAServer installation image. This option installs the required runtime libraries and certificate stores on the client machine and configures the JAGUAR_CLIENT_ROOT environment variable appropriately.

When coding a secure Win32 client application, you must specify the minimum quality of protection (QOP) required for the connection and the PIN for the PKCS #11 token prior to the connection request. When the client application negotiates with the server over the specified secure IIOP port, the server accepts or denies the connection based on whether the QOP can be satisfied. In a mutual authentication scenario, the client certificate is also verified before the connection is allowed.

Both the Connection and the JaguarORB objects have a property named options through which the QOP, PIN, and client certificate label (for mutual authentication only) can be specified. The specific options and their purposes are summarized in Table 2.

To configure these values, set the options property to a concatenated string of the desired items, for example:

c.options = “ORBqop=’sybpks_domestic’,ORBpin=’sybase’”

Alternatively, you can use the SSLCallback object in PowerBuilder to supply this information programmatically, perhaps by prompting the end user. SSLCallback exposes a number of methods like GetPin and TrustVerify that are triggered when the SSL negotiation requires a response from the client to continue. By creating a new user object extending SSLCallback, you can provide your own logic and user interface for obtaining this information from the client on-demand.

More Stories By Jim O'Neil

Jim is a Technology Evangelist for Microsoft who covers the Northeast District, namely, New England and upstate New York. He is focused on engaging with the development community in the area through user groups, code camps, BarCamps, Microsoft-sponsored events, etc., and just in general serve as ambassador for Microsoft. Since 2009, Jim has been focusing on software development scenarios using cloud computing and Windows Azure. You can follow Jim on Twitter at @jimoneil

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.