Tuesday, July 23, 2013

Prolifics and IBM's Digital Experience Software: Enhance, Extend and Enrich...

by Niral Jhaveri, Vice President,  User Experience, Prolifics

Hopefully you got a chance to attend IBM’s recent digital experience launch.  I know we’re excited about the evolution in IBM technology which will provide our customers even better ways to personalize content for their site visitors. It also excels in the analyzing and optimizing of site and campaign performance to drive desired results.  For example, With IBM’s Digital Experience Software, we can further help our portal and collaboration customers develop and manage dynamic content and rich media while delivering multi-channel applications - providing the ultimate, optimized customer experience. Prolifics is dedicated to providing customers with solutions that promote collaboration, empower conversation and bring together communities. Leveraging IBM’s Digital Experience technology stack, Prolifics can assist companies:

Upgrade to IBM Digital Experience
Migrate systems from older versions to IBM Digital Experience

Multi-channel extension of applications to mobile and tablets
Extend business applications beyond conventional desktop
Creating a mobile strategy

Conduct health checks on aging applications
Provide tuning to improve performance and improve application longevity

Check out our latest video to see Watch for more on how Prolifics empowers businesses with mobile, social & collaboration.

Friday, July 19, 2013

Avoiding Future Interface Changes in IBM ODM Rule Services

When building and deploying an IBM ODM[i] business rule based service, one aspect to carefully consider is the structure and composition of the rule service interface; what will become the WSDL in a SOAP/WS HTDS[ii] implementation. Because all service consumers are dependent on this structure, frequent changes to this interface can result in significant rework for all consumers as well as code changes in the rule service itself. Additionally, supporting each interface change introduces change dependency between all consumers and the service. There are ways to avoid this complexity by introducing more flexibility in the service interface. However each technique comes with its own set of tradeoffs that must be carefully considered.

There are three basic approaches. To illustrate, imagine a rule service that determines if a company will accept a transaction from a US customer. In the initial and most simple version, the company policy is to refuse a transaction from any customer under the age of 21. Age is the only decision criteria. In a future version of the same service, the decision criteria becomes more complex when it is determined that the threshold age should vary based on the customer’s US state of residence.

Small, fast, and simple

In this approach the rules service interface contains only the data required by the service to perform the implemented decision point. The structure of the data in the interface is flattened with respect to the decision point implementation and attribute names represent the business decision criteria. The objects in the interface can be used directly in the rule BOM and the default verbalizations will likely be sufficient. No additional mapping of data is required. Marshaling/de-marshaling and transport overhead is kept to a minimum allowing very rapid service response. In later versions of ODM[iii], a REST implementation becomes a viable option with a small number of specific input attributes related to the decision and low transportation overhead. This approach is fast to implement, execute, and easy to change in initial development, but is the least flexible to future change once deployed. Any future additional data requirement in the decision point will require an interface update to accommodate the change. This technique is best used to quickly develop a rule service with rapid changes to the decision criteria while still in development.

In our example to identify customers below the age of 21, the interface initially may only consist of a customer identifier and the customer’s birthday. However our future implementation that observes the customer’s US State of residence will require a service interface change to add this attribute. Concurrent execution of old and new versions of the rule service requires strict versioning of the WDSL and therefore the rule app / rule set.

Enterprise Data Model

In this approach, the rule service interface consists of the entire enterprise data set that may be used to perform the implemented decision point, even if most of the data is unobserved in the initial rule implementation. In other words, the caller passes everything it currently knows about the subject of the decision in the event future rules might need additional information. This approach provides a more comprehensive data interchange, but is limited by the quality of the data model. This approach is most commonly used with vertical industries that have a well defined and widely accepted object model such as those defined by standards bodies such as ACORD, MISMO, EDI Standard formats, HL7, et al. The objects in the interface typically contain several levels of hierarchical data and maps poorly to a flatter, business-oriented BOM desirable in business rule implementations. This commonly necessitates at a minimum custom BOM verbalizations, and frequently mapping of the interface object to a flatter and less normalized form; all adding to the time and effort in rule implementation. However, the advantage is that future rules are less likely to require an interface change IF the enterprise data model is complete, stable, and universally accepted. Because the interface is typically large, in the case of most SOAP web services and message-based architectures, marshaling/de-marshaling, transportation overhead, and remapping become the overriding performance constraints rather than rule execution times.

Using our example rule service implementing a decision point to identify customers below the age of 21, the initial interface would consist of everything about a Customer tracked in the enterprise data model. This will likely include the customer’s birthday allowing age to be derived. When the service needs to expand in the future, allowing the age threshold to vary by customer location, no interface changes will be required if the enterprise model already includes the US state of the customer’s residence. A ‘rules-only’ change can be made to add BOM mappings for the newly required attributes and the rules written using these new attributes. This approach should be avoided if the enterprise data model changes frequently or is unlikely to include future required data elements. Frequent changes in the enterprise model result in changes to the rule service interface even when the model changes do not affect the current rule implementation in order to remain consistent with all rule service consumers. And using this technique requires all consumers and rule services to implement the same version of the enterprise model. If the data model is unstable, managing this dependency alone can negate any flexibility gained with the more comprehensive initial interface.

Generic Key/Value Pairs

In this approach, the rule service consists of a generic list of key/values pairs commonly implemented as a Map or map-like structure. The ‘key’ is a string describing a business attribute name and the ‘value’ is the value of that attribute. This allows any data to be passed to through the rule interface without structural changes in the rule service interface itself and represents the most flexible interface style. Using the previous example of a rule service determining transaction acceptability based on customer age, the interface could initially have a list of keys ‘customerID’ and ‘customerBirthDate’ with their corresponding values. If in a future version, customer location becomes required, the caller would simply add a key ‘customerLocation’ to the list in the interface and provide a value for this information to the rule service in the granularity required. However, the rule service needs to be aware of all the possible key values. These are typically maintained manually as a static or dynamic enumeration in the rule source so business attributes may be properly mapped to BOM vocabulary. This has a distinct advantage over the enterprise data model scenario in that only the data required in any given version of the service is actually passed through the interface to the rules.  This keeps marshaling and transportation overhead low, but still allows for new data to be added without changes to the structure of the rule service interface.

However using this approach means it is more likely that the callers of the rule service will need to make corresponding coding changes to support future data requirements in the rule service. This will often invalidate the advantage that the rule service may be changed without java code alteration. An additional concern with this approach is the loose typing and late binding of the interface elements. While this provides flexibility in the data passed, it effectively places additional run-time validation requirements on the rule service to ensure that the interface data expected is actually provided and typed correctly. Finding the rule service implementation out of sync with the implementation and expectation of multiple consumers is a common problem with this approach.
[i] Operational Decision Management, formerly known as IBM ILOG JRules or WODM, WebSphere Operational Decision Management
[ii] Hosted Transparent Decision Service, a feature of IBM ODM that exposes a ruleset as a SOAP Web service
[iii] REST API supported in ODM V8.5 and later
Written by Lawrence Terrill, Technical Lead, Prolifics Business Decision Management Practice

Wednesday, July 17, 2013

Watch This! Google Hangout: Using Application Performance Diagnostics Tools to Increase the Effectiveness of Shift-Left Testing

How many times do software developers need the ability to debug their application on a live server? Most developers have great code profiling tools used against their local development working environment, though are often challenged to get similar data from a fully deployed application environment. The unit tests may have passed and given good results in the local development environment, though has issues in the fully deployed environment.

We at Prolifics are using the newly released IBM Application Diagnostics Lite tool to provide our own and customers software developers a quick easy tool to use in troubleshooting issues on a single application server running IBM WebSphere and Portal. This tool provides a quick deployment to provide insight into the execution of requests running on the App Server, for real time viewing or recording for offline review. Our WebSphere and Portal developer, architects and administrators are always interested in new and valuable troubleshooting tools.

One of the best features of APD Lite, is that it is a free download from IBM, only requiring a valid ID on the IBM.com website. You can carry this tool on a USB memory stick and provide quick value to your project.

I  recently participated in a Google Hangout with IBM experts where we discussed the benefits of IBM's application performance diagnostic tools and how they can help application teams reduce time and effort associated with shift-left testing.

Click here to watch!

The purpose of shift-left testing is to reduce costs by identifying and eliminating issues earlier in the application development life cycle. Compare that to the purpose of application performance diagnostics tools, which is reduce the time and effort required to identify and resolve issues, and it's easy to see how these tools could provide value when used as part of one's shift left testing practices. Join Redmonk Analyst Donnie Berkholz as he leads a discussion with IBM and Prolifics experts on the how IBM's application performance diagnostic tools can help application teams test their code early and often. We'll discuss the concept of shift-left testing and identify use cases in which tools can be used to reduce the time and effort necessary to effectively implement shift-left testing.

Roundtable panelists:
  • Dan Kern, Solution Architect, Prolifics
  • Donnie Berkholz, RedMonk Analyst
  • Dan Berg, IBM Chief Architect at DevOps
  • Lindsay Farmer, Release Manager, Application Performance Diagnostics
  • Joydeep Banerjee, Architect, Application Performance Diagnostics
  • Todd Kindsfather, Product Manager, Application Performance Diagnostics
Want to connect? Email me at dkern@prolifics.com.

To learn more about Prolifics, visit www.prolifics.com.
Dan Kern is a Solution Architect at Prolifics and an IBM Champion for Tivoli. Dan joined Prolifics as a Senior WebSphere Administrator and Performance Tuning expert. Over the past 7 years, he has held roles as a Technical Solution Director, Practice Director for the Automation and Systems Management area and now helps customers realize the full potential of their software investments as a Solution Architect. Dan is highly regarded in the Tivoli SAPM product and business areas and continues his focus on top quality solutions.

Wednesday, July 3, 2013

Using HTDS with Java XOM in IBM Operational Decision Manager 8

Until version 7.1, IBM ILOG-JRules had Hosted Transparent Decision Service (HTDS) working only when you had dynamic Execution Object Model (XML XOM). However, in IBM Operational Decision Manager (ODM) 8, IBM enables you to still use the HTDS when have static XOM (java XOM).

Though this is good for the projects where XOM was defined in Java and Rules needs to be exposed as Web-Service, in ODM 8 we don’t have to write custom web-service code for exposing Rules as Web-Service if you have Java XOM. This saves a significant amount of time, however, there are still some changes you can make if you have Java XOM to make it work with HTDS in ODM 8 seamlessly.

When you deploy your Rules and Java XOM in RES internally, your Java XOM gets converted to XML format and then it gets exposed through the WSDL to call your Rules as Web-Service.

The caveat here is when the conversion from Java XOM to XML format happens inside RES for HTDS you need to tell the engine how XML will get generated. For example if you have List and Date in your XOM you need to generate XML elements accordingly and change the date format from Java util date to XML date.

As we know there isn't a unique correct mapping between Java Object structures and XML documents. We will need to use Java XML binding implementations to provide ways to fine tune the mapping.

For converting your Java XOM seamlessly into HTDS and working with Web-Service (Request/Response) you will have to use JAXB annotations to tell the engine the specific format you want your XML to be generated.

Below is the code how you should be annotating your List in Java XOM.

Let’s say you have your Java code for List defined below:

List yourObjectList = new ArrayList();

In the getter method you need to have your annotations defined like below.

Note: You can give any string for your name (name = "YourObjects") in the annotation but whatever you define here will be part of your generated XML element in your Request/Response, so choose name as per your requirement. Some like it with List at the end while others prefer something Plural, like YourObjects.

When you are dealing with the Date in Java XOM in HTDS you need to have XmlAdapter class extended and then write your own class like below:

Then, wherever you get methods for your date, you should annotate that as indicated below:

This will make sure the conversion from Java-XOM to XML format happening seamlessly.

Alok Keshri, a Technology Manager for Prolifics focusing mainly on ILOG-JRules and ODM space, has over twelve years experience in IT industry spanning across various industry, He is experienced and resourceful enterprise software Tech Lead/Architect and has worked with J2EE/ SOA/BRMS/ BPM technology. He is specialized in Object Oriented Analysis, Design, Development, and Estimation of project with heterogeneous Web technologies in complex business systems based on variety of platforms, he has extensive experience in IBM middleware products such as WebSphere Application Server, WebSphere ILog-JRules, WebSphere Message Broker and other products in the IBM BPM stack. He is certified in WebSphere ILog-JRules and Filenet, Alok received his BE in Electrical Engineering in year 2000.