Database Design and the Demands of Operational Business Intelligence

Anant Gupta, SOA Practice Director

When hearing the term Business Intelligence the first thought that springs to mind is that of reporting and trend analysis based on historical data. So what exactly is Operational Business Intelligence (BI)? It almost seems to be an oxymoron. In one sentence, it is the mechanism of enabling everyone, and not just the strategy team as in the case of BI, to make decisions that improve the top-line, bottom-line or enhance customer satisfaction. These decisions are not made quarterly or yearly but on a transactional basis. A very simple example of operational intelligence is your GPS system telling you to take a different route to work because of a bad traffic condition on your regular route. To make this more interesting, let’s assume that your system not only understands the traffic conditions, but also gas prices, your schedule, tolls, etc., and needs to present you the most effective option based on all of these factors. To do this, it needs to perform a lot of analysis in real-time. Similarly, systems need to look at the product / promotion info and customer purchase history / status and determine cross-sell, up-sell opportunities.

So far we have been talking about transactional databases or data warehouses / data marts, one for OLTP and the other designed strictly for post-facto reporting and analysis. The new trend will be a middle path where we will be designing data marts that will have the capability to be queried and performing analysis in real time. There will also be a trend that will emerge to update the operational data stores with updates from the data warehouse. Essentially, data warehouses will be able to continuously analyze data, recognize and send events that operations will subscribe to. For example, I might be interested in subscribing to an event if merchandise returns for one of my product lines exceed 5% of normal returns. So, databases will need to start understanding events and perform continuous analysis to determine the occurrence of any of those events.

All of this imposes challenges to the database design as both the depth of analysis and performance will have to be delivered simultaneously.

Anant Gupta was recently named the SOA Practice Director at Prolifics after serving as a Senior Business Integration and J2EE architect Anant has with extensive experience in IBM's SOA software portfolio and specializes in delivering business integration and business process management solutions. He has worked for major clients in the banking, insurance, telecommunications and technology industries.

Web Application Security Considerations

Andy Blank, Security Practice Solution Director

Should you consider doing anything about Web Application Security? Here’s a quick self assessment test for all the many application developers and infrastructure specialists out there. Answer the following questions as honestly as possible.

While building customer web applications (Portals, UI front ends to business processes, SOAInfrastructure, message flows, Web services, etc.), I think of security:

• First, foremost in priority, and continuously throughout!
• As one step in my development process.
• As a separate set of tools (identity management, access management, etc.) handled by a security team.
• Security? Isn’t that the job of the imposing looking person in the elevator lobby?
  

I would guess that the applications I develop/deploy have significant security holes:

• Never! I am a gift to modern development perfection!
• Half the time.
• Three quarters of the time.
• I really have no way of knowing.
  

Unless you honestly answered ‘a’ to both questions, you should take a hard look hard look at Web Application Security -- including coding practices, vulnerability testing, managing system access, and system configurations. 75% of all current internet based attacks are made against the application layer. In addition, security companies such as Symantec surmise that up to 80% of existing web applications have at least one significant exploitable vulnerability.

Since joining Prolifics in 1994, Andrew Blank has held key positions such as Senior Technical Support Engineer, Manager of Training Services, Senior Consultant, and Migrations Practice Manager. Currently, as one of Prolifics’ Solution Directors and as leader of the Security Practice, Andrew takes part in the design, development and delivery of Prolifics’ projects for such clients as Marsh & McLennan, MetLife and UPS. His expertise in J2EE architectures, portal solutions, IT security, and systems monitoring is integral to the company’s strategic planning for adoption and use of new product technologies.

Messaging: JMS vs SCA

Ivan Smirnov, Senior Consultant

In SCA, bindings are the means of transporting data (messages) to and from modules. One specific application I’d like to discuss is messages between SCA modules: that is, when one SCA module calls another SCA module. There are several types of bindings that can be used in that scenario. The easiest is, I kid you not, the SCA binding. At runtime, it becomes an EJB call. SCA binding was designed specifically for inter-module calls and it is so good at this, it makes you wonder: why use any other binding type at all? Well, if you need more flexibility, JMS binding may be handy.

SCA binding is best suited for simple synchronous calls between modules. It is possible to use SCA binding for an asynchronous invocation, but it will be implemented on auto-generated JMS queues on a SCA SYSTEM bus. With little control over queues, this option does not provide all the benefits of JMS binding.

Advantages of SCA bindings over JMS bindings:

• They do not require any external configuration and thus are maintenance-free.
• Interfaces are early bound. Interface types are checked when binding is established, and the Export interface must match the Import interface. This eliminates a possibility of errors not discovered until runtime.

Advantages of JMS bindings compared to SCA:

• More flexibility: target module can be relocated (even to a different cell).
• You don’t have to use the same interface on both sides of binding. Even method names may be different on caller (module Import) and target (module Export), so long as payload type is correct.
• There is an easily accessible checkpoint between modules(a JMS destination) where messages may be inspected for troubleshooting/debugging purposes.
  

In addition to this theoretical analysis, let me share my experience. I experimented with inserting JMS binding between modules where SCA was a natural fit, just for error handling purposes. My idea was that it would be much easier to control message flow and retry logic if there was a JMS queue between modules that I could configure to my liking. As intriguing as it sounds, there was too little real benefit in that specific ESB solution. So my conclusion was that error handling is not sufficient justification for using JMS binding where SCA binding is a more natural fit.


Ivan Smirnov is a Senior Consultant at Prolifics with extensive hands-on experience with the WebSphere family of products (including WebSphere Application Server and Process Server, WebSphere Studio/Rational and WebSphere MQ), Tivoli security offerings (including Tivoli Identity Manager and Tivoli Access Manager for e-business), DB2, XML and Web Services. With strong technical skills both in development and administration, as well as deep troubleshooting skills, Ivan handles aspects of implementation installation, configuration, securing and tuning/troubleshooting to development and architecture within a J2EE environment. He also possesses key Application Server migration skills and has helped several customers’ transition to the WebSphere platform from other J2EE platforms.

SOA and Off-Shore Project Models

Jonathan Machules, Technology Director

SOA is, as it was hyped by the marketing machines years ago, the next maturity level in Architecture. Service Orientation adds another level of design, development and maintenance considerations to projects. Another trend in the industry is the off-shore model of development of these projects. You can see why project success with these maturing trends is largely dependent on the personnel involved.

At Prolifics we are leaders in both these areas. We have expertise in SOA Methodology, Design and Architecture across all functional and non-functional domains complimented by a proven off-shore methodology that delivers.

On a recent SOA project using off-shore resources I had 2 months to Architect and Design an Enterprise Integration Platform for a large financial company seeking to use a combination on-shore/off-shore model for the Design and Development of Enterprise Integration system based on SOA.

This combined model works well with the right pieces in personnel in place. Capable developers with the ability to learn new technologies, strong project management and architectural leadership. Couple this with proven communication strategies and process for corresponding tactical direction and deliverables and there is a model that can work in the face of new technologies and regionally separated personnel.

The pay-off for this model combination is reduced cost and time to market. Given the economic times I foresee we will see a fair amount of interest and subsequent implementations with such models.

-Jon

Jonathan Machules first joined Prolifics as a Consultant, and is currently a Technology Director specializing in SOA, BPM, UML and IBM's SOA-related technologies. He has 12 years experience in the IT field — 2 of those years at Oracle as a Support Analyst and 10 years in Consulting. Jon is a certified IBM SOA Solution Designer, Solutions Developer, Systems Administrator and Systems Expert. Recent speaking engagements include IMPACT on SOA End-to-End Integration in 2007 and 2008, and SOA World Conference on SOA and WebSphere Process Server in 2007.