Developing business process portal applications using WebSphere tooling

Document options Document options requiring JavaScript are not displayed Sample code New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Introductory

Andreas Nauerz (andreas.nauerz@de.ibm.com), Software Engineer, IBM
Juergen Schaeck (jschaeck@de.ibm.com), Software Engineer, IBM Boeblingen Lab
Thomas Schaeck (thomas_schaeck@us.ibm.com), Software Architect, IBM Boeblingen Lab

11 May 2005

Using a common travel planning business scenario, this article illustrates how to provide your end users a way to efficiently process tasks. You use business process integration, a new capability in IBM® WebSphere® Portal Version 5.1 to support tasks requiring human involvement (such as completing online forms) within the business process. The Business Process Execution Language (BPEL)-based workflow runs in WebSphere Business Integration Server Foundation Version 5.1.1. This article is intended for business process designers, portlet application developers, and portal administrators working together to support business processing in their portals. Readers should be familiar with portlet application development and business process design. This article primarily covers the programming aspects of integrating a business process into a portal, and does not detail business process modeling. References are included for more information about process modeling and tooling.

Introduction

In an on demand business environment, where efficient customer, employee, and supplier interaction is critical, businesses need to enable these parties to seamlessly participate and collaborate in business processes. Developers need to provide interfaces to support human interaction with business processes, such as filling in forms or responding to alerts. These interfaces need to be provided to the right people at the right time, and they should facilitate quick action and efficient processing. Also, you need to provide the information, applications, and forms a user needs to process them. In this article, we refer to the tasks involving human interaction as human tasks.

In WebSphere Portal each human facing activity in a process is associated with a task page definition, whose content always contains a task processing portlet. These portlets retrieve the input message of a staff activity, display it to the user, obtain user input, and write it to the system. The other portlets on the page, which do not directly communicate with the workflow system but help to process the task, are called supporting portlets. See the Integrating business processes section of the WebSphere Portal V5.1 Information Center for an overview and more detailed information on the business integration capability.

When a user clicks on one of the tasks displayed in the My Tasks portlet (which is shipped with WebSphere Portal and lists all the tasks for a user), a task page dynamically displays in the navigation for the user. Its layout is defined by the associated task page definition. The user can work with the portlets on the page, and as soon as the task is complete, the page disappears. The scenario below illustrates this concept. The rest of this article walks you through the steps to develop a business process portal application, using the Travel Request Approval sample scenario.

Back to top

Download and run the sample application

You can download the sample application and source code. Extract the bp-portal-sample.zip file and open the readme.html file, which describes the content and links to the setup instructions.

Back to top

Introducing the sample scenario

An employee of the fictitious ACME Corp wants to travel to New York for a conference. Before he can book his travel, he needs to initiate a travel request which must be approved by his manager. He defines his travel preferences as part of the request, and these preferences are used later by an administrative assistant to book a flight for him. This travel application is provided as part of the ACME Corp employee portal.

A typical interaction flow follows.

1. The employee opens the Travel Requests page in his browser. The page includes a travel request portlet, which employees use to initiate travel requests, and a status portlet, which shows all pending travel requests along with current status of each.
2. The employee enters information (such as the reason for travel, destination airport, and departure date) into the travel request portlet, and clicks the submit button to initiate the request.
3. A new travel request displays in the status portlet (see Figure 1)
   Figure 1. The Java Beans view
   
   
4. The employee's manager, who is currently browsing in the portal, sees an alert in the top navigation area notifying him that a new task is pending.
5. The manager clicks on the alert, and the portal displays his current task list which now includes the task to approve the employee's travel.
6. The manager claims the task, and then clicks on its title.
   Figure 2: The manager's task list
   
   
7. The portal displays a new page containing the travel request details the user entered before and buttons to either approve or to reject the request. The manager can click the little X next to the page name to close the current task page, and he can reopen it at any time. When the manager clicks one of the buttons, the page closes and the portal returns to his MyTasks portlet.
   Figure 3: The Approve portlet
   
   
8. Then, the employee's administrative assistant receives the task to book the flight for the travel. He sees an alert, and clicks on it to see his current tasks.
9. The assistant claims the task, and clicks the title. The portal displays a page which includes a travel booking portlet, which shows the employee's travel preferences, and a flight information portlet, which displays matching flights.
10. The assistant selects a flight, and WebSphere Portal's interportlet communication (also called cooperative portlet) mechanism transfers the selected flight data into the form so the assitant does not have to re-key it.
    Figure 4: The administrative assistant books the travel using an auto-filled form
    
    
11. The employee returns to the travel page to review the status of the travel request and sees that the status now is Approved and booked.

The employee is ready to make his trip!

Each user can easily process his or her own tasks. The user does not have to care about the programs he or she needs to use or where to get further information.

You could easily extend this application. In order to add additional helpful portlets, such as a project calendar for the manager or an instant messaging portlet for the administrative assistant, you only need to add them to the appropriate task page definitions.

Back to top

What is a business process portal application?

A business process portal application consists of:

• The definition of the business process
• Portlets to initiate the process
• Portlets to process the human tasks
• The task pages

Creating a business process portal application involves several team members or roles:

• The process designer defines the business process, including the control and data flow, the syntax of the input and output messages, and the semantics of the single activities contained in the process. The process designer can use the WebSphere Business Intergration Modeler and WebSphere Application Developer Integration Edition V5.1.1 to create the design.
• The portlet application developer develops the portlets, using Rational Application Developer V6.0.0.1.
• The portal administrator assembles the content of the task pages based on his domain knowledge. The portal administrator uses WebSphere Portal for this task.

Sometimes, all of these roles and tasks are handled by a single developer. However, if that is not the case (that is, multiple people cover these roles), then the process designer must provide the following information and code to the portlet developer.

Activity specification

The activity specification describes in detail the purpose of the activity, how the input and output messages correlate, the acceptable values for single entries in a message, and the expected results for the output message. This specification also contains the definition of the correct syntax of the input and output messages.

Generated classes

There are two cases where the exchange of generated classes is required.

• One of the input/output messages is nested or contains complex types. In this case, the portlet must have access to these classes.
• The portlet developer should use a generated and adopted Web service or EJB Interface to start a process instance instead of the generic EJB interface. If this is not required, the generic EJB Interface to create process instances can be used. In that case, the name of the template is sufficient.

Because each human activity that is exposed by the portal is assigned to a task page definition, you need to have a unique Client UI identifier for each staff activity. In order to guarantee its uniqueness, you could reuse the Java™ package structure pattern; for example, acme.travelrequests.approvalPage. The process designer needs to specify this identifier, and then communicate it to the portal administrator who assigns it as a unique name to the task page definition.

Back to top

Developing the business process

You can use IBM WebSphere Application Developer Integration Edition V5.1.1 (hereafter called Integration Edition) to create the portal connections with a business process.

Examining the travel request process

Figure 5 shows the overall sample process flow.

• The Input activity starts when it receives the user's input. It initiates the travel approval process.
• The approveRequest represents the first staff activity. It requires the manager to decide whether to approve the request based on the information provided by the employee.
• Depending on the manager's decision the process engine either routes to the second staff activity, bookFlight which asks an administrative assistant to book an appropriate flight, or, if the manager rejects the employee's request, routes directly to the Output node.
• The JavaSnippets store information about which person has processed which task.

Assigning task page definitions to activities

Each activity that should be processed in the portal is associated with a task page definition. In the sample application, the approveRequest activity is associated with the Approve page that contains the Travel Approval Portlet. The Client UI identifier, Unique Name, that should be used is wps.ApprovePage. The bookFlight activity is associated with the FlightBook page that contains a FlightBooking and a FlightSelect Portlet .

To set the associations between staff activities and task page definitions, the Business Process Designer performs the following, using Integration Edition.

1. Open your project in the Business Integration Perspective.
2. Click the staff activity for which the Client UI identifier should be defined; in this example,approveRequest.
3. Click the Client tab and select Client Definitions => Portal .
4. For the UniqueName parameter, click into the Value field, and add the unique name wps.ApprovePage.
5. In the Type parameter, click into the Value field, and select Page Definition from the drop down list.
   Figure 6: Defining the client UI settings
   
   

Using the Member Manager staff plug-in provider

In order to assign human facing tasks to users, WebSphere Process Choregrapher uses Staff Verbs which resolve at runtime and define the list of potential owners of a task. The For example, the Group Members Staff Verb returns the list of users that are part of a specific group. The component that performs the resolution is called a Staff Plugin, which accesses a user repository, such as LDAP or a Custom User Registry, to perform that task.

For a detailed description of the Staff Resolution mechanism see, WebSphere Application Server Enterprise Process Choreographer: Staff Resolution Architecture. See also the Member Manager staff plugin provider section of the WebSphere Portal V5.1 InfoCenter.

In order to provide a uniform view on the user repository, both from WebSphere Portal and WebSphere Process Choreographer, WebSphere Portal 5.1 ships a special Staff plug-in that uses the WebSphere Member Manager user repository that is also used by WebSphere Portal.

The business process designer uses Integration Edition to specify that the Member Manager staff plug-in provider be used for staff resolution within the process:

1. Within the Services view, right-click on your service project.
2. Select Properties => Staff.
3. Define the JNDI name of staff plug-in configuration; for example, bpe/staff/wpswmmconfiguration
   Figure 7: Specifying the staff plug-in provider
   
   

The definition of the roles and verbs for staff resolution is the same as for other staff plugins. In the sample, all users in the approvers group can process tasks of type approveRequest.

To approve a request:

1. Within the editor, click the staff activity for which the Client UI identifier should be defined; for example, approveRequest.
2. Click the Staff tab.
3. From the list of available roles, click Potential Owner.
4. Select Group Members as verb.
5. Enter the name of the group to be used (approvers, in this example), and select false from the drop down list for the IncludeSubgroups property.
   Figure 8: Defining the staff resolution
   
   

Generating code for deployment

After creating or updating the process, the business process designer generates the code for deploying to the server. In Integration Edition:

1. In the service project, right-click the .bpel file.
2. Select Enterprise Services => Generate deploy code.
3. To export the generated EJB, right-click on the EJB, and select Export => Export as EAR, and choose an export destination.

Now the portal administrator can deploy the EAR file (or an update) using the WebSphere Application Server administrative console. Refer to the install instructions which are contained in the download for details.

Exporting classes required by the task processing portlet

During development of the business process, some of the generated classes must be made available to the task processing portlet developer to include in the portlet application.

Integration Edition generates classes for all messages defined in the <processname>.wsdl file, and for all complex types that are added to the schema. The package names of the messages are appended with an _msg suffix. For example, when the target namespace in the WSDL file is set to x.y.z.TravelRequest, the package name for the classes is x.y.z.TravelRequest_msg. The package names for the complex types are similarly built, however, they do not have the _msg suffix. These classes are required by the task processing portlet, so place them, as a JAR, into the /WEB-INF/lib directory of the corresponding portlet application.

To export a JAR file containing these classes which are needed for our sample:

1. Right-click the packages to be exported:

   com.ibm.wps.wfi.sample com.ibm.wps.wfi.TravelRequestProcess_msg com.ibm.wps.wfi.TravelRequestProcess_msg_beans

   
   
2. Select Export from the context menu.
3. Select the Jar file.
4. Enter the destination location for the JAR file.
5. Click Finish.

Back to top

Developing the portlets

Next, you walk through the steps that portlet developers take to create the process initiation and task processing portlets. You use the Rational Application Developer Version 6.0 (hereafter called Application Developer) to create these portlets.

Importing required class libraries

You need to add certain classes to the classpaths of the portlets. You add the generated process message classes, which are packaged in JARs, to the /Web-Content/WEB-INF/lib directory of the portlet.

To add a JAR to the classpath, in Application Developer:

1. Open the view displaying your portlet project.
2. Open the /Web-Content/WEB-INF/lib folder of the portlet project.
3. Right-click on the /lib folder.
4. Select Import from the context menu. The Import wizard opens.
5. Select Select From File, and click Next.
6. Click Browse to select the folder in which the JAR is located, and then click OK.
7. Select the JAR and click Finish.

The JAR is imported into the portlet project.

You also need to specify these JARs located, under was_root/lib, to be referenced as external JARs:

wsif.jar
wsif-j2c.jar
wsatlib.jar

1. Open the view displaying your portlet project.
2. Right click on the project, and select Properties from the context menu.
3. Select Java Build Path.
4. Select the Libraries tab.
5. Click Add External JARs.
6. Browse for the three JAR files listed above.
7. Click Finish.

Developing a process initiation portlet

To develop a process initiation portlet, you use Business Process Engine of WebSphere Process Choreographer (BPE API). See Resources for the location of the Javadoc for the BPE API .

First, you need to code the lookup for the BPE EJB. It is best not to hardcode the location of the BPE EJB; instead, specify an EJB reference in the web.xml:
Listing 1. The build and install process

<ejb-ref>
<ejb-ref-name>ejb/BusinessProcessHome</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.ibm.bpe.api.BusinessProcessHome</home>
<remote>com.ibm.bpe.api.BusinessProcess</remote>
</ejb-ref> 

To add a reference, Application Developer:

1. Double-click the Web Deployment Descriptor .
2. Select the References tab.
3. Create a new reference using the Add button.
4. Enter the data shown in Figure 9.
   Figure 9: Adding an EJB reference via RAD
   
   

You can set the specific location of the 8 (and you can change it without changing the source code) using the WebSphere Application Server administrative console:

1. Select the process application below Enterprise Applications.
2. Select Map EJB references to beans.
   Figure 10: Setting a JNDI name of the EJB reference
   
   

The code to obtain a reference to the BPE EJB uses the EJB reference name (in the sample, ejb/BusinessProcessHome) .

public BusinessProcess getBusinessProcessEJB() throws Exception
{
	[...]
	
// Obtain the default initial JNDI context
Context initialContext = new InitialContext();
// Lookup the remote home interface of the BPE EJB 
   Object result =initialContext.lookup("java:comp/env/ejb/BusinessProcessHome");
// Convert the lookup result to the proper type 
   BusinessProcessHome processHome=BusinessProcessHome}
     javax.rmi.PortableRemoteObject.narrow
    (result,BusinessProcessHome.class);
// Create 
BusinessProcess process = processHome.create();

return process;
...

The method to initiate a process instance expects as input ClientObjectWrapper, which wraps a WSIFMessage that contains the real input data. To retrieve an empty instance of a process input message use this code.

public ClientObjectWrapper 
getProcessInputMessage(BusinessProcess businessProcess, String templateName)
  throws Exception
{
ProcessTemplateData templateData = 
businessProcess.getProcessTemplate(PROCESS_NAME);
String inputTypeName = templateData.getInputMessageTypeName();
ClientObjectWrapper wrapper = 
businessProcess.createMessage(templateData.getID(), inputTypeName);
return wrapper;
	[...]

The process initiating portlet displays a form enabling the end user to enter data and a Submit button to start a process instance. When the user clicks the Submit button, the portal triggers a portlet action which performs the following code:

// Get a reference to the BPE EJB
BusinessProcess businessProcess = workflowService.getBusinessProcessEJB();

// Get the process input message
ClientObjectWrapper inputData=
workflowService.getProcessInputMessage(businessProcess, PROCESS_NAME);
WSIFMessage inputMessage = (WSIFMessage) inputData.getObject();
// Fill the values of the input message using the generated Java Bean

TravelRequestInputMessage travelInputMessage=
new TravelRequestInputMessage(inputMessage);
travelInputMessage.setDestination(destination)
[...]
// Trigger the process
businessProcess.initiate(PROCESS_NAME, inputData);

Developing the task processing portlets

To develop a task processing portlet, you use these APIs:

Task API

Human task manager of WebSphere Process Choreographer

TaskUI Manager API

Portlet service for the task user interface

Property broker API

Exchange properties with other portlets

Javadocs for the Task API are located in was_root/web/apidocs.task/, where was_root is the directory in which WebSphere Application Server is installed.

Javadocs for the TaskUI Manager and Property Broker APIs are located in wp_root/doc/Javadoc/WP/API ,where wp_root is the directory in which WebSphere Portal is installed.

The task processing portlet must include the message classes generated by WebSphere Studio Application Developer Integration Edition as well as special classes for property broker support.

The internal flow of control of the task processing portlet can be separated into three phases.

1. Retrieving properties from My Tasks portlet.
2. Processing the task.
3. Closing the task page.

Retrieving properties from My Tasks portlet

Because the properties that are sent by the My Tasks portlet are only delivered once, the task processing portlet must store them for as long as they are required.

Table 1. Properties delivered by the My Tasks portlet to the task processing portlet

The task processing portlet must indicate that it can retrieve task properties using the following setting in the portlet.xml:

<preference>
<name>com.ibm.portal.pagecontext.enable</name>
<value>true</value>
</preference>

The Approve portlet and the Flight Book portlet are the only task processing portlets receiving properties from the My Tasks portlet. Enable each portlet to receive context by adding this preference value:

1. Double-click the Portlet Deployment Descriptor.
2. Switch to the Portlets tab.
3. In the Persistent Preference Store section, click the Addbutton to add a new entry.
4. Enter com.ibm.portal.pagecontext.enable as name and true as value.
   Figure 11: Enabling portlets to receive context
   
   

JSR 168 compliant portlets receive page context parameters on the processAction() method using the com.ibm.portal.action.name request attribute. The value of this attribute is a Map storing the context entries. Each property value is obtained by name.

Therefore, within the processAction() method of the Approve portlet and the Flight Book portlet, the following code retrieves the three properties in Table 1:

public void processAction(ActionRequest request, 
ActionResponse response) throws PortletException, java.io.IOException
{

[...]

// Perform page context processing		
String specialAction = request.getParameter(PARAMETER_SPECIALACTION);
if (specialAction != null && specialAction.equals(ACTION_PAGECONTEXT))
{
// This indicates context was passed to the launched page
java.util.Map contextMap = (java.util.Map)
request.getAttribute(PARAMETER_PAGECONTEXT);
// Read the information we need
String taskID = (String) contextMap.get(SESSION_TASKID);
TaskUIHandle taskUIHandle = (TaskUIHandle) contextMap.get(SESSION_TASKUIHANDLE);
ObjectID returnPageID = (ObjectID) contextMap.get(SESSION_RETURNPAGEID);
// Store the properties read in the session 
portletSession.setAttribute(SESSION_TASKID, taskID); 
portletSession.setAttribute(SESSION_TASKUIHANDLE, taskUIHandle); 
portletSession.setAttribute(SESSION_RETURNPAGEID, returnPageID);
}

[...]

Processing the task

To process the task:

1. Obtain the TaskManagerDelegate using the TaskManagerDelegateFactoryService. The TaskManagerDelegate is the business delegate of the Human Task Manager (HTM) EJB providing the means to interact with the process engine. Therefore, the Approve portlet and the Flight Book portlet include the following code:

   public void init(PortletConfig portletConfig) throws PortletException, UnavailableException { super.init(portletConfig); [...] Context ctx = new InitialContext(); // Obtain a reference to the TaskUIManager service, which is used to close task pages and to sent a redirect after closure PortletServiceHome serviceHome = (PortletServiceHome) ctx.lookup(SERVICE_TASKUIMANAGER); taskUIManager = (TaskUIManager) serviceHome.getPortletService(TaskUIManager.class); // Obtain a reference to the task manager business delegate to interact with the process PortletServiceHome taskManagerDelegateFactoryServiceHome = (PortletServiceHome) ctx.lookup(SERVICE_TASKMANAGERDELEGATEFACTORY); TaskManagerDelegateFactoryService taskManagerDelegateFactoryService = (TaskManagerDelegateFactoryService) taskManagerDelegateFactoryServiceHome.getPortletService( TaskManagerDelegateFactoryService.class); taskManager = taskManagerDelegateFactoryService.getTaskManagerDelegate(); }

   
   
2. Retrieve the input message from the HTM and display it. The task processing portlets use the getInputMessage() method of the TaskManagerDelegate to obtain the input message from the HTM. The TaskID used is the TaskID property received from the My Tasks portlet previously. We equip the Approve portlet and the Flight Book portlet with the following code:

   public void getTravelRequest(PortletRequest request) { [...] // Obtain the TaskID of the current task String taskID = (String) session.getAttribute(SESSION_TASKID); // Read the input message WSIFMessage message = (WSIFMessage) (((com.ibm.task.api.ClientObjectWrapper) taskManager.getInputMessage(taskID)).getObject()); [...]

   
   

   Important: When the input or output messages of a task contain complex types, make sure that you add the Java classes that were created by the WebSphere Studio process tooling for these messages to the classpath of the portlet. This would be in the portlet's /WEB-INF/classes directory or, if packaged as a JAR, in the /WEB-INF/lib directory.

3. Display the input message and provide a user interface to obtain the required data from the user for output. As part of this step, the portlet could exchange properties with other supporting portlets on the page through the property broker.
4. Send the output message to the HTM. After the user has entered information into the portlet and submitted the changes, the portlet uses the setOutputMessage() of the TaskManagerService interface to send the information to the HTM.

   For the Approve portlet we use the output message to indicate that the manager either has approved or rejected the travel request:

   // Read the TaskID of the current task String taskID = (String) portletSession.getAttribute(SESSION_TASKID); // Obtain the actual task Task task = taskManager.getTask(taskID); // Create and set the output message com.ibm.task.api.ClientObjectWrapper cow= (com.ibm.task.api.ClientObjectWrapper) taskManager. createMessage(taskID, task.getOutputMessageTypeName()); WSIFMessage message = (WSIFMessage) cow.getObject(); ApprovalStatusMessage approvalStatus = new ApprovalStatusMessage(message); approvalStatus.setManagerApproved(true); approvalStatus.setWorker(userName.toString()); taskManager.setOutputMessage(taskID, cow);

   
   

   In case the manager would have rejected the travel request we would have changed the output message to approvalStatus.setManagerApproved(false).

   We perform similar operations within the Flight Book portlet.

   Important: When the input or output messages of a task contain complex types, make sure that you add the Java classes that were created by the WebSphere Studio process tooling for these messages to the classpath of the portlet. This would be in the portlet's /WEB-INF/classes directory or, if packaged as a JAR, in the /WEB-INF/lib directory.

5. Complete the task. The portlets use the complete() method of the TaskManagerDelegate. So, after setting the output message, both the Approve and Flight Book portlets complete the task by using the following command:

   // Complete the task taskManager.complete(taskID);

   
   

Closing the task page

The portlets use the TaskUIManager portlet service to close the task page and return the user to the task list page.

The Approve andd Flight Book portlets each close the task page using the following command:

// Finally close the page and perform the redirect 
taskUIManager.closeDynamicUI(request, response, taskUIHandle);

Important: The parameter taskUIHandle contains the value of the property originally sent by the My Tasks portlet.

Closing the page and setting the new page

Finally, the setPage() method indicates the new page (ReturnPageID) that will be opened after the task page has been closed. The Approve and Flight Book portlets each use the following command to redirect to the page hosting the My Tasks portlet:

taskUIManager.setPage(request, response, returnPageID);

The parameter returnPageID contains the value of the property originally sent by the My Tasks portlet.

Back to top

Conclusion

In this article you have learned how to create applications that leverage the Business Process Integration in WebSphere Portal capability to connect people, processes and information. You could extend the demo application with your own portlets, or replace the existing portlets with your own versions. Or, you could start with an existing business process of your company.

Back to top

Download

	Information about download methods

Resources

• WebSphere Portal V5.1 Information Center (English)
  
  
• WebSphere Portal V5.1 product documentation ? includes InfoCenters in all languages
  
  
• WebSphere Business Integration Server Foundation documentation, including Process Choreographer
  
  
• WebSphere Portal zone
  
  
• Business Process Integration in WebSphere Portal
  
  
• Business process choreography in WebSphere: Combining the power of BPEL and J2EE
  
  
• WebSphere Application Server Enterprise Process Choreographer Programming Model
  
  
• WebSphere Application Server Enterprise Process Choreographer: Concepts and Architecture
  
  
• WebSphere Application Server Enterprise Process Choreographer: Staff Resolution Architecture
  
  
• Integration Cookbook for WebSphere Business Integration Modeler and WebSphere Studio Application Developer Integration Edition
  
  
• Connecting to a business process engine through a portlet
  
  
• Javadoc for the Business Process Engine API
  

About the authors

		Andreas Nauerz Andreas Nauerz works as Software Engineer in the IBM Laboratories at Boeblingen, Germany. His current work areas include Business Process Integration and Dynamic UI Management. He studied Computer Science at the University of Cooperative Education of Mannheim, the University of Staffordshire, the University of Saarbruecken, and the University of Hagen, respectively.

		Juergen Schaeck is a Software Developer at the IBM Boeblingen Lab. Juergen holds a Master's degree from the University of Karlsruhe and currently works in WebSphere Portal Development. He works on the Business Process Integration in WebSphere Portal.

		Thomas Schaeck has been the Lead Architect for IBM Workplace Messaging and Web Conferencing since Fall 2004. Before that, he was the lead for the WebSphere Portal Foundation architecture and portal standards. He initiated the Java Portlet API (JSR 168) and Web Services for Remote Portlets (WSRP) standards, and chaired the OASIS WSRP Technical Commitee for the first year in defining WSRP 1.0. Thomas has filed over 25 patents, written numerous papers, and was a co-author of Pervasive Computing and Smart Card Development in Java.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top