Skip to main content

skip to main content

developerWorks  >  SOA and Web services | Architecture  >

Work with Web services in enterprise-wide SOAs, Part 5: Optimize Web service applications with WebSphere Business Integration tools

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Intermediate

Judith Myerson (jmyerson at bellatlantic.net), Systems engineer and architect, Consultant

14 Jul 2005

Want to learn how to optimize a Web service application in a Service-Oriented Architecture (SOA)? Judith M. Myerson stresses the importance of business process rules as the number one priority in optimizing Web services and gives examples of other optimization techniques, such as reducing the number of Web requests and execution time. She also discusses the IBM WebSphere® Business Integration tools that developers and business analysts might use in a collaborative effort to model Web services for optimization.

Introduction

In Part 1 of the series, I showed how to execute the business logic of Web services to get the proprietary Enterprise Application Integration (EAI) applications to talk to one another. In Part 3, I pointed out how Web services communicate with one another on how processes in multiple SOAs should be integrated and implemented. I also talked about how a developer can use Rational® development tools to create an actual application in Part 4.

In this article, I talk about business process rules for Web services as the first priority in optimizing Web services and SOAs. Once developers have optimized the process rules, they can then begin to reduce:

  • Number of Web requests
  • Execution time
  • Access time
  • Unneeded data
  • Bandwidth amount

Developers also need to consider a partitioning scheme for a large database connected to one or more Web services.



Back to top


Business process rules

To reduce traffic bottlenecks or loading overheads, developers need to optimize the performance of Web services across the SOAs using some set of business process rules. They should use the Business Process Execution Language for Web Services (BPEL4WS) specification to create new business logic, invoke Web services, manipulate data, throw faults, or terminate a process.

You use executable processes to compose new Web services based on business logic to achieve business goals for the organization. You also use an abstract process as an agreement between two partners on how they interact in an e-business dialogue.



Back to top


Web requests

After optimizing business process rules, developers can proceed to develop Web requests that they need to build a new Web service from the existing ones. It does not matter if the Web services are within or across the SOAs. If the new Web service -- business logic or data-centric -- provides better or additional service or functionality, developers must reduce or altogether eliminate redundant Web requests. Figure 1 shows each of the two existing Web services sending a redundant Web request to create a new Web service.


Figure 1. Redundant Web requests
Redundant Web requests


Back to top


Execution time

When developers have optimized the number of requests an existing Web service can make, they also need to reduce the time for execution of the existing Web services to create a new Web service based on business processes at any point in the composition life cycle. Data-centric Web services rarely execute themselves.

When developers compose the new Web service, they should take care it does not result in new redundancy. In order to eliminate redundancy, it might be necessary to combine some redundant Web services as a single service.



Back to top


Access time

Given the optimal execution time, reducing access time is another concern for developers. When a Web service request is simple, the time to access the requested information from a database or another source must be optimal. Care must be taken that the requests do not overlap one another in consuming and publishing Web services.

Developers should modularize, optimize, and index the requests to reduce access time. They can then put the Web requests in a repository from which they can reuse in a new application.



Back to top


Bandwidth amount

As you know, Web services are based on XML and most files are small. Bandwidth is usually not a problem and execution and access time are optimal. The problem is with large XML files. Every time you make changes to the files on a remote server, you need to re-transmit the entire files. The large graphic files, in uncompressed format, can consume enormous disk space and the amount of bandwidth, thus slowing down access time.

As a partial solution, developers need to transmit only the changes to the files for the new Web service. Other techniques to conserve bandwidths include: caching techniques to speed up page loads, optimizing time to parse text-formatted XML files, and compiling XML files as a binary file (unreadable).



Back to top


Unneeded data

Developers should specify filtering rules to weed out data they do not want. Filtering rules are not the same thing as the normalization rules that aim at reducing data redundancy. They should also optimize filtering rules and then store them (XML format) in a repository for later recall. You can load the rules from the repository when you need them and unload the rules back into the repository when you do not need them. The filtering rules should also include automatic purging or backup of aged data and a mechanism to expire large XML files sooner.



Back to top


Partitioning schemes

When a Web service is connected to a large database, care should be taken how the data is accessed, filtered, and distributed across the servers, particularly if the latter are in different SOAs. Developers should consider two things for faster access while reducing bandwidths:

  • Frequency of database updates
  • Updates to database portion size

If most parts of the database require frequent updates, you should consider a partitioning scheme: hardware, horizontal, or vertical. On the other hand, if a small part of the database requires frequent updates, consider dynamic partitions.

Hardware partitioning

You can use RAID (Redundant Array of Independent Disks) to achieve hardware partitioning without splitting tables by physically placing them on individual disk drives. Having a table on one physical drive and other tables on separate drives can improve throughputs and operational efficiency. Alternatively, you can have a table striped across multiple drives to allow faster scanning than with the same table stored on a drive.

Horizontal partitioning

You can partition data horizontally based on age. For example, you can divide a large table into ten smaller, children tables that contain data and business process rules for each of the ten years.

Vertical partitioning

You can use this technique to divide a table into a fewer number of children tables. You could apply the concept of normalization to remove redundant portions of the tables and place them in secondary tables. You can also establish a foreign key in a secondary table to link with a primary key in a primary table.

Dynamic partitions

While you want a relatively small, important subset of the data to be updated frequently, let's suppose the vast majority of information in your database is relatively static. As shown in Figure 2 below, you need to split the database into dynamic and static partitions for frequent and infrequent updates, respectively.


Figure 2. Dynamic and static partitions
Dynamic and static partitions

This means you need to design the database system in such a way that you divide the database tables into modularized and optimized partitions of two types -- static and dynamic. You can keep the static partitions on a local server while moving the dynamic partitions to a remote server for frequent updates by the users. You can do this by splitting the tables across a group of local servers and another group of remote servers. This technique can help to decrease the bandwidth by many orders of magnitude when the new Web service updates the database.



Back to top


Close language gap

Developers and business analysts should find a common ground for ways of optimizing Web services and SOAs. One problem with this approach is that they tend to speak in different languages, use different terminologies, and have different knowledge backgrounds.

For instance, business analysts use process models to address business requirements, while developers use UML (Unified Modeling Language) models to focus on the system capabilities of Web services they want to optimize. One way of resolving this problem is to integrate and transform between UML and BPM (business process modeling) models. This can contribute to good communication and reduce costs associated with miscommunication.



Back to top


WebSphere Business Integration tools

The following are IBM WebSphere® Business Integration (formerly IBM Holosofx) tools you can use to close the gap:

  • IBM WebSphere Business Integration Workbench: This is a BPM tool you can use to bridge the gap between business analysts or managers and developers with a common UML/BPM workspace.
  • IBM WebSphere Business Integration Monitor: With this tool, you can display real-time and historical data from events produced by WebSphere MQ Workflow. By viewing the Workflow and Business Dashboards with business controls, business, and IT, you can optimize and manage business performance.
  • IBM WebSphere Business Integration Workbench Server: This tool provides you with repository management and Web publishing capabilities. It allows you to facilitate process design collaboration and instant Web access to:
    • Process models
    • Policies
    • Procedures
    • Business rules
  • IBM WebSphere Business Integration Modeler Advanced Edition: You can use this tool in a collaboration environment to design processes interactively with multiple users. This product is a bundle consisting of the IBM WebSphere Business Integration Workbench Server and IBM WebSphere Business Integration Workbench licenses. You can run the WebSphere Business Integration Modeler Advanced Edition on Windows® 2000 or Windows XP.



Back to top


Conclusion

Optimizing Web services across SOAs requires planning ahead of time on how many Web services rely on business rules that can actually be optimized. Developers should communicate with a team of business analysts on which modeling techniques and optimization schemes to use and the associated issues of each in designing Web services. By resolving the issues up front, developers find it makes their job of optimizing Web services much easier. They can develop and optimize Web services that interact and integrate with one another -- within SOAs and across SOAs.

Analysts also find that resolving issues up front makes their job of designing and analyzing the business side of optimizing Web services much easier. They can determine which modeling approaches to use, what schemes to use, and how many Web services can be optimized in a SOA.



Resources



About the author

Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful
Extremely
useful
 


Back to top