wps-bestpractices-101223065318-phpapp02

Technical Overview of

WebSphere Process Server,

WebSphere Integration Developer and

Best Practices

Presented by:MIRACLE SOFTWARE SYSTEMS, INC.

February 16, 2007

Proprietary and ConfidentialThe content within is the property of Miracle Software Systems , Inc.

UNAUTHORIZED REDISTRIBUTION IS PROHIBITED

Revision History

Date Author Description01/20/07 Sandeep

GuglothDocument Consolidated

Statement of Confidentiality

This document contains information that is proprietary. As a result, this document shall not be duplicated, in whole or in part, for any purpose other than to evaluate Miracle Software Systems, Inc.

This restriction does not limit the rights of the recipient to use information contained in the data if it is rightfully obtained from another source without restriction.

Copyright 1994 - 2007 Miracle Software Systems, Inc. All rights reserved.

Table of contents

1. Overview of On-Demand Business:-----------------------------------------------------------------------------------------4

2. Key business attributes:---------------------------------------------------------------------------------------------------------4

3. Key technology attributes :-----------------------------------------------------------------------------------------------------5

4. WebSphere Process Integration programming model and Components---------------------------------------8

5. WebSphere Process Server / WebSphere Integration Developer Components-----------------------------10

6. WebSphere Process Server Best Practices and Naming Convention------------------------------------------11

7. WebSphere Process Server and Integration Developer Performance Tuning-------------------------------13

8. Reference:---------------------------------------------------------------------------------------------------------------------------18

WebSphere Process Server Best Practices of 21

1. Overview of On-Demand Business:

The vision of On Demand Business is to enable customers to succeed in an environment with an unprecedented rate of change. Businesses want to focus on core competencies, reduce spending, and reuse existing information in new ways without a major overhaul of their existing infrastructures. There exists a constant pressure to juggle the often conflicting demands to provide flexibility, cost savings, and efficiency. The sections that follow outline the key business and technical attributes that provide the basis for the on demand message.

Figure 1-1 identifies the key components of On Demand Business.

2. Key business attributes:

From a business perspective, On Demand Business is about providing a way for companies to realign their business and technology environments to match the request for reusable business functionality. Business drivers can be summarized with the following key elements:

Focused

The enterprise can focus on their core competencies: what makes them successful and what makes them unique. Strategic alliances are formed to provide needs external to these core competencies.

Responsive

The business can respond with agility to customer demands, market opportunities, or external threats. These decisions are guided through insight-driven decision management features.


Variable

The enterprise can achieve operational and business process flexibility and adapt variable cost structures (fixed to variable) to provide a high level of operational efficiency.

Resilient

The business can respond robustly to changes in both business and technical environments, managing changes and threats with predictable outcomes. Companies can achieve these business imperatives by exploiting current technological developments while drawing on experiences that have been learned from past architectural builds.

3. Key technology attributes :

The business drivers of On Demand Business must be supported by a well-defined technical infrastructure. The following key technological attributes deliver the flexibility, responsiveness, and efficiency that organizations require:

Integration

Virtualization

Automation

Open standards

Figure 1-2 provides a high-level overview of the range of each On Demand Business attribute.


Integration

The fundamental component of an infrastructure designed for On Demand Business is integration. “An enterprise whose business processes, integrated end-to-end with key partners, suppliers, and customers, can rapidly respond to any customer demand, market opportunity, or external threat.”

Integration can occur at various levels:

People

To function at an operating level that is suitable for On Demand Business, human-to-human and human-to-process interaction requires integration throughout the various levels that is not limited to those who use the finished products. Business partners, customers, and employees are all important resources for the value chain provided by On Demand Business. For example, integration can occur for developers through open tooling paradigms that are based on open standards, for business partners through the creation of horizontal processes, and for employees through collaboration.

Process

Recurring elements (security, service level, monitoring, and so on) can be shared by applications to provide horizontal services for decoupling these reusable application components. The use of SOA and Web services to implement these processes, including the emerging Business Process Execution Language for Web Services (BPEL4WS), is likely to facilitate more rapid changes in these processes so that the business can respond with agility to changing market conditions.

Applications

Organizations have invested enormous resources and capital into custom designed and off-the shelf applications. The application integration goal is to leverage, rather than replace, these assets by providing ways of connecting, routing, and transforming the data that is stored or shared among them. Applications sit on disparate systems in an enterprise or are installed throughout many enterprises.

Systems

Systems manage, process, and deliver data to the people and applications in the solution environment. An On Demand Business Operating Environment requires the system to be invisible to the elements that interact with it.

Data

Data is the primary business element of a system. The data is the source of the information and can more easily be shared through the adoption of standards specifications.

Virtualization

Various areas of technology in our lives exploit virtualization concepts, including cell phones, personal digital assistants, wireless connectivity, printers, and so forth. Aspects of virtualization draw on widely adopted architectural concepts, including object oriented design and development, Web services, and XML.

There is a spectrum of virtualization that begins with independent stand-alone systems on one side (a large mainframe system, perhaps) and grid computing on the other. In the middle are varying degrees of client-server implementations.

A grid paradigm, an absolute example of on demand virtualization, is a collection of distributed computing resources that are available over a local or wide area network and that appear to a user or application as one large virtual computing system.

The Internet, the most widely recognized example of virtualization, provides a virtual network that supplies access to content and applications.


The vision is to create virtual dynamic organizations with secure, coordinated resource-sharing between individuals, institutions, and resources. Grid computing is an approach to distributed computing that spans locations,organizations, machine architectures, and software boundaries.

Figure 1-1 depicts virtualization as a set of virtualized resource pools based on:

Servers

This might include partitioning, hyper visors, VM OS, emulators, I/O virtualization, virtual Ethernet, and so forth.

Storage

Here, the focus is on the addition of intelligence and value in the network.

Distributed systems

This includes Web services, scheduling, provisioning, workload management, billing and metering, and transaction management. The goal of grid computing, and thus on demand virtualization, is to provide unlimited power, collaboration, and information access to everyone connected to a grid.

Automation

Autonomic computing addresses the need of an organization to limit the amount of time and cost that occurs as a result of: Over provisioning, New applications and highly skilled labor, Disparate technology platforms even within one organization, Focus on maintenance, not problem resolution, Complexities in operating heterogeneous systems

So how can organizations begin to address these common concerns by using On Demand Business? This is where autonomic computing comes in. Autonomic computing can be summarized by four key components:

Self-healing

For a system to keep functioning, it must detect, prevent, and recover from disruptions with minimal or no human intervention. This requirement is directly proportional to increased business dependence on technology

Self-configuring

The system can adapt dynamically to changing environments, add and remove components to and from the systems, and change the environment to adapt to variable workloads.

Self-optimization

Configuration that maximizes operational efficiency, including resource tuning and workload management, alleviates the constant drain on resources to perform routine tasks. The goal is to tune systems to respond to the workload changes. Systems must monitor and self-tune continuously, adapting and learning from the environment around them.

Self-protecting

Security is one of the inhibitors of the adoption of SOAs as organizations prepare themselves to share data externally. Self-protection requires the system to provide safe alternatives for securing information and data. Self-protecting automation works by anticipating, detecting, identifying, and protecting systems from external or internal threats.


Open standards

Open standards affect the On Demand Business Operating Environment across the previously defined levels, including automation, integration, and virtualization. Each of these elements leverage open standards specifications to achieve their objectives. Open standards are the key element of flexibility and interoperability throughout heterogeneous systems. The global adoption of a standard specification enables the disparate systems to interact with each other. The underlying platforms might be completely different and independent, but open standards enable processes to be built despite (or because of) these differences. Open standards provide the On Demand Business Operating Environment with a standard, open mechanism to invoke system services.

4. WebSphere Process Integration programming model and Components

The Key to Business Flexibility

“The flexibility to treat elements of business process and the underlying IT infrastructure as standardized components (services) that can be reused and combined to address the changing business priorities.“

The basis of Service Oriented Architecture starts with business processes. A service is a business task that provides some business function through a well defined interface. The use of the service is independent of the IT infrastructure needed to accomplish the task. Each service then becomes a building block that, when combined with other services can provides a flexible solution to real business problem, allowing the creation of new and modified processes easily. A key to this is the strong link between the uses of services and how those services make use of the underlying IT infrastructure. The use of the standards based technologies; including Web Services, help to make the SOA vision a reality.

Programming Model today

WebSphere Process Integration introduces a new programming model. It is extremely important to understand this fundamental change in how applications are developed in order to understand the functionality provided in WebSphere Process Server and WebSphere Integration Developer. The figure depicts the programming model as it exists without WebSphere Process Integration. Manipulation and handling of data is the core purpose and reason for all business processes.

There are currently various ways that data can be represented, including a JDBC row set from a relational database, a JMS message, JCA data coming in from an external application, a JAXB object, or an EJB entity bean.


Multiple ways of representing data require multiple ways of interacting with data. Invocation is the way in which a request is made from one piece of code to another. There are a variety of ways to invoke processes to obtain and work with data.

Current methods of invocation include EJB stateless session beans, JAX-RPC, JDBC for communicating with databases, JCA for adapters, and JMS for messaging.

To build a solution you must be able to put together multiple invocations for data access and the processing that acts upon that data. Composition defines how to assemble a series of invocations that work on data to construct a complete process.

This can also be done in a variety of ways, including using Java with either a Java Bean or a stateless session bean, WebSphere Interchange Server collaborations, Flow Definition Language, and Business Process Execution Language. All business process solutions are a composition of invocations that operate on data. With so many different mechanisms for doing this there is a need for many different kinds of skills to develop business processes. Also, the form data takes can dictate the form of invocation and composition that might not always yield the optimal approach.

Programming Model – Simplification

The programming model used with WebSphere Process Integration also involves building business possesses by composing a series of invocations that act on data. However, with WebSphere Process Integration there is a simplified style in which this is done.

Data is defined using Service Data Objects (SDO). SDO provides an abstraction that can be used over various types of data, providing a common mechanism for accessing data. SDO are extended to provide additional functionality needed for process integration scenarios and are referred to as Business Objects.

Invocation is done using Service Component Architecture. SCA provides a standardized way to define and invoke services. The services are associated with different kinds of bindings so that the underlying invocations can be done with various invocation models, such as JMS or Web Services.

Composition is done using Business Process Execution Language (BPEL), which is used to define the overall business process. When the business process accesses data, it does so by making calls to SCA services passing Business Objects.


5. WebSphere Process Server / WebSphere Integration Developer Components

This following figure provides an overview of the components that make up the WebSphere Process Server and are enabled by the WebSphere Integration Developer. The WebSphere Process Server is built on WebSphere Application Server Version 6, providing a robust J2EE application server runtime with capabilities that the process server implementation can exploit such as JMS messaging and enterprise beans. It can also make use of the application server qualities of service such as transactions, security and clustering. Overall, this provides a well proven runtime environment for WebSphere Process Server.

The Service Oriented Architecture (SOA) Core is the foundation in WebSphere Process Server. The main components of the SOA Core are the Service Component Architecture (SCA), Business Objects (BOs) and the Common Event Infrastructure (CEI). SCA is the uniform programming and invocation model for business services that publish or operate on business data. This is one of the key components of the new programming model discussed on the previous slide. Business Objects (BOs) represent the data that is passed within that framework. Business objects are extensions to Service Data Objects (SDOs), which carry additional information needed for some integration scenarios. SDOs in the form of Business Objects are another of the key components of the new programming model. The Common Event Infrastructure (CEI) provides the foundation architecture for the management and handling of events produced by business processes. This is essential for enabling the monitoring of business processes with products such as the WebSphere Business Monitor.

On top of the SOA Core are a set of Supporting Services, which provide the transformation primitives required by integration scenarios built using Service Component Architecture and Business Objects. Interface maps are used to enable components making use of a particular interface to make calls to a component that provides a semantically similar but syntactically different interface. Business object maps enable the transformation of business data between fields of Business Objects representing the same business entity but of differing types. Relationships enable the correlation and synchronization of data representing the same business entity stored in multiple back end systems. Selectors provide for a dynamic invocation of a target component based on a date and time criteria.

Business Processes are a fundamental part of the programming model, providing the composition aspect of the programming model. In WebSphere Process Server, the business processes are defined using BPEL.Business processes provide an implementation of a process model that describes the logical order in which the different activities of the process are being executed, making calls out to the individual SCA services that implement the specific activities. As a result, a business process is the set of business-related activities, rules and conditions that are invoked in a defined sequence to achieve a business goal.


Human Tasks are enabled by the Human Task Manager and provide the human task capabilities for WebSphere Process Server. Human Tasks allow people to participate in a business process in a machine-to-human scenario, a human-to-machine scenario and in a human-to-human scenario. In the machine-to-human scenario an automated process creates tasks for people who participate in the execution of a business process, whereas the human-to-machine scenario allows a person to create a task that is executed by an automated service. The human-to-human scenario allows a task to be created by a person for another person. Human tasks can be integrated directly into the BPEL for a business process or can be packaged as an SCA component for use by any client that can invoke an SCA component.

Business State Machines are another way of modeling a business process. There are some processes that are highly event driven and are well suited to being thought of in terms of a state transition diagram. For example, a business process for order processing has to deal with the fact that an order can be canceled at any time during the order process up until the order is actually shipped. It can be difficult to model these kinds of processes in a business process. The Business State Machine component allows you to model the business process using similar constructs as UML 2.0 state machine support, and then generates BPEL for the implementation.

Business rules are a means of implementing and enforcing business policy through externalization of business function. Externalization enables the business rules to be managed independently from other aspects of an application. This independence allows for dynamic updating capabilities of the business rules to provide for a more agile business. There are two styles of business rules, if then rule sets and decision tables. A Web client is provided where the parameters of business rules can be changed by a business user using a natural language specification of these rules rather than requiring an application developer or integration developer to change the application.

Adapters in Process Integrations

Adapters are used within process integration for doing enterprise integration of various applications and back end systems that are external to the WebSphere Process Server. Adapters are integrated into the system using a service oriented approach and are fully compatible with the service component architecture. The functionality of an enterprise system is encapsulated by an adapter and business objects are used to pass data back and forth between the process server and the enterprise system. The use of business objects and service component architecture allow adapters to fit perfectly into the new programming model for the process server. The use of adapters provides a consistent framework for accessing backend systems and a consistent way to configure, deploy, and administer the adapters. Adapters can be categorized as application adapters or technology adapters. Application adapters are used for connecting to specific applications such as PeopleSoft, SAP or Siebel whereas technology adapters are used for using a specific technology for interfacing with a backend system. For example, a JDBC adapter could be used for interacting with DB2 or with Oracle databases. In addition to how adapters can be categorized, there are two major types or styles of adapters that can be used with the WebSphere Process Server. The WBI Adapters are the existing adapters that are used today with the WebSphere Interchange Server and other brokers. The WebSphere Adapters are new as part of WebSphere Process Integration and are compliant with the Java Connector Architecture (JCA) 1.5 specifications.

6. WebSphere Process Server Best Practices and Naming Convention

Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it's a constant, package, or class-which can be helpful in understanding the code. Some of the naming conventions and best practices followed in WebSphere Process Server are as follows.


COMPONENT NAME FormaT

Library {LB}{‘_’}{DESCRIPTIVE IDENTFIER}

Business Process {BP}[{‘_’}{Process main functionality}]

Module {MP|MA}{‘_’}[{Adapter Type}]{DESCRIPTIVE IDENTFIER}

DataType Generic Data: {DG}[{‘_’}{Generic Name}]Application Specific Data: {DA}[{‘_’}{APP}{Application

Specific Name}]

Interfaces Interfaces: {IF}{‘_’}{Interface Name}{IG}{‘_’}{Interface Name}{IA}{‘_’}{Interface Name}

Business Object Maps {MD}{‘_’}{Source Data Type}_to_{ Dest Data Type}

Interface Maps {MI}{‘_’}{Source Interface}_to_{ Dest Interface}

Relationships {RE}{‘_’}{relationship functionality}

Adapters (Connectors) {AD}{‘_’}{Adapter Type}{‘_’}{SYSTEM_IDENTIFIER}


Human Tasks {HT}{‘_’}{Human Task main functionality}

7. WebSphere Process Server and Integration Developer Performance Tuning

In order to optimize performance it is usually necessary to configure the system differently than the default settings. This section lists several areas to consider during system tuning. This includes both tuning the WPS, WID, and WA products, and also other products in the system. As an example, WPS supports different database managers. The documentation for each of these products contains a wealth of information regarding performance, capacity planning and configuration. Assuming that all these issues have been addressed from the perspective of the actual product, additional levels of performance implications are introduced at the interface between these products and the WPS or WebSphere Adapters.

7.1 Configure Threads for Messaging and in Work Managers

The Platform Messaging Component SPI Resource Adapter is created as part of an application install. It provides an EIS with the ability to communicate with message driven beans configured on the server. Message processing for an application uses properties defined under an activation specification for this resource adapter.

The maxConcurrency custom property under the J2C activation specification for the resource adapter is used to specify the number of threads available to process messages by the application.

If a work manager is used, set the Maximum number of threads to a value high enough to prevent the thread pool from running out of threads. This can be set in the administrative console under Asynchronous beans → work managers.

One symptom of insufficient concurrency will be CPU idleness. Vary the concurrency to achieve maximum CPU utilization and throughput.

7.2 Configure WebSphere Process Server for clustering

When tuning to achieve the best possible horizontal scalability through clustering, additional WebSphere Process Server configuration is required.

Configure the activation specification properties

Each SCA module defines a message-driven bean (MDB) and its corresponding activation specification. The default value for maxConcurrency of the SCA module MDB is 10, meaning only up to 10 asynchronous SCA requests in the module can be processed concurrently. If the server CPU is not maxed out, it sometimes is caused by this setting being too low; it needs to be increased.

Open Resource Adapters → Platform Messaging Component SPI Resource Adapter → J2C activation specification.

Select the SCA module activation specification.

Click on J2C activation specification custom properties.


Change maxConcurrency to a higher value.

Configure the ORB thread pool

This configuration parameter is relevant if the cluster is driven by a driver node through the SCA synchronous binding.

Due to the interaction between synchronous SCA, workload management (WLM), and the ORB, the ORB thread pool size on the cluster nodes needs to be configured to maximize the clustering throughput. The rule of the thumb is to use the same number of ORB threads on all application nodes, and have the total number of ORB threads across all application nodes be the same as the number of driver threads on the driver node. For example, if the driver uses 120 concurrent threads, the ORB thread pool size on each application node on a 6-node cluster should be 20.

The default value of ORB thread is 50.

To set this value, navigate to Servers → Application servers → <server_name> →Container Services → ORB Service → Thread Pool. Complete the Maximum Size field.

Configure relationship and BPE data source connection pools

The maximum connections property of the relationship data source should be large enough to allow concurrent access to the database from all threads. For the clustered measurements in the test lab, this property was set to 2 times the largest value of the WebContainer, ORB, or the default thread pool size. The multiplier of 2 comes from the fact that each transaction in the test run could contain two relationship database accesses. If your application contains more or less relationship database access, you need to adjust the multiplier accordingly.

The maximum connections property of the BPE data source should be large enough to allow concurrent access to the database from all threads. It should be larger than the largest value of the WebContainer, ORB, or the default thread pool size.

To set maximum connections for a data source navigate to Resources → JDBC Providers → <JDBC provider name> → Data sources → <Data source name> →Connection pool properties. Complete the Maximum connections field.

To find the Web container thread pool size navigate to Servers → Application servers → <server_name> → Thread Pools → WebContainer. The value is in the Maximum Size field.

The maximum connections for the ORB service can be found by navigating to Servers → Application servers → <server_name> → Container Services → ORB Service → Thread Pool. The value is in the Maximum Size field.

To find the default thread pool size, navigate to Servers → Application servers → <server_name> → Thread Pools → Default. The value is in the Maximum Size field.

Configure IBM HTTP server

On the driver node, set the com.ibm.websphere.webservices.http.maxConnection system property to 200. The default is 50. In the performance tests in a clustered environment, more than 50 driver threads were needed to max out the CPU on six cluster members.

In httpd.conf for the IBM HTTP server, set MaxSpareThreads to 200 (default is 75). This enables more than 75 driver threads, which was needed for the clustered workload performance tests using Webservices to run without errors.


Configure the JMSImport connection factory

The maximum connections property of the JMSImport Connection Factory (SAPAdpt.JMSImport_CF) connection pool should be large enough to provide a connection for every driver thread. The default is 10.

7.3 Move the default messaging provider data stores to a high performance DBMS

The messaging engine data stores are automatically created during profile creation on Cloudscape without allowing any user choice. Create alternative data stores for the messaging engines on DB2.For information on setting up the data store for a messaging engine see: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/tasks/tjm0030_.html

7.4 Disable validation in CEI Emitter

The default behavior of CEI event emitters is to validate the events to ensure that all fields are correctly filled. This is unnecessary for events generated by the WebSphere Process Server system.

To disable event validation, a custom property needs to be added to the emitter factory profile:

Navigate to Resources → CEI Infrastructure Provider (cell scope) → Emitter Factory Profile → Default Common Event Infrastructure emitter → Custom Properties

Add a new property with name validateEvent with value set to false.

Tuning Checklist

WebSphere Process Server

Do not run production server in “development mode”

Disable Tracing and Monitoring

Move databases off of the default Cloudscape

Configure Threads for Messaging and in Work Managers

Use an appropriate Java Heap size for Production Environments

WebSphere Adapters

Disable Tracing and Monitoring

Move databases off of the default Cloudscape

Configure Polling Frequency and Quantity

Database (General)


http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/tasks/tjm0030_.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/tasks/tjm0030_.html

Use a production quality database (such as DB2)

Place Database Table spaces on a Fast Disk Subsystem

Size Database Cross-Referencing Tables Correctly

Place Logs on Separate Device from Table Spaces

Database (DB2 Specific)

Maintain Current Indexes on Tables

Update Catalog Statistics

Set Buffer Pool Size Correctly

Java

Set the Heap and Nursery Size (where applicable) To Handle Garbage Collection Efficiently

Set AIX Threading Parameters

Use Hotspot Server instead of Client (where applicable)

Set Thread Stack Size if Using Many Threads

Reduce or Increase Heap Size if java.lang.OutofMemory occurs

8. WebSphere Process Server Best practices

8.1 Use Micro flows instead of Macroflows if possible

Remember, micro flows can be 100x faster than macro flows.

If target applications respond “quickly”, use microflows and synchronous bindings to target applications.

Carefully plan macro flow use and consider impacts to capacity plan.

Call Micro flows as sub processes of a “human interaction” Macroflow parent process.

8.2 Avoid over-using the process engine.

A process and its individual steps should have “business significance”.Use normal implementation techniques (servlets, beans, POJO) for “logic” that has no business significance.

8.3 Set “Transactional Behavior” to “Participate” when possible

This setting allows the current activity to run in the transaction context of the previous activity.


The default setting for “Transactional Behavior” is “Commit After” which causes each activity to run in its own transaction

8.4 Implement intelligent (query avoiding) task claim algorithms

Utilize a list of applicable claims instead of a single claim for cases where a claim may fail.

Claim a random task from a list of claims.

Limit the size of a work list by setting a size threshold.

Consider using client side caching of queries.

Consider custom query workarounds where process metadata is held separate from the process data (using database query best practices).

Avoid using BPC Explorer in high load situations.

8.5 Minimize the number of Java Snippets by initializing as many variables as possible with a single Snippet

Activities implemented as Java snippets are faster than other WPS components. Implement business processes using Java snippets as appropriate.

Java snippets do not support raising faults.

8.6 Synchronous invocations are faster than asynchronous invocations since asynchronous binding require queuing. Use Sync instead of Async if possible

Intra-module async calls are “queued”

Inter-module async calls encounter more “queues” than for intra-module async calls

At the import and at the target (export)

8.7 Use POJOs to isolate intra-module calls that must be asynchronous

Nature of interaction may be propagated downstream

Interface Maps force same interaction style on both sides. If an interface map is invoked async, async interaction is forced to the component immediately downstream from map – no longer true in 6.0.1.1+

8.8 Do not use the default path to install WID, choose the shortest possible path

Also use the shortest possible path for server profile directory and workspace paths

8.9 Modules and Shared Libraries

After deployment, if shared resources change in the library, ALL modules using the resources have to be re-deployed

8.10 Do not put any user logic into generated EJB and Web modules


Project > Clean action will delete them!

8.11 Perform a clean on the BI module project build before exporting as an EAR

It's always good to perform a clean build before exporting your application from WID to ensure that all the projects are in sync

8.12 Minimize component name lengths

Having component with long names, results in deployment failure on Windows operating system due to exceeding the path length limit.

Define your own naming conventions that make development and business sense.

8.13 When defining Interfaces, wrap primitives in business objects

Wrapping all arguments as business objects will result in the data types being handled correctly by SCA

8.14 Avoid concurrent modifications

Optimistic setting for Team Environment in not recommended unless users are very familiar with the artifact files at the text level (for example, XSD for BOs).

8.15 Separate namespaces in business objects

If working with more than one business object, it is best to put each one in a separate namespace. If they are put in the same namespace, then all of the business objects get loaded each time a namespace is called, and the overall performance of the tool degrades.

8.16 Disable monitoring and tracing whenever possible

Monitoring and tracing is significant performance hit. The default configuration WebSphere Process Server has performance critical logs switched off by default. However double check that tracing, debugging and performance monitoring is switched off.

8.17 Do not use cloudscape database for production environments

WebSphere Process Server uses cloudscape database by default. Using cloudscape database simplifies the configuration however it is not designed for production environment where high availability and performance are important.

8.18 Tune statement cache for long running processes

BPEL macro flows (long-running processes) make extensive use of the database for persisting data relevant to the process. Persisting various data results in the usage of many different statements, far more than the default capacity of the data source’s cache. This results in an excessive number of cache misses, making the caching ineffective. This problem can be resolved by increasing the size of the cache.

8.19 Use an appropriate Java Heap size for Production Environments


Small Java heap size results in frequent garbage collection. High Java heap size results in long garbage collection cycles. Refer to documentation of the used Java Virtual Machine (JVM) for more details.

8.20 Do not use the Unit Test Environment (UTE) for performance measurement

8.21 Do not run a production server in development mode

8.22 Setup repositories to avoid concurrent modification of files

8.23 Do not check in any generated artifacts into a team repository

8.24 Check-in/Check-out only the file in the Business Integration view

9 Reference:

1. Technical Overview of WebSphere Process Server and WebSphere Integration Developer

http://www.redbooks.ibm.com/abstracts/redp4041.html?Open

2. WebSphere Business Integration V6.0.2 Performance Tuning

http://www.redbooks.ibm.com/redpieces/abstracts/redp4304.html?Open

3. WebSphere Process Integration Version 6.0 information center

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp

4. WebSphere Application Server Performance URL

http://www.ibm.com/software/webservers/appserv/was/performance.html

5. WebSphere Business Integration Adapters: An Adapter Development and WebSphere

6. Business Integration Solution

http://www.redbooks.ibm.com/abstracts/sg246345.html?Open


http://www.redbooks.ibm.com/abstracts/sg246345.html?Open

http://www.ibm.com/software/webservers/appserv/was/performance.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp

http://www.redbooks.ibm.com/redpieces/abstracts/redp4304.html?Open

http://www.redbooks.ibm.com/abstracts/redp4041.html?Open

About the authors:

Prasad V Lokam

Prasad V Lokam is the Chief Architect at Miracle Software Systems, Inc. He has over 15 years of Systems Integration & Business Integration consulting experience with some of the Fortune 500 companies which spans across Enterprise Architecture, Business Integration Architectures, Definitions, Business Process Management & Optimization, Technology Portfolio Management, Planning and Implementation.

Email: [email protected] / 1-248-233-1187

Sai Kastury

Sai Kastury is the Enterprise Architect at Miracle Software Systems, Inc. He has over 10 years of Systems Integration & Business Integration consulting experience with Business Integration Architectures and Business Process Management & Optimization.


Sandeep Gugloth

Sandeep gugloth is a WPS expert at Miracle Software Systems, Inc. His primary focus has been on the Process Integration space. He has several years of experience helping various customers across Manufacturing and Healthcare domains using IBM Process Integration Technologies.


Rajesh Garlanka

Rajesh Garlanka is an Integration Specialist at Miracle Software Systems, Inc. His primary focus has been on the Business Integration space. He has several years of experience helping various customers across Telecom, Manufacturing, and Retail domains using IBM Business Integration Technologies.

Email: [email protected]

Copyright 2007 © Miracle Software System, Inc.

Miracle acknowledges the proprietary rights of the trademarks and product name of the other companies mentioned in this paper. The information provided in this document is intended for the sole use of the recipient and for educational purposes only. Miracles make no express of implied warranties relating to the information contained in this document or to any derived results obtained by the recipient from the use of the information in the document. Miracle further does not


mailto:[email protected]

mailto:[email protected]

guarantee the sequence, timeliness, accuracy or completeness of the Information and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of, any of the information of in the transmission thereof, of for any damages arising there from. Opinions and forecasts constitute our judgment at the time of release and are subject to change without notice. This document does not contain information provided to us in confidence by our clients


wps-bestpractices-101223065318-phpapp02

Documents

websphere

maximum size

jmsimport

miracle software

websphere

websphere

systems integration

maximum connections