JavaServer Pages (JSP) files invoke Service Component Architecture (SCA) components using stand-alone references in the module assembly.
Before you begin
The following instructions apply only to stand-alone references using WSDL references. The code will not work for stand-alone references with Java interfaces.
About this task
The JSP file has to be deployed in the same EAR file as the module assembly. Do not copy the sca.references file to another EAR file. The file will not work outside the module that it belongs to. If the Web project is in another EAR file, then the JSP file is in another module, and imports and exports are required for it to work with services in another module.
Here are the steps for adding the JSP file to the module:
Procedure

1. Create a Web project.
2. Build the JSP file in the Web project. If you are importing the code, import it into this Web project. See the example of code below.
3. Open the module (which has the stand-alone references) with the dependency editor. Add a dependency on the Web project as a J2EE project. Make sure that the Deploy with Module check box option is selected so that the Web project will be added to the EAR file.

Example
Here is an example of some JSP code that uses the stand-alone references in the module assembly:

In IBM Integration Designer, you can export modules and libraries as .zip files and then use the serviceDeploy command of Process Server or WebSphere® Enterprise Service Bus (mediation modules only) to build and deploy them as EAR files.

Before you begin
Before you export any modules as .zip files for deployment using the serviceDeploy command, ensure that you have reviewed the information about dependencies in the topic "Deployment."

Procedure

1. From the File menu, select Export. The Select page of the Export wizard opens.
2. In the Select page, expand Business Integration and select Integration modules and libraries.
3. Click Next. The Export Integration Modules and Libraries page opens.
4. The intended usage of the exported content determines the export format. Select the Command line service deployment to export the content as .zip files.
5. In the Select projects to export list box, select the check box beside the name of each project that you want to export and click Next.
6. In the Target file field, specify a path name for the exported .zip file. Alternatively, you can click Browse to navigate the file system and select a target file.
7. If you have changed any of your generated J2EE projects, select the Include generated J2EE projects from workspace check box. The names of the J2EE projects will be displayed in the Additional projects list box. By default, all dependencies are automatically included in the serviceDeploy zip file. These dependencies are required to successfully build an EAR file from the zip file and deploy it using the serviceDeploy command-line tool.
8. If there are global shared libraries that the exported content depends on, these libraries are listed. These libraries must be deployed to the runtime according to these instructions: http://www-01.ibm.com/support/docview.wss?rs=2307&uid=swg21322617
9. Click Finish to export the selected modules and libraries in a zip file for command-line service deployment.

For training on IBM Lombardi mail us at [email protected]

Understand what capabilities IBM® Business Process Manager provides for business process management, and how the various phases of business process management, such as creating and deploying process applications, relate to one another.

The process application is the fundamental container for processes and their components in IBM Business Process Manager. Process designers create process applications in the authoring environments, and may include services, tasks, and artifacts needed to support execution.

Advanced Integration Services are implemented in Integration Designer and associated with process applications. From the Process Center, process applications are deployed to the Process Server, which is the process runtime environment for IBM Business Process Manager.

Similarly, automated processes created in Integration Designer can use human activity flows that have been developed in IBM Process Designer.

The components of IBM Business Process Manager provide a unified BPM repository, tooling for authors, administrators, and users, and a runtime platform. Different configurations of the product support different levels of complexity and involvement with business process management.
                                                                                                                                                         Click here For More On Product Overview 

When developing processes in Process Designer, you need to plan for the eventual installation of your process applications on servers in your test and production environments.

These samples and tutorials will help you get started with IBM Business Process Manager.

For training on IBM Lombardi BPM mail us at [email protected]

A mediation module is a business integration project that is used for development, version management, organizing resources, and deployment to the runtime environment. It contains flows that intercept and modify messages between service consumers (exports) and service providers (imports). Mediation modules can be deployed to the WebSphere® ESB or the IBM Business Process Manager.

Procedure
To create a mediation module, complete the following steps:

1. From the menu, click File > New > Project > Mediation Module to open the New Mediation Module wizard.
2. Enter a name for Module name.
3. Keep the Use default selection for the location of the module.
4. Make a selection from the Target Runtime list.
5. Keep the Create mediation flow component selection.
6. Click Next to open the Select Required Libraries wizard. Select the libraries that contain resources that the new mediation module will use.
7. Click Next.
8. If you want to have your new mediation module referenced by an integration solution, select the Select an integration solution check box and then choose an integration solution from the Integration solution list.
9. Optional: If you want to change the business object parsing mode, click Next.
   1. Select a parsing mode.
   2. Click Finish.
10. Click Finish.

Results
The new mediation module appears in the Business Integration view. The libraries you selected are added as dependencies.


For training on IBM Lombardi mail us at [email protected]

In IBM Integration Designer, you can export modules as EAR files for server deployment or as service Deploy files for command-line server deployment. You can also export modules as project interchange files so that you can share projects for development purposes. If you are exporting modules for adapter deployment, you might need to configure dependency libraries for the adapter on the server.

About this task
The following topics explain how to export modules for deployment or development and how to configure dependency libraries for adapters that have been deployed on a server.

If you want to author artifacts in IBM Integration Designer and deploy them to an IBM Business Process Manager runtime environment, the major versions of the two products must match.

• Exporting modules as EAR files
  In IBM Integration Designer, you can export modules and libraries as EAR files and then deploy them on Process Server or WebSphere Enterprise Service Bus(mediation modules only) using the administrative console or command-line tools.
• Exporting modules and libraries as serviceDeploy files
  In IBM Integration Designer, you can export modules and libraries as .zip files and then use the serviceDeploy command of Process Server or WebSphere Enterprise Service Bus (mediation modules only) to build and deploy them as EAR files.
• Exporting modules and libraries as project interchange files
  In IBM Integration Designer, you can export modules and libraries as project interchange files. This enables you to share modules and their projects for development work.
• Configuring dependency libraries for adapters
  The deployed adapter running in the server requires the same dependency libraries as it does in IBM Integration Designer to process requests. The method for adding these library files depends on the mode of the adapter deployment: deployed as a stand-alone adapter; or embedded in the EAR file.

For training on IBM Lombardi mail us at [email protected]

Imports and exports require binding information. Binding information specifies the means of transporting the data from the modules.

Bindings for imports and exports have different purposes. An import binding describes the specific way an external service is bound to an import component. An export binding describes how that export (or service) will be published or made available to clients outside the module.

A key to service-oriented architecture is the ability to expose services with a number of binding options and the ability to call services using industry norms. Binding types are associated with imports and exports using the assembly editor.

The kind of binding determines what kind of client is supported; for example, a web service binding makes the service available to any web-based client, while an SCA binding makes it available to other SCA modules. Import bindings tell the SCA runtime processes how to access an external service. For example, if you publish a service with an SCA export binding, an import with a JMS binding will not be able to successfully call it. The SCA binding is the default binding; if no binding is specified for an export, the runtime process assumes an SCA binding when the module is deployed. You can use an import with an SCA binding to access a service in another SCA module. You can use a web service import binding to bind an external web service to an import. The import binding does not have to be defined at development time; it can be defined at deployment time.

Creating an export specifies that a component or import is being externalized for use outside the module. The main reason for specifying the SCA binding type on the export is that it allows for the most efficient cross-module calls of the exported entity. If, for example, you specify the web service export binding, the component or import is invoked across the web instead of through a construct that approximates a direct call. A reason to not use the SCA export binding would be to allow clients outside of the SCA programming model to invoke the exported component or import. Note that you can create more than one export for a component or import, so you could effectively export the component or import with more than one binding if you specify a different binding type on each of the exports. You could even choose to export one set of interfaces with one binding type and another set of interfaces with another binding type. Because the SCA bindings are easy to use (for example, the SCA export binding requires no binding information), you might choose to use them for prototyping work, and replace or augment them as the prototype later evolves.

If modules are running on the same server, an SCA binding is the easiest and fastest to use. The same is also true of modules deployed in the same cluster. If you want a service to be published as a web service and to be available to other modules in the same cluster, consider using two exports, one with a web service binding and one with an SCA binding.

The enterprise service discovery wizard creates imports and exports representing a service on an EIS system. These bindings are discussed in "Accessing external services with adapters." The bindings created are of an EIS type. An EIS binding provides synchronous communication with the service on the EIS system.

Java Message Service (JMS), WebSphere® MQSeries® (MQ) and WebSphere MQSeries JMS (MQ JMS) bindings are used for interactions with messaging systems, where asynchronous communication through message queues are critical for reliability. These bindings are discussed in "Accessing external services with messaging systems."

Another binding is the HTTP binding. The Hypertext Transfer Protocol (HTTP) is a widely-used protocol for transferring information on the web as defined by the World Wide Web Consortium (W3C). Today many standard HTTP requests such as GET, POST, PUT, and DELETE are a part of this widely used protocol. This binding is discussed in "HTTP data binding."

An import can also have a stateless session bean binding, but an export cannot.

Binding resource configurations extend the supplied bindings with bindings that you can create yourself. For information on binding resource configurations, see "Working with configurations that access external services."

The assembly editor lists the bindings supported and simplifies the creation of them when you want to create an import or export. The import and export have different icons to indicate the type of binding. The following image shows an import and an export with no bindings: 
A properties view in the assembly editor displays the binding information of any import or export.

The deployed adapter running in the server requires the same dependency libraries as it does in IBM® Integration Designer to process requests. The method for adding these library files depends on the mode of the adapter deployment: deployed as a stand-alone adapter; or embedded in the EAR file.

In the test environment, the tools will automatically configure the required dependency libraries for you except when native libraries are used, for example, with the WebSphere Adapter for SAP Software or the WebSphere Adapter for JDBC, if using a Type 2 driver that uses native libraries.

For a production environment or testing on a remote server, however, you must add references to the dependency libraries. The following sections show you how to configure the dependency libraries for adapters with either stand-alone deployment or EAR deployment.

• Stand-alone deployment
• EAR deployment using the administrative console

Stand-alone deployment
The dependency libraries may be added to the stand-alone deployed adapter either during initial deployment of the RAR file or by configuring the adapter properties after it has been deployed.

To set the values during initial deployment of the RAR file, from the navigation of the administrative console, select Resources > Resource Adapters > Resource adapters. Install the adapter and, afterwards, add the paths to the Class path and Native path sections, before saving your configuration.

The class path is used to point to JAR files and the native path is used to point to folders containing native libraries, such as *.dll and *.so, as shown in the following figure:

If a native library is dependent on other native libraries, the dependent libraries must be configured on the LIBPATH of the JVM hosting the application server (rather than on the native path shown in the above figure) in order for that library to load successfully. You should configure an environment entry by selecting Servers > Application Servers > server_name > Java and Process Management > Process Definition > Environment Entries(where server_name is the name of the server; for example, server1). On the Environment Entries page, create a new environment entry to specify the LIBPATH of the JVM.

To set the dependency library path files after the adapter has been installed on the server, use the administrative console to modify the values for the adapter.

From the navigation of the administrative console, select Resources > Resource Adapters > Resource adapters. Select the installed adapter and, afterwards, add the paths to the Class path and Native path sections before saving your configuration, as shown in the following figure:

EAR deployment using the administrative console
If the dependency libraries can be loaded by the application, then you do not need to take any further steps. The dependency libraries are included in the connector module.

However, when native libraries are used, the dependency libraries are added as WebSphere shared libraries. You define the shared library containing external dependencies and associate them with the server.

To use the administrative console to add the dependency libraries as a shared library, follow these steps.

1. Make sure the dependency files are available on the server machine in the separate folder. If needed, copy dependency files on to the server machine.
2. Define variables, one for the class path and one for the native path. The class path is a semicolon-separated list of absolute file paths to each library. For the native path, the value points to folders. To define a variable, select Environment > WebSphere Variables, which opens the WebSphere Variables page. Select the scope of your variable, for example, widCell. If you are uncertain about which scope is suitable, a link on the page provides help on the scope settings. Click New and create your variable pointing to a dependency library. Then click Apply and Save to add the variable to the list of variables on the server.

Define the shared library through the server administrative console using the variables defined in the previous step. Select Environment > Shared Libraries. As in the previous step, you must select your scope. Then click New. Create the shared library and click Apply and Save to add it to the server.

Deploy the EAR to the server.


For training on IBM Lombardi mail us at [email protected]

In IBM Integration Designer, you can export modules and libraries as project interchange files. This enables you to share modules and their projects for development work.

Before you begin
Before you export any content as project interchange files, you should ensure that you have reviewed the information about dependencies in the topic "Deployment."Note: It is advised that you do not select the staging projects if you are using the Rational® Application Developer's project interchange export function. Although it is possible to import staging projects, it is not recommended. When importing projects from a project interchange file, the staging projects will be regenerated for you.

IBM integration Designer provides a filtering function known as capabilities. With capabilities, you can choose to hide tools not used during business integration application development. At any time, you can choose to show those tools again.

IBM® Integration Designer supports a range of servers and, runtime deployment environments. Tools are grouped into predefined categories called capabilities according to the target runtime that they support. You use capabilities to filter your development environment, so that you see only the tools that you need. In order to access a tool, its capability must be enabled.

When you install Integration Designer, you are asked to select a runtime environment. The capability that corresponds to your selection is enabled. The first time you start IBM Integration Designer, the tools that are part of that capability are available, and the other tools are hidden. The Getting Started page is also customized according to the runtime (and capability) that you selected during installation. You can enable or disable capabilities at any time according to your needs.

IBM Integration Designer provides these capabilities:

• IBM Process Server Development

         Includes WebSphere ESB development tools. Additionally, provides tools, functions, and related documentation       
         to create and test applications that can be deployed to this server.

           Use this capability if you want to work with business processes created in IBM Process Designer and the IBM  
         Process Center repository. Also use this capability if you want to work with applications that targeted the   
         WebSphere Process Server in previous releases.

        The IBM Process Server development capability includes:

• Process applications and toolkits.
• Modules, mediation modules and libraries
• Business Objects
• Interfaces and interface maps
• Data maps: Business object maps, Relationships and XML maps.
• Customized visual snippets
• BPEL Processes
• Mediation flows
• Human tasks
• State machines
• Business rules
• Business Vocabularies
• Business Calendar
• Java Components
• Selectors
• Enterprise Access artifacts and adapters

• WebSphere ESB  Development

         Provides tools, functions, and related documentation to create and test applications that can be   
          deployed to the WebSphere Enterprise Service Bus and the IBM Process Center :

• • Mediation modules and assemblies
  • Libraries
  • Business Objects
  • Interfaces
  • Business object and XML maps
  • Mediation flows
  • Java Components
  • Enterprise Access artifacts and bindings
• WebSphere DataPower

          Provides tools, functions, and related documentation to create and test artifacts that can be deployed to 
          WebSphere DataPower:

• DataPower libraries
• Business Objects
• Interfaces
• XML maps

To see the capabilities that are available, follow these steps:

1. From the Help menu, select Getting Started > IBM Integration Designer.
2. In the Getting Started page that opens, the section What environment do you want to use? shows the current capability that is enabled.

In IBM Integration Designer, you can export modules and libraries as EAR files and then deploy them on Process Server or WebSphere® Enterprise Service Bus (mediation modules only) using the administrative console or command-line tools.

Before you begin
Before you export any content as EAR files, you should ensure that you have reviewed the information about dependencies in the topic "Deployment."
Procedure

1. From the File menu, select Export. The Select page of the Export wizard opens.
2. In the Select page, expand Business Integration and select Integration modules and libraries.
3. Click Next. The Export Integration Modules and Libraries page opens.
4. The intended usage of the exported content determines the export format. Select the Files for server deployment to export the content as EAR files.
5. In the Select projects to export list box, select the check box beside the name of each project that you want to export and click Next.
6. Specify a file name for each archive, or leave the default file names as shown.
7. In the Target directory field, specify the path and name of the target directory where you want to export the EAR files. Alternatively, you can click Browse to navigate the file system and select a target directory.
8. Click Finish. The selected modules and libraries are exported as EAR files for server deployment.

For training on IBM Lombardi mail us at [email protected]