1
Introduction

As a feature of Oracle9i, Oracle Dynamic Services is a Java-based programmatic framework for incorporating, managing, and deploying Internet and Intranet services. Using the Internet as the information source, Oracle Dynamic Services makes it easy for application developers to rapidly incorporate valuable services from Web sites, local databases, and proprietary systems into their applications.

For example, an online financial portfolio can use Oracle Dynamic Services to integrate Internet financial services, such as stock quotes and exchange rates, from different resource providers to calculate the current value of a portfolio in foreign currency. Oracle Dynamic Services is designed to handle dynamic business models with no degradation in the quality of service. Business opportunities can be maximized because this framework permits customized service delivery for flexible application development.

Using the simple, yet flexible framework of Oracle Dynamic Services, application developers can significantly shorten the development cycle for developing applications and increase quality of service by selecting the very best sources. With the Internet becoming the source of choice to compose, deploy, access, and manage business information through service offerings, Oracle Dynamic Services provides the best framework to dynamically manage and customize these Internet services.

Table 1-1 summarizes the tasks or roles of people or organizations in the Dynamic Services framework; the roles of these people and organizations are described later in this section.

Table 1-1 Summary of People or Organizations and Their Tasks or Roles in the Oracle Dynamic Services Framework  

People or Organizations	Tasks or Roles
Service provider (business partner and application developer)	Owns business information content or services to offer Provides the specification for accessing services Provides the content for a service Designs the service package Registers the service package
Service consumer application	Incorporates services into applications in order to deploy them as useful, customized services Designs the flow of the services
Service administrator	Grants service access to service consumer applications Registers the service package Manages the Oracle Dynamic Services registry Manages service consumer applications Performs tuning of the Oracle Dynamic Services engine

1.1 Application Scenarios

Businesses and application developers face a host of business problems and technical challenges in providing information and integrating it into dynamic applications for the Internet or for corporate Intranets.

1.1.1 Business Problems or Technical Challenges

To integrate Internet services or Intranet services into dynamic applications, businesses must be able to:

• Access sources using protocols or APIs
• Manage sources that have different types of sessions with different protocols, have multiple content formats, and do not have guaranteed access
• Deliver specially formatted content to both Web and wireless devices

To access a variety of information sources, businesses must do the following:

• Develop custom code to manage data transformations among different protocols
• Develop custom servers to use these resources
• Implement security, scalability, and performance with every server and then manage them all

In addition, due to the extensive code customization required, businesses rarely can reuse these custom servers.

To manage these information resources, businesses must manage sessions differently for different protocols such as cookies for HTTP. They must be able to handle various content structures, such as DB result sets, XML, Java objects, and so forth; and, they must develop custom solutions for failover service aggregation, caching, and so forth.

To deliver content, businesses must render application results into multiple formats, such as HTML, XML, and so forth. Due to the difficulty involved, they often must utilize consultants to integrate their applications. They must continually change code to adapt to any changes because nothing is configurable; and they face great challenges in being able to scale their applications as their customer base expands.

In summary, it is currently very expensive and an extremely complex operation to develop applications for customers because of the extraordinary number and variety of technical issues involved.

1.1.2 Oracle Dynamic Services Solutions

Application developers who develop e-business, wireless, or portal applications must be able to easily and rapidly aggregate service offerings from business partners and application developers (often referred to as service providers) and provide a single service visible to customers (see Figure 1-1). Application developers, who build their service offerings upon a sound architecture, can quickly develop a collection of services that are easily maintained and managed, and rapidly deployed to meet changing business needs.

Application developers can use Oracle Dynamic Services to create customized delivery of services with the following benefits:

• Separating of application logic from service access for improved application development and easier maintenance
• Modifying available services to solve business problems, thereby reducing the cost and time needed to develop a new application
• Making development of value-added services or applications easier and faster by using services from multiple resource providers
• Enabling improvement of the incorporated services without affecting existing applications

Service consumers, such as an application developer for an e-business, wireless, or portal service provider, provides one aggregate set of services to customers as shown in Figure 1-1, based on specifications provided by the service providers.

Figure 1-1 Application Developers Aggregate Services for Customers

Text description of the illustration ebuss.gif

Oracle Dynamic Services can be used in a number of scenarios including wireless, portal, and e-business applications, where services are integrated with little incremental development cost.

1.1.2.1 Wireless Service Developers

Wireless service developers can use Oracle Dynamic Services to incorporate various useful services. Applications can be built for wireless (handheld) devices to prompt messages, advertisements, or special services based on the geographical location of the user with the handheld device. For example, as a user enters a particular geographic area, an application can prompt specific information to the user's device, highlighting specific local business offerings, such as store sales promotions, a significant weather event, local entertainment, and so forth. Using Oracle Dynamic Services, application developers can aggregate multiple services into a single service, and provide a great breadth of information to customers.

1.1.2.2 Portal Service Developers

Portal service developers, who can deliver a richer, broader, and more dynamic array of information and services to users for specific geographical areas, become more powerful in attracting users to their service offerings. Using Oracle Dynamic Services, portal developers can build applications that contain services to perform specific tasks for the user. These applications can, for example, send confirmation notices when each task is completed. Using a portal search engine, local restaurants of interest can be listed, a reservation made, and a confirmation notice returned along with directions to the restaurant from a specific point of interest. As the success of these kinds of services grows, so does the use of the portal by its customers.

1.1.2.3 e-Business Service Application Developers

As e-businesses grow, application developers can use Oracle Dynamic Services to integrate different services to help its customers through a series of related transactions, such as buying a house. Using an online real estate service, a prospective buyer can locate houses of interest, visit each house through a virtual tour, ask questions, and decide upon a small set of those houses to visit in person. This same buyer can also locate several mortgage lenders, fill out an online mortgage loan application, schedule home inspections, loan closures, movers, and so forth. Every possible real estate service can be used as needed to make the house-buying experience as enjoyable and easy as possible for the home buyer.

Using the service triggering capability of Oracle Dynamic Services, as one task is completed, the next set of related tasks is scheduled, so in turn, each task leads directly to additional related tasks. Application developers for the online real estate broker can write an entire e-business application using Oracle Dynamic Services. The real estate broker needs only to cultivate and manage the relationships among the various service providers.

1.2 Overview of Concepts

Table 1-2 describes the primary components that comprise Oracle Dynamic Services.

Table 1-2 Dynamic Services Components and Their Functions  

Components	Functions
Service consumer application	Acts as a client of the Dynamic Service engine, writes applications using this framework.
Dynamic Services client library	Handles communication between the service consumer application and the Dynamic Services engine. Connects an application with the Dynamic Services engine by opening a connection to it, in a fashion similar to opening a JDBC connection. There are multiple connection drivers available with Dynamic Services that allow different connection paths from applications to the Dynamic Services engine. Applications must register the desired driver and then operate with the returned connection. (See Section 5.1.3 for more information.)
Service package	Contains the information necessary to model a resource as a service component deployable in the Oracle Dynamic Services framework. Contains, in its simplest form, a bundle of files modeled as a local directory. Contains, in its compound form, an additional file, a jar file, containing all Java classes and stylesheets needed by the compound service.
Service registry	Maintains the service package information of registered services that enables Dynamic Services engines to set up and execute a service, and access distributed sources from service providers.
Application profile registry	Maintains service consumer application information about the identity of service consumer applications and their properties. A service consumer application must be registered in the application profile registry.
Dynamic Services engine	Accepts service requests from client applications and does the following tasks: Performs post-processing of service requests to produce the input required by the service (input adaptor) Determines how the service needs to be executed and sets up the service execution environment (execution adaptor) Issues service execution requests to the service providers by transforming the standard service request to the input needed by the service following the underlying protocol (protocol adaptor) Receives the service response from the service providers and does the following task: Transforms the service response for the client and returns it to the caller (output adaptor) Can execute services in synchronous as well as asynchronous mode, depending upon the client application setup.
Service administrator	Uses an extended version of the Dynamic Services client library for communicating with the Dynamic Services engine. Includes an administration shell (DSAdmin utility) and a Web-based administration utility that are both part of the Dynamic Services engine to manage that engine and all its components.

Figure 1-2 shows the Oracle Dynamic Services architecture. Service providers (business partners and application developers) provide services that service administrators register in the service registry using the DSAdmin utility. Application developers create applications using application profiles that service administrators register in the application profile registry. The registry is an Oracle Internet Directory (OID) Lightweight Directory Access Protocol (LDAP) server whose contents are also mirrored in the Oracle9i database for performance optimization. The Dynamic Services Java engine, depending upon the configuration, can reside either inside or outside Oracle9i. Dynamic Services does the following:

• Exposes PL/SQL interfaces to run the Oracle Dynamic Services engine within Oracle9i JVM (see Figure 1-5)
• Exposes Java interfaces when it runs on a local machine hosting the application (thick client library) (see Figure 1-4)
• Acts as a middle-tier Java engine behind a Java servlet with the application using a Dynamic Services thin client library (see Figure 1-6)

Figure 1-2 Oracle Dynamic Services Architecture

Text description of the illustration dsarch.gif

Figure 1-3 shows the major components of Oracle Dynamic Services and the roles of people and organizations in the Dynamic Services framework. These major components and roles begin with the definition of a service package. Both service providers and service consumer applications can define the service package depending on their business relationship. The service administrator takes the service package and registers it in the Dynamic Services engine. Registered services and applications are managed by the Dynamic Services engine. Next, application logic within an application invokes a registered service. Upon the service invocation request, the Dynamic Services engine then contacts the service provider for the specific request.

Figure 1-3 Roles in the Oracle Dynamic Services Framework

Text description of the illustration dysrv_i2.gif

1.2.1 Service Provider

Service providers provide the content and transformations for a service. Service developers and service administrators define the service and load it into the service registry so that the service becomes available to service consumer applications. Service consumer applications can combine many of these services to create value-added services or applications. Service developers need to know the requirements of the service providers for access and authentication in order to create a service in the Dynamic Services framework. Service developers can also specify caching policy, failover, and so forth, to further improve scalability and reliability. The Dynamic Services engine contacts the service providers during service execution according to the specification provided in the registered service package.

1.2.2 Service Registry

The service registry is the storage place for the service package. A service package enables Dynamic Services engines to set up and execute a service, and access distributed information sources from service providers. Service consumer applications can use the client library to perform lookup operations on the service registry. Service administrators can perform updates on the registry without affecting client applications. This feature simplifies the client applications.

1.2.3 Application Profile Registry

The application profile registry is the storage place for the service consumer application attributes. It holds information about the identity of service consumer applications and their properties. A service consumer application must be registered to the Oracle Dynamic Services engine. Before a service consumer application is registered, it must be associated with a database user who has been granted the connect privilege and been granted the DSUSER_ROLE privilege. Then, the named service consumer application must be granted service execution privileges for a service before it can access the named service.

1.2.4 Service Administrator

The service administrator is responsible for managing the Dynamic Services engine and all of its components. The service administrator monitors service failover, manages caching policy, schedules services, and also registers and unregisters services and service consumer applications. The service administrator can listen to the events raised within the Dynamic Services engine to monitor, trace, profile, view service execution, and view service session data. The service administrator also specifies deployment options for services and controls service access to the service consumer applications. The service administrator performs engine performance monitoring, service log reviewing, and so forth.

1.2.5 Service Consumer Application

A service consumer application acts as a client of the Dynamic Service engine. Through the Dynamic Services client API, service consumer applications acquire handles on the services it wants to execute, submits service execution requests, and collects the responses. Service consumer applications need not be aware of the communication protocol used by the Dynamic Services client library and the Dynamic Services engine. The communication protocol is abstracted by the Dynamic Services framework. Service administrators are also unaware of the service providers and other management infrastructure supporting the service execution. This abstraction has been built into the Dynamic Services framework to keep the client applications simple and less vulnerable to the changing business conditions and the changing technical environment that supports their applications.

1.2.6 Dynamic Services Engine

The core of the Dynamic Services framework is the Dynamic Services engine. The Dynamic Services engine is a multithreaded Java engine, which accepts requests from the client applications. The Dynamic Services engine can execute services in synchronous as well as asynchronous modes, depending upon the client application setup. Once a request is received by the engine, the engine determines how the service needs to be executed, sets up the execution environment, and issues execution requests to the service providers. Upon receiving the response from the service providers, the engine transforms the response for the client and returns it to the caller.

1.2.7 Services as Application Components

One of the premier advantages of using Oracle Dynamic Services is the ability to use services as application components. Service administrators can easily change a service provider, because as a service, their access to service consumer applications is easily managed. Application components can be easily aggregated to offer a service composed of many services. For example, an application can offer failover service aggregation among a group of related services should a specific service become unavailable. An application can offer a specific set of services based on certain business conditions, and so forth. Furthermore, specific application components can be easily tailored to deliver content in a format suitable for the device an end user is using. Because these options are available as application components, applications can be rapidly developed and deployed as well as modified to fit changing business needs. The ability to easily build, maintain, and manage a collection of application components for rapid deployment is what Oracle Dynamic Services offers to application developers.

1.2.8 Communication Between the Service Consumer Application and the Dynamic Services Engine

The client library is responsible for handling the communication between the service consumer application and the Dynamic Services engine. The communication is performed as synchronous or asynchronous messages between the client library and the Dynamic Services engine. Service consumer applications can communicate with any available Dynamic Services engine provided they are authorized to use that particular instance. Once connected, service consumer applications have the access and privileges that service administrators assign to them. These features allow distributed client access to a large number of Dynamic Services engines, and can be used to implement client failovers or load balancing.

1.2.9 Communication Between the Service Administrator and the Dynamic Services Engine

The service administrator interfaces with the Dynamic Services engine through the administrator tools. The administrator tools use an extended version of the client library to communicate with the Dynamic Services engine. The Oracle Dynamic Services administrative shell, shipped with the Dynamic Services engine, is an example of these tools. This is an interactive, scriptable, easy-to-use command-line shell that includes online help. Some of the features of the shell are also available from a Web-based administration utility, which is shipped with the Dynamic Services engine.

1.3 Dynamic Services Implementation Overview

Oracle Dynamic Services has three possible deployment modes:

• Java deployment view (see Section 1.3.1)
• PL/SQL deployment view (see Section 1.3.2)
• Java (HTTP/Java Messaging Services (JMS)) Deployment view (see Section 1.3.3)

The following is a brief description of the underlying technologies of the high-level components for each implementation.

Dynamic Services Engine

The Dynamic Services engine can be deployed as any of the following three engine types:

• A Java engine running on the machine hosting the application (thick client library) (see Figure 1-4)
• A middle-tier Java engine behind a Java servlet (see Figure 1-6)
• A Java engine running within Oracle9i JVM (see Figure 1-5)

Different options can be selected by service consumer applications based upon their application needs. A unique feature of the Dynamic Services framework is that service consumer applications can switch from one environment to another without recompiling or even restarting their applications. This gives the service consumer application added flexibility to try out various options, to see which best fit their applications.

Dynamic Services Service and Application Profile Registries

The service registry and application profile registry are deployed as directories in the Oracle Internet Directory (OID) server. The access control list of OID is used for access control, allowing service administrators to choose the services visible to a particular service consumer application. Managing services and service consumer applications in OID allows multiple instances of Dynamic Services engines to work in a synchronized fashion, giving an open, scalable option to service consumer applications. For performance reasons, the registry data is cached in an Oracle9i instance accessed by the Oracle Dynamic Services engine at service execution time. This cache can be synchronized automatically at the start of the Dynamic Services engine, or service administrators can synchronize it through their console, as required.

Communication Between Service Consumer Applications and the Dynamic Services Engine

The communication between the Dynamic Services engine and the service consumer applications is abstracted by the Dynamic Services client library. By registering a Dynamic Services driver, a service consumer application can dynamically change the underlying communication protocol used by the client library to communicate with the Dynamic Services engine. Supported communication protocols include HTTP (see Figure 1-6), AQ/JMS (see Figure 1-6), and direct Java access (see Figure 1-4). Service consumer applications have complete control over the drivers they choose within their programming framework, and they can switch to any driver. Service consumer applications can use multiple drivers to talk to multiple Dynamic Services engines, at the same time, if required.

Service consumer applications can access services through different paths depending upon their Dynamic Services engine deployment. The Dynamic Services engine allows access to the services in PL/SQL and Java for programming purposes.

1.3.1 Java Deployment View

Figure 1-4 shows a basic Java deployment view of the Oracle Dynamic Services framework. The Oracle9i database serves as a registry cache, communicating with the OID Lightweight Directory Access Protocol (LDAP) server hosting the registries. The service consumer application contains application logic that uses the services through direct Java calls.

In this case, the service consumer application uses the Dynamic Services thick Java client library, which contains the Dynamic Services execution engine. Service providers run in their own servers.

Figure 1-4 Java Deployment View of the Oracle Dynamic Services Framework

Text description of the illustration dysrv_i3.gif

1.3.2 PL/SQL Deployment View

Figure 1-5 shows a PL/SQL deployment view of the Oracle Dynamic Services framework. The Dynamic Services engine runs in the Oracle9i JVM, with its functions exposed as a set of Java stored procedures. The Oracle9i database serves as a registry cache, communicating with the Oracle Internet Directory LDAP server hosting the registries. The service consumer application contains application logic, which makes use of the services through PL/SQL calls. Service providers run in their own servers.

Figure 1-5 PL/SQL Deployment View of the Oracle Dynamic Services Framework

Text description of the illustration dysrv_ic.gif

1.3.3 Java (HTTP/Java Messaging Services (JMS)) Deployment View

Figure 1-6 shows a Java (HTTP/JMS) deployment view of the Oracle Dynamic Services framework. The Dynamic Services engine runs in a Dynamic Services gateway (middle tier) that supports HTTP, HTTPS, and JMS as communication protocols. The Oracle9i database serves as a registry cache, communicating with the Oracle Internet Directory LDAP server hosting the registries. The service consumer application contains application logic, which makes use of the services through the Dynamic Services thin Java client library, and can execute services remotely in other systems.

In this case, service execution requests are forwarded to the Dynamic Services gateway, which executes the service and returns the response. The communication between the service consumer application and the gateway is handled by the Dynamic Services thin Java client library.

Figure 1-6 Java (HTTP/JMS) Deployment View of the Oracle Dynamic Services Framework

Text description of the illustration dysrv_i4.gif

Figure 1-7 shows the asynchronous deployment communication (JMS) that occurs when the DSJMSDriver allows for asynchronous access to services using a Dynamic Services gateway in the form of a JMS daemon. The mode of operations with this driver lets it submit requests asynchronously to an AQ/JMS queue in a remote database. The driver assumes the existence of this JMS daemon that listens asynchronously to the same queue where requests are being submitted. The daemon takes on the role of the Dynamic Services engine and processes the request, generates a response, and submits that response into another queue that the DSJMSDriver listens to asynchronously. On the service consumer application side, therefore, listeners can be registered to be informed when the response is returned.

Figure 1-7 Asynchronous Deployment Communication (JMS)

Text description of the illustration dysrv_i8.gif

1.4 Using Multiple Dynamic Services Engines

To increase scalability, you can install multiple Dynamic Services engines that communicate with a central master Lightweight Directory Access Protocol (LDAP) registry (see Figure 1-8). See Section 4.5 for installation and configuration information for setting up LDAP with OID and configuring the Dynamic Services registry to use LDAP.

The basic steps for using LDAP as a central master registry are as follows:

1. The service administrator registers a service through one Dynamic Services engine.
2. This Dynamic Services engine updates the central registry, then broadcasts a synchronize message to all other instances of the Dynamic Services engines.
3. All other instances of Dynamic Services engines synchronize their registry cache with the central registry.

Figure 1-8 Using Multiple-Instance Deployment of Oracle Dynamic Services Engines

Text description of the illustration dysrv_i5.gif

1.5 How to Get Started with Oracle Dynamic Services

The remaining chapters in this guide begin by guiding you through a basic installation and configuration of Oracle Dynamic Services (Chapter 2), then showing you how to get started by configuring and running the DSAdmin utility and registering a new service, browsing registered services, and executing a registered service (Chapter 3).

Advanced topics are discussed in the remaining chapters, guiding you through advanced installation and configuration options (Chapter 4), describing how to use the Java and PL/SQL Web application development interfaces (Chapter 5), showing you the process of service development (Chapter 6), and finally describing service administration tasks (Chapter 7).