BAB
|
Arsitektur Distributed Application vs Client Server
Application
|
1
|
In a distributed application, the client and server
work together to perform tasks for the business user. The client handles all
interactions with the user while the middle-tier server provides background
services to the client. Typically, the middle-tier server performs most of the
processing and database access. To invoke the services of the server, the
client calls a method (or function) associated with a component (or object)
that resides on the server.
Client-side logic for enterprise applications must be
as small and efficient as possible to conserve network bandwidth. To accomplish
this goal, applications are partitioned into three parts: presentation,
business logic, and database access. The database resides on the bottom tier of
the enterprise system to maintain and secure the organization's information assets.
The business logic resides in the middle tier or server. The presentation is on
the user's desktop, or top tier, or is dynamically downloaded to the user's
desktop.
The server is then responsible for executing and
securing the vast majority of a corporation's business logic. This makes it a
critical component in the network-centric architecture. The client communicates
with the server, calling middle-tier components that perform business logic.
A Web application is a variation of the distributed
architecture where the client is hosted in a Web browser. PowerBuilder provides
several technologies for building Web applications, including .NET Web Forms deployment
and the Web DataWindow, which provide a thin client solution. The architecture
of your application varies depending on which technologies you decide to use.
For more information, see Chapter 28, “Web Application
Development with PowerBuilder.”
PowerBuilder developers can build clients that invoke
the services of Sybase EAServer, COM+, and other application servers, and build
components (or objects) that execute business logic inside each of these
servers.
PowerBuilder also provides support for building
clients for Enterprise JavaBeans components (EJBs) running on any
J2EE-compliant server.
PowerBuilder and EAServer are fully integrated. A
PowerBuilder application can act as a client to any EAServer component. In
addition, EAServer can contain PowerBuilder custom class user (nonvisual)
objects that execute as middle-tier components.
EAServer hosts the PowerBuilder virtual machine
natively. This means that EAServer can communicate directly with PowerBuilder
nonvisual user objects, and vice versa. EAServer 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.
Components developed in PowerBuilder can exploit
features such as transactions, interoperability, and instance pooling. As shown
in Figure 22-1, any type of client can access any type of component running in
EAServer, regardless of the language used to develop the component.
Figure 22-1: Clients and components in EAServer
For more information, see Chapter 23, “Building an
EAServer Component” and Chapter 24, “Building an EAServer Client.”
J2EE, the Java 2 Platform, Enterprise Edition, is the
official Java framework for enterprise application development. A J2EE
application is composed of separate components that are installed on different
computers in a multitiered system. Figure 22-2 shows three tiers in this
system: the client tier, middle tier, and Enterprise Information Systems (EIS)
tier. The middle tier is sometimes considered to be made up of two separate
tiers: the Web tier and the business tier.
Client components, such as application clients and
applets, run on computers in the client tier. Web components, such as Java
servlets and JavaServer Pages (JSP) components, run on J2EE servers in the Web
tier. Enterprise JavaBeans (EJB) components are business components and run on
J2EE servers in the business tier. The EIS tier is made up of servers running
relational database management systems, enterprise resource planning
applications, mainframe transaction processing, and other legacy information
systems. In PowerBuilder, you can build client applications that use the
services of EJB components running on any J2EE-compliant server. For more
information, see Chapter 27, “Building an EJB client.”
You can also deploy custom class user objects to
third-party application servers on which the PowerBuilder Application Server
Plug-in is installed. The plug-in is a Sybase product that supports several
application servers. Wizards that help you generate application server
components that you can deploy to these servers and proxies that you can use to
build client applications are built into PowerBuilder, but you must install the
plug-in product separately. The wizards and techniques are very similar to
those used for building EAServer components and clients. For more information,
see the documentation for the PowerBuilder Application Server Plug-in on the
Product Documents Web site at http://www.sybase.com/support/manuals/.
A PowerBuilder application can act as a client to a
COM server. The server can be built using any COM-compliant application
development tool and it can run locally, on a remote computer as an in-process
server, or in COM+. For more information, see Chapter 26, “Building a COM or
COM+ Client.”
BAB
|
Membuat Komponen
EAServer
|
2
|
1. About building an
EAServer component
PowerBuilder
provides tools for developing custom class (nonvisual) user objects and deploying
them as EAServer components. You can deploy these components to an EAServer
host running on Windows, UNIX, and Linux operating systems. See “Deploying a
component to EAServer” on page 464.
Limitations
on UNIX
If you plan to deploy components to a UNIX or Linux
server, you should be aware that the PowerBuilder runtime libraries on these
platforms do not support graphical operations or calls to the Windows
application programming interface.
PowerBuilder provides several wizards to facilitate
the development and deployment of EAServer components. All of the wizards build
an EAServer project:
Target wizard,
Creates a new target, a new application object, a new
custom class user object, and a new EAServer project
Object wizard,
Creates a new custom class user object in an existing
target and a new EAServer project
Project wizard,
Creates an EAServer project in which you select one or
more existing custom class user objects
To build and deploy an EAServer component from a
custom class user object, complete the following steps:
1. Use
the EAServer Component Target Wizard to create a new user object in a new
target. Alternatively, if you are working in an existing target, you can use
the EAServer Component Object wizard to create the object.
These wizards also allow you to enter information
exposing the new user object as a Web service.
2. Add
functions, events, and instance variables to the generated user object in the
User Object painter.
3. Test
and debug the object.
4. Deploy
the object to EAServer.
To test or deploy an EAServer component that you
developed in PowerBuilder, create a project object and build the project. You
can create a project object from the Target, Object, or Project wizard.
To deploy a component, open the project in the Project
painter, optionally modify the project settings, and build the project. When
you do this, the EAServer component generator deploys the component interface
and the PowerBuilder implementation of that interface to the target server.
For testing purposes, you can use live editing to
build the project automatically from the User Object painter. This removes the
need to build the project from the Project painter. When live editing is
enabled in the User Object painter, PowerBuilder builds the project for an
EAServer component each time you save the user object. For more information on
live editing, see “Testing and debugging the component” on page 453.
When you create a new user object by using the
EAServer Target or Object wizard, you can optionally create a To-Do List. If
you check the Generate To-Do List box on the last page of the wizard, the
wizard adds tasks to the To-Do List to remind you to complete all phases of
development.
An application server profile is a named set of
parameters stored in your system registry that defines a connection to a
particular EAServer or third-party application server host. Before you use a
wizard to create a component, you should create a profile for the server where
the component will be deployed.
The Application Server Profiles dialog box lists your
defined profiles. You create, edit, delete, and test application server
profiles from this dialog box.
Application
Server Pofiles
|
In the EAServer and Application Server Component and
Proxy wizards, there is a Manage Profiles button on the Choose EAServer Profile
or Choose Application Server Profile page. Clicking this button opens the
Application Server Profiles dialog box so that you can add a new profile or
modify an existing profile without leaving the wizard.
The Profile Name in the Edit Application Server
Profile dialog box cannot be edited. This is because the name is stored in the
project object along with the other properties of the profile. If the profile
name cannot be found in the registry when the project is deployed, the
description in the project object is used.
To create an application server profile:
1. Click
the Application Server Profile button in the PowerBar.
The Application Server Profiles dialog box displays,
listing your configured profiles.
2. Select
Add.
The Edit Application Server Profile dialog box
displays.
3. Type
the profile name, server name, port number, login name, and password (if
required).
4. (Optional)
Select Test to verify the connection.
5. Click
OK to save your changes and close the dialog box.
The Application Server Profiles dialog box displays,
with the new profile name listed. The Application Server profile values are
saved in the registry in HKEY_CURRENT_USER/Software/Sybase/PowerBuilder/12.0/
JaguarServerProfiles.
2. Working with shared
and service components
When you create an EAServer component in PowerBuilder,
the wizard offers you a choice of creating a standard, shared, or service
component.
The EAServer architecture is component-oriented. Each
component maintains its own state. When a single client instantiates several
PowerBuilder objects on the server, EAServer maintains program variable space
for the objects separately. Each PowerBuilder user object running in EAServer
has its own copy of the global and shared variables. The PowerBuilder objects
share no common state. They can communicate only through methods, EAServer shared
components, server files, and databases.
To allow clients to share state information, EAServer
provides support for shared components. Shared components allow multiple
clients to share the same component instance.
EAServer
Manager and the Management Console
In EAServer 5.x, you use EAServer Manager to manage
properties in EAServer. In EAServer 6.x, you use the EAServer Manager plug-in
the Sybase Management Console.
Marking a component as shared in a PowerBuilder wizard
is equivalent to marking it as shared on the General page of the component’s
properties in the Management Console or the Instances page in EAServer Manager.
Only a single instance of the component can be instantiated in EAServer.
Clients (and other server components) access a shared
component as if it were any other kind of 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
EAServer shared components offer many of the same
benefits as PowerBuilder shared objects. PowerBuilder components that you
deploy to EAServer can act as clients to EAServer shared components, as well as
to PowerBuilder shared objects. EAServer shared components can also be accessed
by components and clients that are not imp lemented in PowerBuilder.
However, EAServer does not treat PowerBuilder shared
objects as if they were EAServer shared components. Therefore, the functions
used to manipulate PowerBuilder shared objects (SharedObjectRegister,
SharedObjectGet, and so forth) do not work with EAServer shared components. If
you try to call one of these functions inside a PowerBuilder component running
in EAServer, the request will fail.
A service component performs background processing for
EAServer clients and other EAServer components. EAServer loads service
components at server start-up time.
When you mark a component as a service component in
one of the PowerBuilder wizards, PowerBuilder installs the component as a
service in EAServer at deployment time.
When you create a service component, the wizard marks
the component as shared. If you want more than one instance of a service
component, you can change that setting in the Project painter. Select the
number of instances you want in the Create Instances spin control on the
Components page of the EAServer Component Generator property sheet in the
Project painter. Notice that when you change the number of instances to a
number greater than one, the Concurrency and Automatic Demarcation/Deactivation
are checked. This is to ensure that the component does not encounter threading
issues in EAServer. For more information, see "Threading issues and
component types" next.
The PowerBuilder wizards include three additional
functions for a service component. These functions are defined in the
CTSServices::GenericServices interface and allow you to control the behavior of
background processes associated with the service:
Start EAServer calls the Start function after the
service component has been loaded. You can add logic to this function to
perform start-up initialization for the service.
Run EAServer calls the Run function after the first
invocation of the Start function returns. The Run function allows you to
perform repetitive tasks as a background process. The Run function must
periodically suspend its own execution by calling the JagSleep C function. The
JagSleep function frees the CPU to perform other tasks. To use the JagSleep
function, declare an external function for JagSleep in PowerBuilder. Here is
the syntax to use for the function declaration:
subroutine
JagSleep (Long seconds) LIBRARY
"libjdispatch.dll"
|
Stop This function allows you to stop the execution of
the background process coded in the Run function. You can implement a
service-manager client for your service that calls Stop, Start, and Run so that
the service can be restarted without restarting EAServer. The script for the
Stop function can also clean up any resources that were allocated in the Start
function.
Each instance of a PowerBuilder component executes in
its own session, and each session can support only one thread of execution.
Therefore a single PowerBuilder component instance cannot simultaneously
execute multiple client requests. However, multiple instances of the same
component can each execute a separate client request. When you create a
component, PowerBuilder sets default values for several properties that affect
the way threads are handled in EAServer.
Using
the Thread Manager
You can also use the EAServer Thread Manager to
develop more robust services. See “Using the EAServer Thread Manager” on page
419.
The Concurrency property determines whether multiple
instances of a component can be created to handle multiple client requests.
Checking the Concurrency check box in the wizard or the Project painter sets
the com.sybase.jaguar.component.thread.safe property to TRUE.
Standard
components, For standard components, you can improve performance
by allowing multiple instances of a component to handle client requests. The
default setting for the concurrency property for standard components is
checked, but you can change the setting if you want only one instance of a
given component.
Shared
components, For shared components, only one instance of the component
should be active at any time and therefore only one thread can be executed. The
Concurrency check box is disabled and not checked for shared components.
Service
components, Although service components are usually treated as shared
components, you can choose to create more than one instance of a service
component to improve performance and scalability. There are three options on
the Components page that interact for service components:
Concurrency, Automatic Demarcation/Deactivation, and
Create Instances (the Create Instances option can be changed only for service
components).
When you change the Create Instances option to 2 or
more, the Concurrency check box and the Automatic Demarcation/Deactivation
check box become checked. Multiple instances of the service component can be
created if necessary, and are deactivated after each method call. If you clear
the Automatic Demarcation/Deactivation check box, so that you need to
explicitly deactivate component instances, the Create Instances check box is
reset to 1 and the Concurrency check box is cleared.
There are three other component properties that affect
the handling of threads in EAServer: sharing, tx_vote, and bind.thread.
Bind
Object property not used, An additional property, bind.object, enables client
threads to execute in a single instance but also supports creation of multiple
instances. This property cannot be used for PowerBuilder components and is
always set to FALSE.
When the bind.thread property is set to TRUE, a method
on a component instance must execute on the same thread that created the
instance. This property must be set to TRUE if you are using live editing to
build your component. It should be set to FALSE for components that are
deployed to UNIX servers to improve scalability.
The sharing property identifies whether or not the
component is shared. It is set to FALSE when you select Standard in the wizard
and to TRUE when you select Shared or Service. The only way this property can
be changed in PowerBuilder is by changing the Create Instances setting on the
Components tab page for service components in the Project painter. If either
the sharing or thread.safe property is set to TRUE, the other must be set to
FALSE.
A component that can remain active between consecutive
method invocations is called a stateful component. A component that is deactivated
after each method call and that supports instance pooling is said to be a
stateless component. Typically, an application built with stateless components
offers the greatest scalability. The tx_vote property determines whether the
component is deactivated after every method call. It is set to FALSE
(stateless) if you check the Automatic demarcation/deactivation check box in
the wizard or select more than one instance on the Component page in the
Project painter; otherwise it is set to TRUE (stateful). You can have only one
instance of a stateful service object.
Table 23-1 summarizes the default setting for each
type of component and shows which can be changed.
Table
23-1: Thread-handling properties
No
|
Component
|
bind.thread
|
sharing
|
thread.safe
|
tx_vote
|
1.
|
Standard
|
FALSE,
dapat berubah
|
FALSE,
tetap
|
TRUE,
dapat berubah
|
FALSE,
dapat berubah
|
2.
|
Shared
|
FALSE,
dapat berubah
|
TRUE,
tetap
|
FALSE,
tetap
|
FALSE,
dapat berubah
|
3.
|
Service
(single
instance)
|
FALSE,
dapat berubah
|
TRUE,
tetap
|
FALSE,
dapat berubah
|
FALSE,
dapat berubah
|
4.
|
Service
(multiple
instances)
|
FALSE,
dapat berubah
|
FALSE,
tetap
|
TRUE,
dapat berubah
|
FALSE,
dapat berubah
Jika
diubah jadi
TRUE,
maka angka instance diset
1,
dibagi menjadi
TRUE,
dan berikutnya FALSE.
|
3. Providing support for
instance pooling
4. Providing support for
transactions
5. Accessing a database
from an EAServer component
6. Defining the
component interface
7. Implementing an
existing interface
8. Invoking another
server component’s methods
9. Accessing component
properties
10. Exposing an NVO as a
Web service
11. Testing and debugging
the component
12. Printing data
13. Deploying
a component to EAServer
