Application Development

After creating the repository, distributed applications can create service components. These service components can be called by any client screen in your application.

All distributed application architectures in Panther use service components. However, the steps taken in the editor to define the service components and the coding required to call those service components can differ for each technology. For developers, this means that a service component created for one product can need modifications before it can work with another technology.

This chapter summarizes how a service component is created for different application architectures.

Service Components for JetNet and Oracle Tuxedo

In a Panther JetNet/Oracle Tuxedo application, a service can consist of three parts:

• A routine that implements the service.

• A service component (optional) that provides a physical means of sending, receiving, and processing data.

• A service definition in the JIF.

To create a service, you can: Use the screen editor or the screen wizard to create a service component—the graphical or visual representation of a service.

• Write the service routine that implements the service.

• Define the service in the JIF.

Creating Service Components in JetNet/Oracle Tuxedo

A service component is a graphical service. It looks, for the most part, like the client screen it is servicing. However, service components reside on the server (in a server library such as server.lib) and so are not visible to the user at runtime.

To create a service component using the editor, you must include and identify all the components necessary to implement the service. In addition to building the screen, you must code the service routines and set the appropriate property values on the client screens that will use the service component.

For the most part, service components must have the same contents and property values as the client screens that use them so that it can handle the data that flows between the client screen and the service. Therefore, changes you make on a client screen must also be made to its corresponding service component (if the changes are not implemented by a shared repository).

You can create new service components in the editor by choosing FileNewService Component.

Alternatively, you can use the screen wizard to build service components as you build your client screens.

Writing Service Requests in JetNet/Oracle Tuxedo

Service routines are responsible for receiving data from the client (if sent), performing some task, and returning data to the client (if requested).

Service routines are built for you when you use the screen wizard to create the service components. You can also write service routines the same way you write any other Panther application code. JPL is most convenient, but you can code a service as a C or Java function if that suits your application needs.

For information on writing service requests, refer to Chapter 12, "Creating Service Components," in JetNet/Oracle Tuxedo Guide.

Creating Client Screens

When creating client screens, before any service requests are made, a screen must have a valid middleware connection. In order to open a middleware session for an application user, call client_init, as illustrated in the login screen from the EntBank sample ATM:

The service_call command initiates a service request, as illustrated in this excerpt from the deposit process:

In order to close the middleware connection, call client_exit.

Updating the JIF

After you complete a service request, you must update the JIF to let the application know that the service is available. The JIF contains information about services and service groups and is used when a client makes a service call to determine the parameters, when a server needs to determine which C or JPL procedure should be executed to process the service call, and when a service forwards data to another service.

Figure 12-1 The JIF editor defines the service: its service name, corresponding routine name, service component, and transport methods.

For information on using the JIF editor, refer to Chapter 24, "JIF Editor," in Using the Editors.

Service Components for COM Components and EJBs

COM+ and Enterprise JavaBeans (EJBs) are object-oriented, component-based technologies. A COM component or an EJB has a public interface consisting of methods and properties that other objects or client applications can use to access the component. COM components can be deployed on any Windows system; EJBs can be deployed on IBM's WebSphere Application Server.

Creating Service Components in Component Applications

With Panther, you use a similar process to build service components deployed in these technologies. In fact, on Windows systems, saving your service component allows you to generate both the DLL needed for the COM component and the Java files needed for the EJB.

• In the editor, create a new service component by choosing FileNewService Component.

• Define its properties and methods on the Component Interface window, available by choosing ViewComponent Interface.

• For COM components, define the application directory and other COM-specific settings on the COM section of the Component Interface window.

• For EJBs, define the target directory and other EJB-specific settings on the EJB section of the Component Interface window.

• Write the programming for each method using JPL, C/C++ or Java. Using the JPL verbs receive_args and return_args (or their corresponding C functions sm_receive_args and sm_return_args) you can pass data to and from the client screen.
  

  Figure 12-2 In the editor, you can create the service component, define its interface, and write the programming needed for its methods.

For more information about creating service components in the editor, refer to Chapter 7, "Defining Service Components," in Using the Editors or to the following chapters: Chapter 3, "Building COM Components," in COM/MTS Guide or Chapter 5, "Building Enterprise JavaBeans," in WebSphere Developer's Studio.

Creating Client Screens in Component Applications

In the client screen, you first set the current_component_system property to specify the type of service components, PV_SERVER_COM for COM components or PV_SERVER_EJB for EJBs. You can then call the library functions which:

• Create the component, sm_obj_create.

• Call the component's methods, sm_obj_call.

• Get or set the component's properties, sm_obj_get_property and sm_obj_set_property.

• Destroy the component, sm_obj_delete_id.

• Control error messages, sm_obj_onerror, sm_com_result and sm_com_result_msg.
  

  Figure 12-3 In the client screen, you can instantiate a COM component or Enterprise JavaBean and access its methods and properties.

For more information about creating client screens which call COM components, refer to Chapter 4, "Building Client Screens," in COM/MTS Guide. For more information about creating client screens which call EJBs, refer to Chapter 7, "Building Client Screens," in WebSphere Developer's Studio.

Deploying Components in COM Applications

In a Panther COM/MTS application, a service component consists of:

• A service component, stored in a Panther application library

• A DLL file for the COM component

When you save the service component in a library, you are prompted to build the DLL for the COM component. Creating the DLL also creates the component's type library and the client registration file that is needed for DCOM deployment. Once built, COM components can be deployed under COM, DCOM, or MTS.

In a Panther COM application, both the Panther library containing the service component and the DLL file for the COM component must reside on the COM component server. The COM component must be installed on each server machine; each client must install either the COM component or its location in the registry.

For information about deploying service components in a COM+ environment, refer to Chapter 5, "Deploying COM Components," in COM/MTS Guide.

Deploying Components in WebSphere Application Server

For information about deploying service components and EJBs, refer to Chapter 6, "Deploying Enterprise JavaBeans in WebSphere," and Chapter 8, "Deploying Your Application," in WebSphere Developer's Studio.

Using the Common Component Interface

In order to provide a common programming interface for service components deployed under different technologies, the following C functions will work for both COM components and Enterprise JavaBeans:

• sm_log—Write a message to a server log.

• sm_obj_call—Call a service component's method.

• sm_obj_create—Instantiate the service component.

• sm_obj_delete_id—Destroy the component.

• sm_obj_get_property—Get the component's properties.

• sm_obj_set_property—Set the component's properties.

• sm_obj_onerror—Install an error handler.

• sm_raise_exception—Send an error code back to the client.

• sm_receive_args—Receive a method's parameters from the client.

• sm_return_args—Return a list of parameters back to the client.

You must first specify the current_component_system property to determine the type of components currently in use: PV_SERVER_COM for COM components or PV_SERVER_EJB for EJBs deployed in WebSphere Application Server.