WebSphere DataPower Release 5.0.x
Application Optimization
© 2012 IBM Corporation
This presentation discusses the enhancements to the Application Optimization theme for
DataPower 5.0.0.
DataPower_5.0_AppOpt.ppt
Page 1 of 23
Table of contents
JSON Parser Settings
AO on XG45
WAS Version Update
2
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
For DataPower 5.0.0, JSON Parser settings were added to allow an administrator the
ability to control the behavior of the JSON Parser.
The Application Optimization feature is now available on the XG45 DataPower Appliance.
And, the prerequisites for WebSphere Application Servers have been updated.
DataPower_5.0_AppOpt.ppt
Page 2 of 23
Table of contents
JSON Parser Settings
AO on XG45
WAS Version Update
3
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
First, we will discuss the JSON Parser Settings.
DataPower_5.0_AppOpt.ppt
Page 3 of 23
JSON Parser Settings
What It Is
This feature adds the ability to configure specific limits on the JSON Parser.
Why It Is
Prior support had fixed document and attribute limits. These limits were too small for
many applications and could not be changed. Additional constraints were added for
threat protection.
Who Wants It
Any customer that uses JSON. Developers can ensure that their JSON documents can be
processed. Administrators can protect their environment by enforcing configurable limits.
4
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
The JSON support for DataPower falls under the Application Optimization strategy, but is
provided as part of the base functionality of the DataPower product line. It does not
require that you purchase the Application Optimization feature.
For DataPower 5.0, JSON settings were added to allow the DataPower administrator the
ability to control and adjust the limits used by the JSON parser. Prior to this release, the
limits were fixed internal values that could not be changed. Customers ran into constraints
that were too small for their applications.
With the JSON Parser settings, developers can adjust the behavior of the parser to fit their
needs. And, administrators can protect their environments by enforcing threat protection
limits.
DataPower_5.0_AppOpt.ppt
Page 4 of 23
JSON Constraints – Pain Points
� Constraints on JSON Parser were fixed and insufficient
– Labels of 256 and value strings of 8192.
– Added a variable that could be used to dynamically change the constraints
• var://service/json/string/max-value-length
� JSON Accounting inconsistencies
– Maximum string size was correct only for non-escaped and non-special character ASCII
• Special Characters: ‘&’, ‘<‘
• Escaped Characters: \uxxxx (unicode), \r, \t, etc..
– Mix of XML and JSON accounting
• “\u005C” becomes “&#x005C;” – Six characters versus eight.
– “Label” strings different from “Value” Strings { “label&” : “value&” } – Lengths of 6 vs 10.
• Internally, there are different APIs for attributes and elements
5
Application Optimization
© 2012 IBM Corporation
For releases prior to DataPower 5.0, the JSON Parser had limits such that label strings
could be no larger than 256 characters, and value strings could be no larger than 8192
characters. A service variable was added to allow an administrator the ability to override
these constraints. This variable is cumbersome to use. The best practice is now to use
the JSON parser settings rather than to use this service variable.
In addition to the JSON constraints being too constricting, there were a set of accounting
inconsistencies. For example, the number of characters in a given string was only correct
for non-escaped and non-special characters. If escaped or special characters were
included, the numbers varied. Similarly, the translation of JSON characters to XML
characters had some inconsistencies. Finally, the strings used for labels and values used
different accounting methods. The result is that the numerical size of a string was very
difficult evaluate. For DataPower 5.0, each character in the JSON payload counts as a
single character. If an escaped character such as “\t” is encountered, it is counted as 2
characters – one for the ‘\’ and one for the ‘t’.
DataPower_5.0_AppOpt.ppt
Page 5 of 23
JSON Constraints – General background
� JSON is parsed into a JSONX (XML representation of the JSON body).
� A context __JSONASJSONX is created as the JSON document being parsed.
� Both JSON parsing constraints and XML parsing constraints must be satisfied.
– Must be an association between the JSON settings and the XML settings (i.e. a
reference).
– If a constraint is violated, a 500 response is generated.
6
Application Optimization
© 2012 IBM Corporation
At this point, let’s step back for a moment and look at how DataPower handles a JSON
body. If the input type of the request is set to JSON, the JSON parser will be
automatically invoked when a JSON body is received. JSON is parsed and converted into
an XML representation of JSON known as JSONX. The JSONX document is placed in a
context named __JSONASJSONX.
The beauty of this operation is that once the material is converted to XML, you can use
XSLT style sheets to manipulate or verify the material any way you wish. In effect, you
are unleashing the DataPower flexibility to perform deep packet processing on JSON
documents.
The conversion of the JSON document into JSONX has some implications that the
administrator or developer needs to be aware of. For a JSON document to be properly
read in and converted into JSONX, the JSON parsing constraints and the XML parsing
constraints must be satisfied . If a constraint is violated on either the JSON side or the
XML side, the request will fail the processing, and a 500 response will be returned.
The JSON constraints are specified in the JSON Settings Object. The XML constraints
are specified in the XML Manager Object. The JSON Settings and XML Manager Objects
are linked together via a question in the XML Manager that identifies the JSON Settings
Object that should be used when JSON documents are to be processed. If no JSON
Settings object is specified in the XML Manager that is used to process an inbound
request, default values for the JSON Settings object will be used.
DataPower_5.0_AppOpt.ppt
Page 6 of 23
JSON Constraints – Where they apply
7
Application Optimization
© 2012 IBM Corporation
This is a simple example of a JSON object that shows you where the 5 constraints come
in to play.
The upper left oval is around a JSON label, “Image” . The “Maximum Label Length”,
measured in number of characters, limits the number of characters used in a label. In this
example, the Label length is 5.
The second oval is around a JSON number, “800”. The “Maximum Value Length for
Numbers”, measured in the number of characters that the number, its sign, and exponent
uses, limits the number of characters used in a number. In this example, the Number
length is 3.
The rectangle around “http://www.example.com/image/481989943” shows a value that is a
string. The “Maximum Value Length for Strings”, measured in number of characters, limits
the number of characters used in a value string. In this example, the value String length is
38.
The arrows pointing to the curly brace characters ‘{‘ indicate the nesting level of a JSON
document. The nesting depth is measured as the largest number of non-closed ‘{‘
characters at any point in the document. The “Maximum nesting depth” is measured in
levels. In this example document, three unanswered ‘{‘ characters are present at the point
following the location immediately after the following sequence: “Thumbnail”: { . Thus, the
nesting level is 3.
Finally, the entire document is contained in the document size. Measured in bytes, the
JSON document that is received may not contain any more bytes than specified in
“Maximum document size”.
DataPower_5.0_AppOpt.ppt
Page 7 of 23
JSON Constraints – New JSON Settings Object
8
Application Optimization
© 2012 IBM Corporation
This is the new JSON Settings configuration object. Note that on the left hand navigation
panel, the JSON Settings is listed under the category JSON Processing.
There are two categories of questions: Label-Value pairs and Threat Protection. These
questions allow you to specify the constraints discussed on the prior slide.
The default values for these fields are the same as the original constraints used by prior
releases.
DataPower_5.0_AppOpt.ppt
Page 8 of 23
JSON Constraints – XML Manager update
9
Application Optimization
© 2012 IBM Corporation
Earlier, we mentioned that there must be an association between the XML Manager and
the JSON Settings object. This is where you establish that relationship. In the XML
Manager, you must specify which JSON Settings object you plan to use for processing
JSON documents. If no JSON Settings object is specified, but you are processing JSON
documents for a given service, then the default JSON settings will apply.
DataPower_5.0_AppOpt.ppt
Page 9 of 23
JSON Constraints – Interdependencies between JSON and XML
{"label":"value"}
<?xml version="1.0" encoding="UTF-8"?>
<json:object xsi:schemaLocation=
"http://www.datapower.com/schemas/json jsonx.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema­
instance"
xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">
<json:string name="label">value</json:string>
</json:object>
� Both JSON and XML constraints are in play.
– JSON Documents are smaller than XML documents
•In the example, the JSON document contains 18 characters, the XML document contains 289.
•Most of expansion in example is due to XML declaration and namespaces
•Tag names and Attribute names also are generated in XML
•Special characters (e.g. &, <) and escaped characters (e.g. \u005C, \r) are larger in XML
10
Application Optimization
© 2012 IBM Corporation
How do we know what values to set for these JSON Settings and XML parser limits? The
next two slides will give you some ideas on how to configure these settings.
The code snippets at the top are of a simple JSON document and the XML document that
is generated as JSONX. You can see that there is significant expansion from JSON to
XML. This is especially true of very small JSON documents where the XML counterparts
contain namespace information. This overhead is a fixed cost, and contributes less to the
expansion for larger JSON documents. The XML information that is in red represents the
variable cost that is proportional to the JSON information. In this example, it is about 3
characters of XML for every character of JSON. But you can easily see that you can
create scenarios where the overhead is extremely high like 50 to 1. Or, a scenario where
the overhead is very low (e.g. 1.2 to 1).
Not shown in this example is expansion due to special characters and escaped
characters. These will also typically be larger in the XML representation than in the JSON
representation.
DataPower_5.0_AppOpt.ppt
Page 10 of 23
JSON Constraints – JSON constraints vs XML constraints
� General rule of thumb is that the XML constraints should be at least double the size of the
largest JSON document constraint
� XML Bytes Scanned should be at least double the JSON Maximum Document Size
� XML Element Depth should be greater than the JSON Maximum Nesting Depth plus 2
� XML Maximum Node Size should be at least double the JSON Maximum Value Length for
Strings.
11
Application Optimization
© 2012 IBM Corporation
Given the expansion discussed on the previous slide, the XML parser constraints specified
in the XML Manager must be larger than the JSON parser constraints specified in the
JSON Settings object. Here are some suggestions for configuring the XML constraints
given a specific set of JSON Settings.
In general, the XML constraints should be two to three times higher than the
corresponding JSON constraint. As shown in the prior slide, there is overhead involved in
mapping the JSON object into XML elements. A JSON label becomes an XML attribute.
A JSON value becomes an XML element. Therefore, the XML Manager’s XML Bytes
scanned should be two to three times the size of the JSON Maximum document size.
And, the XML Manager’s XML Maximum node size should be two to three times the size
of the JSON Maximum value length for strings.
The Maximum nesting depth for JSON is very similar to the nesting depth of the XML
document, thus you only need to have the XML Element Depth set to a few greater than
the JSON Maximum nesting depth.
DataPower_5.0_AppOpt.ppt
Page 11 of 23
JSON Parser Settings
Troubleshooting
Because both the JSON Parser Settings and the XML Parser Settings are used when a
JSON document is being processed, if any constraint is hit, a log message will be
generated indicating the constraint that was hit.
12
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
The JSON Settings work with the XML Manager parser settings for every JSON document
that is processed. If the JSON document exceeds any of the constraints when being read
in, the JSON parser will log an error message indicating the constraint that was violated.
The response will be returned with a 500 error response code. If an XML parser
constraint is hit while the JSONX document is being constructed, the XML parser will log
an error message, and again, the response will be returned with a 500 error response
code.
DataPower_5.0_AppOpt.ppt
Page 12 of 23
Application Optimization
JSON Parser Settings
AO on XG45
WAS Version Update
13
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
Next, we will discuss the addition of the Application Optimization feature to the XG45.
DataPower_5.0_AppOpt.ppt
Page 13 of 23
AO on XG45
What It Is
The Application Optimization feature is now available on XG45. This is an optional feature
which is field upgradeable.
Why It Is
Provides Application Optimization for consolidation in the DMZ resulting in a simplified
network, fewer products, and lower Total Cost of Operation.
Who Wants It
Customers that want to reduce costs and simplify their networks.
14
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
The Application Optimization feature is a popular feature on XS and XI platforms. It is now
available on the XG45 platform.
The strategy behind Application Optimization begins with analyzing the products and
functions that are used in the DMZ and in the ESB. Over the years, there have been
numerous changes in these areas to improve the efficiency of the overall traffic flow. It
makes sense to perform security, encryption/decryption, modifications, and routing
decisions in as few products as possible. Each product that a request passes through
causes an additional delay in the processing of that request. The request must go up and
down a protocol stack for each processing hop.
If we can consolidate all of the operations into a single DataPower platform, then not only
have we made each transaction more efficient. We have also simplified the network by
removing tiers of platforms. The result is a substantial savings to the business. The
business saves on the obvious investment of the functions replaced in software and
hardware costs. But even more important, the maintenance and security costs which are
continuing operational costs are significantly reduced when the number of platforms is
decreased.
The Application Optimization feature on the XG45 strives to provide a collection of
functions that can replace other platforms reducing costs and improving the efficiencies
within the network.
DataPower_5.0_AppOpt.ppt
Page 14 of 23
AO on XG45
� Same AO feature set as that provided for XS and XI
– Self Balancing (Replace a front side load balancer or IP sprayer) w/ HA
– Intelligent Load Distribution (Replace a back side load balancer)
• Topology Learning for WAS ND, VE
• Session Affinity (Passive, Active, Active Conditional)
• Weighted Least Connections load Balancing Algorithm
– Application Intelligence (VE Only)
• Application Edition Support
• Group Rollout – Identify a subset of the cluster to update
• Atomic Rollout – Half of the cluster updates with distinctive switchover.
– Secure Cloud Connector – Secure tunnel to a host on the cloud
15
Application Optimization
© 2012 IBM Corporation
This is a list of the most important aspects of the Application Optimization feature. The
feature is the same as that provided on the XS and XI platforms.
The Self Balancing feature is designed to eliminate the need for a front side load balancer
or IP sprayer. A primary DataPower appliance is elected from a tier of appliances. All
traffic is received by the primary and is distributed to each of the other members in the tier
while also processing some portion of the traffic directly. If the primary fails, a secondary
is elected and becomes the primary. One key to the failover is that the secondary
appliances all maintain copies of the primary’s control tables. So, most connections are
unaffected when failover occurs.
The Intelligent Load Distribution (ILD) is a feature that helps DataPower replace a back
end load balancer. DataPower has always had a rich load balancing collection, but ILD
takes it to the next level. The first aspect is “topology learning”. ILD comes with a servlet
that can be installed on a WAS ND cell. The servlet is periodically queried by the
DataPower platform to retrieve servers, their weights, and session affinity information for
all members in a cluster. If the membership changes such as new servers being brought
on line or old servers being taken off line, the load balancer group that is feeding traffic to
that cluster will automatically change to distribute traffic to the proper set of servers.
Cookie based session affinity is also included in ILD. Session affinity allows a specific
client to be handled by the same server for all requests within a session. ILD supports
three modes of affinity. Passive affinity is where DataPower knows and understands the
WAS backend cookie format. If a request is received with a JSESSIONID, the DataPower
appliance will extract routing information from that cookie and forward the request to the
specific server. Active and Active Conditional affinities work with WAS and/or non-WAS
servers. In Active and Active Conditional affinity, DataPower will append its own SetCookie under certain circumstances to allow it to channel requests to the server where
affinity was requested.
The third aspect of ILD is the addition of a new Weighted Least Connections (WLC) load
balancing algorithm. WLC uses weighting to provide a percentage framework of how
much
traffic should go to each server. The higher the weight, the larger the percentage.
DataPower_5.0_AppOpt.ppt
Page 15 of 23
Least Connections attempts to use the server with the fewest connections at that point in
time. A server that is responding slowly will have more connections up and in use than a
server that is responding quickly. The WLC algorithm takes both of these factors into
Table of contents
JSON Parser Settings
AO on XG45
WAS Version Update
16
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
Finally, we will discuss the versions of WebSphere Application Server Network
Deployment (WAS ND) and WebSphere Application Server Virtual Enterprise (WAS VE)
that DataPower 5.0.0 Application Optimization supports.
DataPower_5.0_AppOpt.ppt
Page 16 of 23
WAS Version Update
What It Is
The version of WebSphere Application Server Network Deployment (WAS ND) and
Virtual Enterprise (WAS VE) has been updated.
Why It Is
Provides support for the latest versions of WAS ND and WAS VE. It also provides
some additional benefit that DataPower customers will see.
Who Wants It
Any customers that are currently using the Intelligent Load Distribution of the Application
Optimization feature.
17
Application Optimization
WebSphere DataPower Release 5.0.x
© 2012 IBM Corporation
DataPower 5.0 was tested against the latest versions of WAS ND and WAS VE. This
section will discuss the versions that are supported for Intelligent Load Distribution and
Application Intelligence for the Application Optimization feature.
In addition to testing with the latest versions, we wanted to test some specific scenarios
that are of interest to our customers. These scenarios take advantage of some of the
latest updates in WAS.
DataPower_5.0_AppOpt.ppt
Page 17 of 23
WAS Version Update
Original (DataPower 3.8.1):
WAS ND 6.0.0, 6.1.0, 7.0.0
WAS VE 6.1.1
ODCInfo_ND60,
ODCInfo_ND61/OSGi
New (DataPower 5.0.0):
WAS ND 6.1.0, 7.0.0, 8.0.0
WAS VE 6.1.1, 7.0.0
ODCInfo_ND61/OSGi
LBG
18
Application Optimization
© 2012 IBM Corporation
The last update was done during the DataPower 3.8.1 release.
For DataPower 5.0, WAS ND 6.1.0.x, 7.0.0.x and 8.0.0.x are all supported. WAS VE
6.1.1.x and 7.0.0.x are also supported.
In DataPower 3.8.1, there were two WAR files that were shipped. In 5.0.0, only the
ODCInfo_ND61.WAR file is valid. ODCInfo_ND61.WAR will run on WAS ND 6.1.0.x,
7.0.0.x, and 8.0.0.x
DataPower_5.0_AppOpt.ppt
Page 18 of 23
Handling Sick, but Not Dead Back End Servers
� Weighted Least Connections (AO feature)
– Attempts to create or use connections to server with fewest “in use”
connections.
– Back pressure causes new requests to be channeled to the healthy servers.
– With persistent connections, the connections remain up, and are reused.
– With non-persistent connections, the responsive servers will have fewer
connections.
– Rerouting happens in milliseconds.
– Problem: timed out requests are replaced by new requests.
20
20
LBG
20
19
Application Optimization
© 2012 IBM Corporation
One of the questions we get from customers is, “How does DataPower behave when a
server is sick, but not dead?” A sick, but not dead server is one where connections can be
established to the server, but the response is much slower than from other servers.
The Weighted Least Connections algorithm (part of the Application Optimization feature)
gives a superior response over other load balancing algorithms. For example, if a
Weighted Round Robin algorithm was used and the server weights were the same, the
sick server would continue to receive requests at the same rate as the healthy servers. In
the example, this would result in almost one third of the traffic being sent to the sick
server. If the Weighted Least Connections algorithm is selected and all servers have the
same weights, connections to the sick server would remain up for long periods. This puts
back pressure on the system and causes new connections to go to the healthy servers.
The result is an immediate redirecting of traffic to the healthy servers.
The algorithm balances things out such that the number of established connections to
each server at a given time would be roughly the same number, but the traffic per
connection would be much greater to the healthy servers.
This scenario does show a problem. If, for example, the sick server accepted
connections, but never responded, then DataPower would continue to set up new
connections to the sick server as the old connections age out and get recycled. And, the
number of connections is proportional to the weight. In the next slide, we address this
problem.
DataPower_5.0_AppOpt.ppt
Page 19 of 23
Handling Sick, but Not Dead Back End Servers
� WebSphere Virtual Enterprise Role
– Dynamically controls the weights based on
•Response Times as measured by the container
– Weights are reduced for lethargic servers
•DataPower activates current weights upon next refresh
� Reduces the number of requests that will be attempted to Sick server redirecting
them to the healthy servers.
1
20
LBG
20
20
Application Optimization
© 2012 IBM Corporation
The Weighted Least Connections algorithm on the prior slide shows that traffic can rapidly
be rerouted to healthier servers. The problem was that if the weight for the sick server is
high, it still receives more connections than we would like.
WebSphere Virtual Enterprise (WAS VE) provides a solution to this problem. WAS VE
measures response times at the container, and adjusts weights dynamically based on
these values. For servers that are lethargic, WAS VE will lower the weights associated
with that server. DataPower will dynamically pick up the new weight and will drop the
weight associated with that member to reduce the number of requests far beyond where
the Weighted Least Connections algorithm left off.
DataPower_5.0_AppOpt.ppt
Page 20 of 23
Dynamic Clusters now work with DataPower AO
� WebSphere Virtual Enterprise
– Spins up additional servers when CPU utilization thresholds are exceeded
– Stops servers when they are below a certain threshold
� DataPower adapts to the addition or removal of servers
� Requires WAS VE 7.0.0
� No change to DataPower AO
20
20
20
20
LBG
Source: TJSMITH
21
Application Optimization
© 2012 IBM Corporation
Another area of interest is in Dynamic Clusters. Dynamic Clusters are a feature in WAS
VE where the administrator pre-configures server instances. These instances remain off­
line until average CPU utilization on the back end reaches a certain configurable
percentage. Once that happens, an additional server is brought on-line. Then another.
And another. This continues until the CPU utilization is reduced to a tolerable range.
Likewise, when the average CPU utilization falls below a certain range on the back end,
servers will be stopped and taken off-line.
DataPower with ILD will automatically see the addition or removal of servers and will
reflect that in its load balancer group membership.
This function requires WAS VE 7.0.0 on the back end.
DataPower_5.0_AppOpt.ppt
Page 21 of 23
Questions
22
Application Optimization
DataPower_5.0_AppOpt.ppt
© 2012 IBM Corporation
Page 22 of 23
Feedback
Your feedback is valuable
You can help improve the quality of IBM Education Assistant content to better meet your
needs by providing feedback.
� Did you find this module useful?
� Did it help you solve a problem or answer a question?
� Do you have suggestions for improvements?
Click to send email feedback:
mailto:iea@us.ibm.com?subject=Feedback_about_DataPower_5.0_AppOpt.ppt
This module is also available in PDF format at: ../DataPower_5.0_AppOpt.pdf
23
Application Optimization
© 2012 IBM Corporation
You can help improve the quality of IBM Education Assistant content by providing
feedback.
DataPower_5.0_AppOpt.ppt
Page 23 of 23
Trademarks, disclaimer, and copyright information
IBM, the IBM logo, ibm.com, DataPower, and WebSphere are trademarks or registered trademarks of International Business Machines Corp.,
registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of other
IBM trademarks is available on the web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml
Other company, product, or service names may be trademarks or service marks of others.
THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE
MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED
"AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT
PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR
ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION.
NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY WARRANTIES OR
REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF ANY AGREEMENT
OR LICENSE GOVERNING THE USE OF IBM PRODUCTS OR SOFTWARE.
© Copyright International Business Machines Corporation 2012. All rights reserved.
24
DataPower_5.0_AppOpt.ppt
© 2012 IBM Corporation
Page 24 of 23