Architecture of a distributed application

PowerBuilder provides support for three middle-tier servers:

• Jaguar Component Transaction Server (CTS)
• Microsoft Transaction Server (MTS)
• Distributed PowerBuilder

PowerBuilder developers can build clients that invoke the
services of Jaguar CTS, MTS, and distributed PowerBuilder servers.
In addition, they can build components (or objects) that execute
inside each of these middle-tier servers.

Jaguar CTS

About Jaguar CTS

Jaguar CTS, part of the Enterprise Application Server, provides
a framework for deploying the middle-tier logic of distributed component-based applications.
At the heart of Jaguar CTS is a high-performance transaction server that
provides efficient management of client sessions, security, threads, third-tier
database connections, and transaction flow. Jaguar’s scalability
and platform independence allow you to develop your application
on inexpensive uniprocessor machines, then deploy the application
on an enterprise-grade multiprocessor server.

With Jaguar CTS, you can:

• Deploy PowerBuilder,
  Java, ActiveX, and C/C++ components to
  the middle-tier transaction server
• Develop CORBA-compliant client applications
• Administer the transaction server using Jaguar Manager,
  a graphical utility that supports component interface browsing,
  declarative role-based security, and runtime monitoring

Jaguar CTS provides the following additional services:

• Transparent client-session and component life cycle
  management
• Connection caching to allow reuse of remote database
  connections
• Transaction management to simplify the design and
  implementation of an application’s transactions
• Instance pooling for efficient reuse of component
  instances by multiple clients
• Transparent thread-safety features to simplify the
  use of shared data and resources
• Result-set support to enable efficient retrieval
  of tabular data in client applications
• Declarative, role-based security to restrict client
  connections and the components that can be invoked by a specific
  client session
• Native SSL protocol support, including X.509 certificate
  authentication

PowerBuilder and Jaguar are fully integrated

A PowerBuilder application can act as a client to a Jaguar
CTS server. In addition, a Jaguar server can contain PowerBuilder
custom class user (nonvisual) objects that execute as middle-tier
components.

Jaguar hosts the PowerBuilder virtual machine natively. This
means that Jaguar can communicate directly with PowerBuilder nonvisual
user objects, and vice versa. Jaguar components developed in PowerBuilder
can take full advantage of the ease of use and flexibility of PowerScript
and the richness of PowerBuilder’s system objects.

Jaguar components developed in PowerBuilder behave like any
other Jaguar components; therefore, these components can exploit
Jaguar features such as transactions, interoperability, and instance
pooling. Both PowerBuilder and non-PowerBuilder clients can access
PowerBuilder components running in Jaguar. In addition, PowerBuilder
clients can access both PowerBuilder and non-PowerBuilder components.

Jaguar server architecture

Components and packages

Jaguar can host PowerBuilder, Java, C, C++,
and COM/ActiveX components. A component is
an encapsulated object that contains business logic that runs in
the Jaguar transaction server. A component consists of one or more
methods that provide services to Jaguar clients. Clients create
an instance of a component and execute methods associated with that
component.

A package is a collection of components
that work together. Each package acts as a unit of distribution,
grouping together application resources for ease of deployment and
management.

Connection caching

To optimize database processing, Jaguar provides support for connection caching.
Connection caching allows Jaguar components to share pools of preallocated
connections to a remote database server, avoiding the overhead imposed
when each instance of a component creates a separate connection.
By establishing a connection cache, a Jaguar server can reuse connections
made to the same data source.

Transaction support

Jaguar components that you develop in PowerBuilder can participate
in Jaguar transactions. A Jaguar transaction is
a transaction whose boundaries and outcome are determined by Jaguar.
You can mark components to indicate that they will provide transaction
support. When a component provides transaction support, Jaguar ensures
that the component’s database operations execute as part
of a transaction.

Multiple Jaguar components can participate in a single Jaguar
transaction; Jaguar ensures that database changes performed by the
participating components are all committed or rolled back. By defining
components to use Jaguar transactions, you can ensure that all work
performed by components that participate in a transaction occurs
as intended.

Instance pooling

Jaguar components can optionally support instance pooling. Instance
pooling allows Jaguar clients to reuse component instances.
By eliminating the resource drain caused by repeated creation of
component instances, instance pooling improves the overall performance
of a Jaguar server.

Shared components

To allow clients to share state information, Jaguar provides
support for shared components. Shared components
allow multiple clients to share the same component instance. When
you deploy a PowerBuilder nonvisual object to Jaguar, you have the
option to configure this object as a Jaguar shared component.

Shared components allow you to:

• Provide convenient
  access to common data that would otherwise need to be retrieved
  separately by each client connection
• Reduce the number of database accesses, allowing
  the database server to be available for other processing

Jaguar naming service

Jaguar implements the CORBA standard CosNaming naming service.
When multiple servers are involved in your application, the naming
service allows you to specify logical server names rather than server
addresses. For example, instead of connecting to your finance component
server at host badger
using port 9000
,
you can specify the initial naming context for that server, such
as USA/MyCompany/FinanceServer. Components are
identified by specifying an initial server name context plus the
package and component name.

Load balancing, failover, and high availability

Jaguar provides support for load balancing, failover, and
high availability. These features ensure that incoming client requests
are evenly distributed between multiple Jaguar servers and that
Jaguar services are still available even when one or more Jaguar
servers are unavailable.

To enable load balancing, failover, and high availability,
you must first create a server cluster (a
group of Jaguar servers running on different machines). The servers
within a cluster share the workload, and the cluster provides client services
even if a server or servers within the cluster fails or is off-line.

How Jaguar differs from distributed PowerBuilder

Jaguar provides built-in services for managing client sessions,
security, threads, third-tier database connections, and transaction
flow. Therefore, you do not need to write code to implement
these services
. This is not the case with a distributed
PowerBuilder server, which must be developed from scratch in PowerBuilder.

When a client connects to a distributed PowerBuilder server,
the ConnectionBegin event of the Application object is fired to
allow the server to authenticate the client connection and allocate
resources for the client. When the client disconnects, the ConnectionEnd
event is fired to allow the server to clean up client resources.
These events are not
fired when a PowerBuilder
user object executes in Jaguar.

The Jaguar server manages program variable space in a very
different way from a distributed PowerBuilder server. For each client
connection to a distributed PowerBuilder server, PowerBuilder maintains
a separate client session. All server objects instantiated by a
client share the same session; therefore they all share the same
global variables and the same application object. In addition, if
two or more objects are of the same class, any shared (class) variables
are shared among the instances of the class. This is not
the case
with Jaguar. Each PowerBuilder user object running in
Jaguar has its own copy of the global and shared variables.

Unlike the distributed PowerBuilder server, which is session-oriented,
the Jaguar server architecture is component-oriented. Each component
maintains its own state. When a single client instantiates several
objects on the server, Jaguar maintains program variable space for
the objects separately. The server objects share no common state.
They can communicate only through methods, Jaguar shared components,
server files, and databases.

Jaguar client architecture

A PowerBuilder client that accesses a Jaguar server has three
main components:

• User interface
• Connection object
• Jaguar proxy objects

User interface

The client application contains
all of the windows and menus required to interact with the business
user. In addition, the client contains scripts that perform processing
in response to each action that the user takes. For example, these
scripts can specify what happens when a user clicks a button, chooses
an item from a menu, or enters data into a text box in a window.

Connection object

The Connection object makes
it possible for the client application to connect to Jaguar and
request its services. The Connection object is instantiated in a script
in the client. Its properties provide the information PowerBuilder
needs to establish client connections. The Connection object identifies
the host name and port number for the Jaguar server, the user ID
and password for the connection, and optionally a default package.
The Connection object can also be used to specify ORB properties
for a connection.

Jaguar proxy objects

Each component in a Jaguar server
has a corresponding proxy object in the client
application. At execution time, the proxy object allows the client
to address the remote object instance just as if it were instantiated
locally.

To define a Jaguar proxy object, you need to use the Jaguar
proxy object generator, which is available in the Project painter.
Proxy objects cannot be edited directly. To change the definition
for a proxy object, you need to rebuild the proxy object from the
Project painter.

Creating a CORBA-compatible client

If you want to create a CORBA-compatible client, you can use
the JaguarORB object instead of the Connection
object to establish the connection to the server. By using the JaguarORB
object, a PowerBuilder client can access Jaguar in the same way
that a C++ client would.

The JaguarORB object supports two techniques for proxy instantiation:

• Instantiation by using the Naming Service
  To instantiate a proxy by using the CORBA Naming Service,
  you use the Resolve_Initial_References function
  of the JaguarORB object in conjunction with the NamingContext interface.
• Instantiation without using the Naming Service
  To instantiate a proxy without using the CORBA Naming Service,
  you use the String_To_Object function of the JaguarORB
  object in conjunction with the Manager and Session interfaces.

For more information on the Resolve_Initial_References
and String_To_Object functions, see the PowerScript
Reference
.

Creating an EJB-compatible client

If you want your client to behave the way an Enterprise JavaBeans
client would, you can use the Lookup function of
the Connection object.

For more information on the Lookup function, see the PowerScript
Reference
.

Establishing an SSL connection

PowerBuilder also allows you to establish Secure Sockets Layer
(SSL) connections to a Jaguar server. To take advantage of SSL support,
you can use the GetGlobalProperty and SetGlobalProperty functions
of the SSLServiceProvider object. Alternatively,
you can specify SSL connection parameters by using the Options property
of the Connection object.

The SSL protocol allows connections to be secured using public-key encryption
and authentication algorithms that are based on digital certificates. SSL
is a wrapper protocol: packets for another protocol are secured
by embedding them inside SSL packets. For example, HTTPS is HTTP
secured by embedding each HTTP packet within an SSL packet. Likewise,
IIOPS is IIOP embedded within SSL.

For more information on the GetGlobalProperty and SetGlobalProperty functions,
see the PowerScript Reference
.

Microsoft Transaction Server (MTS)

About MTS

A PowerBuilder application can act as a client to a COM server.
The server can be built using PowerBuilder or any other COM-compliant
application development tool and it can run locally, on a remote
computer as an in-process server, or in Microsoft Transaction Server.

You can develop a custom class user object containing business
logic in PowerBuilder and then package the object as a COM object.
A PowerBuilder COM server can include one or more PowerBuilder custom
class user objects. You code the user objects in the User Object
painter and then build the server in the Project painter. You can
also deploy the COM server directly to a local MTS server or create
an MTS package from the Project painter.

Distributed PowerBuilder

About distributed PowerBuilder

A distributed PowerBuilder application typically uses the
services of two separate applications located on different machines:

• Server application
• Client application

The server and client applications work together to perform
tasks for the business user. Typically, the client application handles
interactions with the user while the server application provides
background services to the client. The physical location of application
components is transparent to the business user.

Although the server application usually provides background
services to one or more client applications, the server itself can
also function as a client. In other words, a server application
can act as a client to another server application, while this server
acts as a client to yet another server, and so on.

Server application

The server application has two main components:

• Transport object
• Remote objects

Transport object

The Transport object makes it possible
for the server application to receive client connections and process
client requests for services. The Transport object is instantiated
in a script in the server application. The properties of the Transport
object provide the information PowerBuilder needs to process client requests.
For example, the Transport object can identify the server application and
the communications driver that will be used, and specify how data
will be passed across the network:

Remote objects

In a distributed application, a client can invoke services
provided by remote objects. A remote object
is a custom class (nonvisual) user object that is contained in an
application located on a remote server. A client can invoke functions
that are associated with a remote object just as if they were defined on
a local object.

Remote objects can be invoked across process boundaries or
across computer boundaries. That is, a client application can invoke
a remote object associated with a separate executable on the same
computer or on another computer in a network.

PowerBuilder supports both synchronous
and asynchronous
function
calls against remote objects. When you issue a synchronous call,
the server executes the function immediately while the client waits
until processing has completed. When you issue an asynchronous call,
the server adds the request to a queue and performs the processing
at a later point in time; meanwhile, the client can continue to
do other work while the server handles the request.

Client application

The client application has three main components:

• User interface
• Connection object
• Class definitions for the remote objects

User interface

The client application contains
all of the windows and menus required to interact with the business
user. In addition, the client contains scripts that perform processing
in response to each action that the user takes. For example, these
scripts can specify what happens when a user clicks a button, chooses
an item from a menu, or enters data into a textbox in a window.

Connection object

The Connection object makes
it possible for the client application to connect to a server application
and request its services. The Connection object is instantiated
in a script in the client. The properties of the Connection object provide
the information PowerBuilder needs to establish client connections. The
Connection object identifies the server application, the machine
where the application resides, and the communications driver that
will be used.

Remote object class definitions

Each remote object in a server
application has a corresponding class definition in the client application.
The local copy of the remote object’s definition has the same
name
as the definition in the server. At execution time,
the local definition allows the client to address the remote object
instance just as if it were instantiated locally.

The class definition on the client can contain the complete
implementation of the remote object, or simply a proxy
object that provides a representation of the remote
object’s interface. For distributed processing, only the
proxy object is required on the client.

To define a proxy object, you need to use the proxy object
generator, which is available in the Project painter. Proxy objects
cannot be edited directly. To change the definition for a proxy
object, you need to edit the user object from which the proxy was
created and then regenerate the proxy.

Location transparency

When you deploy a remote object’s class definition
in a client application, the definition on the client has the same
name as the remote object definition deployed in the server application.
By allowing the two definitions to have the same name, PowerBuilder
provides for location transparency. Variables declared
with this object type can hold a reference to a local object instance
or a remote object instance. At execution time, you can instantiate
the object locally or remotely depending on your application requirements.
In order to instantiate the object locally, you must have the complete
implementation of the class on the client machine. If you always
plan to instantiate the object remotely, you only need the proxy
object on the client.

Communications drivers

Distributed PowerBuilder provides several communications drivers:

• WinSock, which provides
  communications in a TCP/IP network through the Windows
  Sockets facility
• NamedPipes, which provides communications through
  the Named Pipes facility
• Local, which allows distributed applications to
  be run locally

OpenClientServer driver The OpenClientServer driver is not supported in Version 7
of PowerBuilder.

Supported drivers

The
level of communications support varies depending on the platform:

Platform	Driver	Server support	Client support
Windows NT 4.0	NamedPipes	Yes	Yes
	WinSock	Yes	Yes
Windows 95	NamedPipes	No	Yes
	WinSock	Yes	Yes
Windows 98	NamedPipes	No	Yes
	WinSock	Yes	Yes
AIX	NamedPipes	No	No
	WinSock	Yes	Yes
HP-UX	NamedPipes	No	No
	WinSock	Yes	Yes
Solaris	NamedPipes	No	No
	WinSock	Yes	Yes

You can use the Local driver on all supported platforms.

Database access

Distributed servers, like all threaded applications, should
be used with threadsafe libraries. When a distributed server accesses
a database using a client API, it must use a threadsafe client library.

---