WHITE PAPER

PowerBuilder® Accelerating
SOA Development – Part I
TABLE OF CONTENTS

1 Part I: PowerBuilder in the SOA Implementation Layer

1 SOA: What’s Old is New Again
1 SOA’s Purpose: Business Agility…Remember RAD?
2 A Brief SOA Primer: The Nuts and Bolts of It
2 SOA Challenges: The Process of Change
2 PowerBuilder as SOA Implementation…or SOA Data With Ease
4 Internet Information Server (IIS)
5 Sybase EAServer
7 The PowerBuilder Application Server Plug-in

i
PART I: POWERBUILDER IN THE SOA IMPLEMENTATION LAYER

The last reason for which you want your pilot SOA project to fail is that too much time was spent coding for data
manipulation and data presentation. In this two part article, we’ll examine how PowerBuilder can give you a
competitive edge in Service Oriented Architecture both at the implementation level and in the presentation layer.
We’ll discuss how DataWindow technology can increase the likelihood that your initial SOA project will succeed. In
fact, PowerBuilder will help you to get buy-in from a project’s business owners for second and subsequent SOA
projects…which is where the real power of SOA can be realized.

SOA: WHAT’S OLD IS NEW AGAIN

Service oriented architectures have been around quite a while. What has been lately gaining popularity among
pundits and the press is only the most recent incarnation of SOA. Java’s Remote Method Invocation (RMI), the Object
Management Group’s (OMG) Common Object Request Broker Architecture (CORBA), the Open Group Distributed
Computing Environment (DCE), and Microsoft’s Distributed Component Object Model have all had their supporters
and enterprise utilizations. The current SOA this time around is based on Web Services. What’s so different now?
Arguably, the traction this SOA incarnation is experiencing is due to the ubiquity of IP-based networks and the
simplicity of accessing Web Services.

SOA’S PURPOSE: BUSINESS AGILITY…REMEMBER RAD?

It’s arguable whether SOA will take over the world, but if it does become predominant, it has Client/Server squarely
in its crosshairs.

Pointing to Client/Server, SOA advocates often critique it as “monolithic” and “too hide bound” to respond to ever-
accelerating demand for change of business requirements. Somewhat ironic is that this was the same criticism
Client/Server advocates used when pointing to mainframe/procedural application development in the early 1990s. It
may seem even more of a paradox then that PowerBuilder, the seminal C/S development tool, will help SOA
proponents achieve their business agility goals; especially during the oh-so-critical pilot project…but it will. SOA’s
main reason for existence is to achieve the goal of Business Agility; the ability to respond to short-notice business
requirement changes and additions in a timely fashion. SOA achieves this goal of business agility through reuse.

Remember Service Based Architecture? Remember Object Orientation? Remember RAD? When OO first came to the
marketplace, there was an effort then as well to get buy-in from business owners to have faith that savings would
eventually be realized in second and subsequent projects when the cost and schedule benefits of reuse would begin
to manifest themselves. It was a challenge in the early 1990s to show business owners that the preparation
necessary for OO was easily reconciled with the concept of RAD. By using Rapid Application Development techniques
whenever possible, development time was optimized and freed for the more challenging task of creating a sound
architecture and codified business rules that enabled and encouraged reuse.

There’s no need to abandon RAD when developing SOAs. By employing DataWindow technology in your Web
Service implementation (code) as well as in the presentation layer of a SOA solution, you’ll have a distinct productivity
advantage, in fact, a competitive differentiator in your hip pocket.

As PowerBuilder developers and architects, you’ve had experience identifying or even reengineering business
processes that were redundantly implemented in multiple applications. You’ve already shown how to consolidate
these into a single point of maintenance, a single point for enhancement into common PowerBuilder libraries shared
among multiple solutions within an enterprise. This is old hat for you, and yet it’s a hallmark of what drives the
contemporary SOA of today! From your OO days, you also have experience in showing management and business
owners the advantages of reuse and the investment of time that is necessary in the first iteration in component-
driven architectures. As experienced PowerBuilder developers you’re in the SOA catbird seat for a variety of reasons
including being familiar with component-based architectures and the reuse enabled by OO techniques.

1
 A BRIEF SOA PRIMER: THE NUTS AND BOLTS OF IT

In short, Service Oriented Architecture is a distributed model for creating enterprise level software. Reuse in SOA is
achieved by a distributed, component-driven model. Its logic is partitioned into distinct components. These
components are “self-contained” or it could be said “well encapsulated”. The implementation, or code of these
components, can be heterogeneously programmed using multiple languages for any one solution. The components
are commonly hosted and exposed as Web Services by one or multiple servers. These components may execute
requests themselves, indirectly call other services for logic execution, perform database access, deliver/receive email,
even expose legacy systems like mainframe applications as services. Language agnosticism in Web Services is
achieved by “wrapping” each component with a standards-based interface. This standard interface allows the
component to interact with the interface of other components in this potentially heterogeneous assemblage across
the standard SOAP protocol. Web Service-based SOA is loosely coupled. Loose coupling is achieved by insulating the
implementation languages with the component “wrapper” that is a service. The analysts and developers putting the
SOA into development will “mine” their practices for tasks that are redundantly coded in multiple applications to
provide the alternative of one service that acts as a single point of maintenance, a single point of fulfilling change
requests. The developers will then in great part create new solutions/applications by assembling or “orchestrating”
these discrete services into processes. It’s certainly beyond the scope of this primer to go into a more detailed level
than this, but I’ll briefly cite additional elements of an SOA that include but are not limited to...

• A discoverable, searchable directory of available services.

• A metadata repository describing the services.
• A message layer guaranteeing that each synchronous (request/reply) or asynchronous (fire/forget) service
request gets one and only one response.
• BPEL4WS or Business Process Execution Language for Web Services allows the developer to orchestrate or extend
services into Business Processes that can provide transactional control.

SOA CHALLENGES: THE PROCESS OF CHANGE

While the technical challenges presented to SOA architects are considerable, they’re surpassed only by the cultural
challenges inherent in SOA adoption. The cultural challenges include 1) Organizational: putting procedures in place for
making modification requests once business owners begin making them and 2) Governance: ensuring that once a
service or business process has been designed and created, it’s reused rather than recreated. (Remember the advent of
Object Orientation?) The ability to abstract service implementation in a language- and platform-agnostic manner is
one of SOA’s greatest strengths -- that is, creating a cohesive enterprise from heterogeneous resources. To then
overcome the temptation to blindly standardize upon one service implementation language when the abilities of
another language to more productively accomplish any one task is indeed a cultural challenge. One of the main
thrusts to Web Service-based SOA is that the implementation language, the code that is executed, is abstracted by
the service layer and in fact becomes moot to the enterprise at large. This leaves the developer the freedom to choose
the right tool for the right job -- the most productive (or may we say RAD) language for each service’s task. And if the
job at hand is the heavy lifting of data…what technology comes to mind as the most productive, allowing you to get
the most accomplished with the least code when it comes to muscling around piles of data? Hmmmm??

POWERBUILDER AS SOA IMPLEMENTATION…OR SOA DATA WITH EASE

So let’s talk about PowerBuilder components, a.k.a. Custom Classes, a.k.a. Nonvisual User Objects a.k.a. NVOs. At this
point in time from the PowerBuilder IDE you can take an NVO and deploy it to a roster of application servers including
Sybase’s EAServer, IIS, WebLogic, WebSphere, and JBoss…then have it exposed as a Web Service. Once deployed, these
PowerBuilder Web Services can take on considerable data-oriented tasks at a pretty performant clip. Let’s pose a
specific example: a PowerBuilder Web Service converting a result set into XML. As you can see from this method,
PowerBuilder is simply taking in an argument value to be used in a query, retrieving the result set, then returning that
result set as an XML-formatted string. After initializing the Transaction Object and the DataStore, it’s one line of code
to retrieve the result set, and one line of code to perform the transformation.

2
 DataStore lds_employees
String ls_xml

//Initialize a Transaction Object and use it to connect to a DBMS

transaction my_trans
my_trans = CREATE transaction
my_trans.DBMS = "ODBC"
my_trans.DBParm = "ConnectString='DSN=EAS Demo DB V110;UID=dba;PWD=sql'"
CONNECT using my_trans ;

//Initialize a DataStore
lds_employees = CREATE datastore
lds_employees.DataObject = 'd_dept_emp'
lds_employees.Settransobject( my_trans )

// Retrieve a departments employees and

// convert the result set to XML
lds_employees.Retrieve( dept_id )
ls_xml = lds_employees.object.DataWindow.Data.XML

//Clean up
DESTROY lds_employees
DISCONNECT using my_trans ;
DESTROY my_trans

Return ls_xml

So the point is, this is very little code folks. You would avoid taking up a stomach-wrenching amount of a SOA
project’s schedule by having PowerBuilder-implemented Web Services accomplish both your most simplistic and your
most demanding data-oriented tasks. Make no mistake, there’s no requirement that you must use DataWindow
technology in your PowerBuilder Web Services. Every single Web Service in your SOA can be PowerScript-implemented
if you wish…even those without data-oriented tasks. What we want to do in this article is to point out when it doesn’t
make sense to use anything BUT PowerBuilder for a subset of your complement of services. Especially with SOA you
need to ensure that economy of code is pursued. Let PowerBuilder take care of the data so you can get on with the
hard stuff: architecture, governance, culture, business process reengineering.

Back to our component. Deploying this component as a Web Service to any of the aforementioned application
servers is a code-free matter of filling in some property sheet values for the appropriate type of project. Further
underscoring the productivity of the PowerBuilder IDE is that for each of the deployment project types to follow, all
idiosyncratic deployment tasks will be automatically performed by these PowerBuilder projects at the click of a toolbar
button or menu item: the installation of the class to the application server’s repository, the configuration files created
and deployed, etc. There are wizards for each of the following deployment projects, but for the sake of brevity we’ll
only take a tour of each project’s property sheets and cite only the properties that are salient for this topic. The
developer may create each of the types of deployment projects for NVOs listed in this article by selecting File>New
from the PowerBuilder IDE menu, then selecting the Project tab page. For certain Projects, creating a new appropriate
container Target is a prerequisite.

3
 INTERNET INFORMATION SERVER (IIS)

As of PowerBuilder 11.0 you may deploy your PowerBuilder components to IIS as .NET Web Services. On the General
tab page of the .NET Web Service Project, you’ll choose the IIS virtual directory to which your service will be deployed.

Figure 1

The Deploy tab page will let you choose to which instance of IIS you want to deploy or optionally package your
service as a Microsoft Installer file.

Figure 2

The Objects tab page will let you choose the name or alias by which the service will be invoked. Furthermore, this
property sheet allows you to designate the subset of your publicly declared methods that you want exposed in this
.NET Web Service.

Figure 3

4
SYBASE EASERVER

For the EAServer Component Project, you’ll first want to specify the Package to which the component will be
deployed. (A Package is a way of logically grouping related classes together.)

Figure 4

On the Server Host tabpage, you’ll designate to which of your extant host profiles the component should be deployed.

Figure 5

5
 On the Components tabpage, you choose which components you wish to deploy and designate various component
options for the flavor of transactional support, the component type, whether it’s stateless or stateful, etc.

Figure 6

On the Web Service tabpage, you may choose whether or not to expose this EAServer-hosted component as a Web
Service and if so designate the server’s Administration port, the application name to which you’ll deploy, as well as
the service name.

Figure 7

For a more detailed discussion of the EAServer deployment project see “Chapter 24: Building an EAServer
Component” in the PowerBuilder documentation’s “Application Techniques”.

http://infocenter.sybase.com/help/topic/com.sybase.dc37774_1100/html/apptech/CBBBFDAD.htm

6
THE POWERBUILDER APPLICATION SERVER PLUG-IN

The PowerBuilder Application Server Plug-in (PBASP) was created to allow PowerBuilder developers to deploy
components to J2EE application servers in shops that have standardized on something other than Sybase EAServer.
With this utility, NVOs may be deployed with EJB session bean wrappers, and then exposed as Web Services by their
respective hosts. A post-PBASP 1.0 version will support PowerBuilder 11 components. In this image we see a project for
deploying an NVO to JBoss as an EJB. The package name and its equivalent for Java interfaces are specified in the
project’s General tab page.

Figure 8

On the Server Host tab page, a predefined host profile consisting of the host name, its port number, and the
authentication information needed is chosen by the PowerBuilder developer.

Figure 9

7
 The Components tab page is your chance to designate the component’s name or alias by which it will be known to
clients as well as the component’s level of transactional support. You can also decide whether or not the NVO will
behave in a stateless manner, whether or not it participates in instance pooling, its need for thread safety, and
whether or not to tag it for remote debugging.

Figure 10

As you can see in the project’s Web Service tabpage, you can decide whether or not to expose the resultant EJB
session bean as a Web Service without having to leave the PowerBuilder IDE.

Figure 11

If your SOA utilizes WebLogic, WebSphere or JBoss you can deploy your PowerBuilder collateral as services to these
J2EE servers in an efficient and agile fashion.

In pilot SOA projects the demands of developing and/or adapting the presentation layer, the application(s) that will
act as the users’ interface, is constantly in danger of being overlooked in initial project plans and in danger of being
grossly underestimated. If optimization planning for the UI is left until the latter stages of development, defeat can all
too easily be snatched from the jaws of victory. In part two, we’ll examine how PowerBuilder will be your most
productive development environment for presenting and modifying the data being proffered to the users of your SOA.

8
9
 SYBASE, INC. WORLDWIDE HEADQUARTERS, ONE SYBASE DRIVE, DUBLIN, CA 94568 USA 1 800 8 SYBASE Copyright © 2008 Sybase, Inc.
All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo and PowerBuilder are trademarks of Sybase, Inc. or its
subsidiaries. All other trademarks are the property of their respective owners. ® indicates registration in the United States. Specifications are subject to
www.sybase.com change without notice. 04-08