Integrating MQ FTE with WebSphere Process Server/WESB

Ivan Smirnov, Senior Consultant

WebSphere MQ File Transfer Edition (known simply as MQ FTE) is a robust managed file transfer solution built on WebSphere MQ transport backbone. Product page is here: http://www-01.ibm.com/software/integration/wmq/filetransfer/index.html

This product is a recent addition to the storied and extremely stable WebSphere MQ – it came out after MQ version 7. I was excited to hear about its release because it creates new possibilities in file transfer that FTP, SCP and the like never delivered – like reliability and tolerance of transient network failures. Immediately a question arose: how can we take advantage of these new capabilities in IBM’s middleware. What is the best way to integrate IBM’s premier integration platform, WebSphere ESB (and by extension, WebSphere Process Server) with MQ FTE?

Integration between WESB and MQ FTE will occur on 2 ESB boundaries: module exports that receive files from MQ FTE and module imports that send files to a remote destination via MQ FTE. I argue that the simplest integration approach is also often the best.

On the SCA export (send files via MQ FTE) side, we will configure MQ FTE file transfer using the tool’s native interface (command line or GUI). We then will use Flat File adapter in outbound mode to create a file on local file system where it will be picked up by MQ FTE. Protection from incomplete file pickup is provided by using staging directory, which is built into Flat File adapter.

The following alternatives are possible:

1) Construct the whole MQ FTE messages on the fly in WESB (for instance, by engineering an MQ FTE import binding)

2) Put file on file system the same way, using Flat File adapter, but initiate transfer by putting a request message on MQ FTE agent queue.

The first alternative approach requires duplicating a lot of code that is already in MQ FTE while providing minimal savings in terms of disk I/O. It is not a worthy alternative.

The second alternative approach is close to the original design. However, there is no need to predefine file transfer – this will be done by sending an XML message to administrative queue of MQ FTE. Its benefit is zero administration effort, but it requires some upfront custom development.

On the SCA import (receive from MQ FTE) side, we can configure MQ FTE to transfer files to a local WESB file system. Files will be picked up by Flat File Adapter in inbound mode. MQ FTE has built in protection against picking up incomplete files.

As an alternative, it is certainly possible to receive MQ messages in WESB instead of letting MQ FTE create files on file system. This alternate solution will require complex code largely duplicating existing MQ FTE functionality to extract file payload from MQ messages and handle file-level acknowledgement and auditing. The only upside would be avoiding disk I/O by skipping writing file to file system by MQ FTE and reading it in by Flat File adapter. There is not much value in this, since at such high volume WESB will reach capacity much sooner then disk I/O becomes a bottleneck. This alternate solution is all cost and no benefit.

Conclusion: when integrating MQ FTE and WPS (WESB), simplest solution is very reasonable and will work best in many situations.

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.

Good design and usability principles

Alex Ivkin, Senior IT Security Architect

I am a big proponent of usability. After all, regardless of how good something is, or how many cool features it has, if it is unusable – it is worthless. A hard to use application, website or in fact anything that interacts with a human, will not be popular, will lose out to competition or be ignored altogether. There are many articles on the web with examples and lists of usability principles, so I would not go into that here.

It seems, however, that many sites, like ss64.com or useit.com, suffer from a common pitfall in usability design, sacrificing design by going too far. They subscribe to the lowest common denominator in an effort to make it usable to the biggest possible crowd. This makes them very plain and downright ugly. Sure, they cover the 99% of the crowd out there, not the 95% a good design would cover, but in the push for these extra 4% they lose much in the beauty and attractiveness.

Ever wondered how Apple design wins praises so much? It’s not only created with usability in mind, it is also very attractive. Good, usable design after all has clues that are beyond simply making it readable or understandable. The clues are like little streaks of color on a bland background that make it come alive, make it stand out and win over a more “usable” background for most of people out there. Combining a creative effort with a usability agenda is the winning combination.

With that in mind here are the good usability design principles:

1. Start with a use-case. Run through how you think the users will approach the tasks and navigate through. You will be wrong, but that’s a start.
2. Think how it could be simplified. In many cases the simpler is the better. Many designs, like a single hand faucet handle, start off designed for the ease of use with simplicity and then they win over. Assume you are designing for people who are resource constrained: “the less brain I can devote to this task the better”
3. Be creative. Think how you can make it more attractive.
4. Consider performance. Yes it is a big usability factor.
5. Implement and fix bugs (another big usability factor).
6. Rinse and repeat.

What you can do to improve it if you have run out of ideas:

1. Think about HTTP/XHTML validation and CSS compliance
2. Focus on making it understandable by all kinds of colorblind people
3. Sprinkle with metadata, image tags and SEOs

An interesting twist to the discussion above was mentioned in a recent Wired article on ‘good enough tech’. The usability principles break down on the economics level somewhat. In other words if something is cheap enough, and usable enough, it will work for the most of us. So, think of where your design fits economically and how would it compete in that niche. If your stuff is cheap, it may work with a cheap design and being somewhat ok to use (think IKEA). If your stuff is free, it may limp by being somewhat unusable. Like this blog.

Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.

Human Centric Processes: A Fresh Perspective

Anant Gupta, SOA Practice Director

With BPM gaining so much attention, any workflow product worth its salt provides a lot of flexibility when it comes to definition and execution of processes specifically when it comes to human centric processes, both structured and unstructured. This flexibility however comes at a cost, cost both in terms complexity and clarity of definition of processes and performance in runtime. Also, making changes to workflows always remains a challenge. Simple changes like making steps execute in parallel instead of sequentially are a nightmare to implement and are most often simply not taken up.

It does not really need to be that complex if we take a somewhat hybrid approach to structured and unstructured processes. There are certain steps that have to happen in a particular order and then there are others that can be done at any time if certain pre-requisites are met. We have to start thinking of processes as steps where each step has a set of pre-requisites. These pre-requisites could be related to the steps in the workflow or can be content / context related. Instead of workflows, human centric processes can be defined as a set of steps with pre-requisites. For eg, a step X can be executed only when Step A and Step D are completed, when the status of a document is accepted and if the flow was initiated by a gold client.

This approach should be extended with user experience simulation to come up with the typical paths the workflow will take and this should be visually depicted. This will provide both clarity in terms of the definition and flexibility to change the workflows in an extremely simplified fashion.

Call it pre-requisites or workflow rules, the idea is to provide extreme dynamicity to human centric processes, an area that has not been addressed by most of the so called dynamic BPM products which cater almost always to system centric processes.

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.

Service Versioning in WSRR

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

We had heard the word “Change” used a lot in the recent months and I have to agree that “There is nothing more permanent than change”. In the services world, “Change” brings about a unique challenge – “Versioning”. As I enhance my service to add new functionality or update existing logic, I need to create a new version of the service. The reason - Most often, I need to support multiple versions of the same service in my environment as I might have different clients who would like to use different versions of the service.

WebSphere Services Registry and Repository (WSRR) is the place where I store all my service definitions. WSRR allows me to define a version number for a service, i.e. I could have multiple versions of the same service in WSRR.



However what is missing in WSRR is the ability to connect multiple versions of the service. However what WSRR does provide is the flexibility to add metadata to service definitions. I have created two such relationship attributes called – nextVersion and previousVersion and have used them to build a custom way to link multiple versions of a service.



Such a custom relationship allows me to do an impact analysis in my registry to see the following results:






Rajiv Ramachandran first joined Prolifics as a Consultant, and is currently the Practice Director for Enterprise Integration. He has 11 years experience in the IT field — 3 of those years at IBM working as a developer at its Object Technology Group and its Component Technology Competency Center in Bangalore. He was then an Architect implementing IBM WebSphere Solutions at Fireman’s Fund Insurance. Currently, he specializes in SOA and IBM’s SOA-related technologies and products. An author at the IBM developerWorks community, Rajiv has been a presenter at IMPACT and IBM's WebSphere Services Technical Conference.

Why Move to Portal 6.1?

Samuel Sharaf, Solution Director West Coast

We recently proposed a WebSphere Portal 6.1 upgrade to one of our very important customers. Their environment is currently running on Portal 6.0.x. The customer’s first question was, “What value does Portal 6.1 provides over version 6.0? And how it would benefit us?” To answer their question, we developed a simple table which lists the features available in the latest version of Portal and a brief description of these features.

These two columns, in table 1.0 below, can be used as basis for developing an ROI model for a customer who wants to upgrade to Portal 6.1. For example, most likely, a customer has developed custom AJAX functionality to enhance the user experience. Yet with any custom code, there is cost associated with code maintenance and enhancements. With Portal 6.1’s Web 2.0 support, most of the Portlets have built in AJAX support.The customer was happy to see how these new features in Portal 6.1 can help reduce the on going code maintenance and administrative costs and help improve the overall site and user experience.

WebSphere Portal 6.1 Features and Descriptions

UI Improvements

1. Themes and Skins Wizard
2. Themes and skins no longer part of wps.ear. Updates are applied without restarting Portal

Web 2.0

1. AJAX enabled Portlets
2. Supports JSR 268 which provides for improved inter-Portlet communication
3. Portal REST services and integration with Collaboration Services

Administering Portal/Web Content Management

1. Portlet Resource monitoring (out of box)
2. Simplified administration of sites
3. Greatly improved security configuration

Web Content Management Improvements

1. Security:
1. Inherited security support
2. User and contributor roles
3. Active content filtering
   
2. Performance:
1. Changes to WCM node structure for better authoring experience/performance
   
3. Presentation:
1. Improved UI tags for content rendering
   
4. Authoring/templating:
1. In line editing, Authoring tool enhancements, EditLive RTE 5
   
5. API:
1. JSR286 Portlets to enable Web content pages and directing links to right WCM Page

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

OpenID Vulnerabilities

Alex Ivkin, Senior IT Security Architect

OpenID is an identity sharing and a single sign on protocol, that is becoming more and more popular on the net. OpenID allows us to use a single authenticating source (aka an identity provider) to login into any site that accepts OpenIDs (aka a service provider) without the need to create an account on that site. Yahoo!, Google, AOL, SourceForge, Facebook and many others now support it now. A great idea, but unfortunately it comes with some big holes.

What OpenID means, in an essence, is that you are entrusting all your account accesses to a single source. You trust your identity provider to safeguard your personal information until you decide to use it. So, to no surprise, most of the attack vectors are targeting this trust relationship.

Spoofing an identity provider
If you use one of the common identity providers, say myopenid.com, you need to be aware of identity phishers. An attacker could devise a site, that, after asking you to login with an OpenID, sends you to a myopenid-look-a-like.com. You, trustingly, enter your OpenID login information, and, boom, your id and your password that opens access to all you OpenID accounts are in the wrong hands.

The switch user attack
If you are one of the paranoid types and host your own identity provider, say via a Wordpress OpenID plugin, you may succumb to a URL hijacking technique. If attackers gain an ability to modify pages on your site (PHP is great at that), they then could modify the headers on your pages to redirect openid validation requests to their own identity provider. With the redirect configured, when they log in into a service provider with your OpenID URL, the service provider will authenticate against attackers’ own identity provider, thus making them appear as you, anywhere they go. We’ve proven this scenario on our host, and it is very viable and very scary.

OpenID URL hijacking
Another set of attacks targets the OpenID URL. An Open ID URL is your unique identifier on the net to the service providers. If someone gains control over the URL, either due to DNS manipulation (google DNS attacks) or site hacking, they have a key to all your accounts. An example would be to trick a service provider into resolving your OpenID URL to an attacker’s site that uses attacker’s identity provider, thus making the service provider trust an attacker, posing under the URL of the victim. The use of i-Numbers in lieu of URL’s is supposed to help with this issue, but they are not yet widely supported.

Cross site request forgeries
OpenID does not validate all of the traffic going between the identity provider and service provider in a user browser via hidden i-frames. A malicious site could supply your browser could with a page that, knowing your openid from the cookies, could determine your identity provider name and automate actions to any number of service providers, acting on your behalf. The actions could range from creating accounts under your name to divulging details of your existing accounts on these sites. Secunia provided detailed research on this type of the XSS.

Automation attacks
OpenID sign on process makes it really easy for automated processes to login or create accounts on the fly. A spammer could create an identity provider validating its own id’s at a rate of hundreds a second and then supply them to the service providers. This could be mitigated by pairing an openid field with a captcha field, but it is not supported by most OpenID service providers right now.

Security holes
Yes, there are bugs, both in the specifications and the technical implementations. I would not go in to details here, since these are typically short lived and are addressed by the vendors in an on-going basis. The holes are exploited by the hackers and are expected for any new technology appearing on the web. The problem is that the stake with OpenID is a lot higher. Loosing an OpenID means not only losing your ID but also losing a multitude of accounts and associated personal information.

OpenID keeps your ID off your hands and on the net, the place that you have no control over. I am sure, current OpenID providers will work hard to make sure they are well protected to retain your trust, but rest assured, there will be breaches. Identity provides are very attractive targets to hackers, since they act as gateways to a wide array of accounts. And when this happens all your accounts are potentially lost, not just one. Thus, OpenID should be treated as a convenience, not a way to increase security of your accounts. From another perspective, assuming Linus’ law holds, I do not see OpenID going the Microsoft Passport way. OpenID has its advantage in being open and freely available.

Nonetheless, until OpenID is mature from the security prospective, like SSL and GPG, I am sticking with managing my accounts in an encrypted web browser’s password store. It’s almost as convenient and a lot better protected. After all, you keep your driver’s license in your own wallet, not posted on the web.

Alex Ivkin is a senior IT Security Architect with a focus in Identity and Access Management at Prolifics. Mr. Ivkin has worked with executive stakeholders in large and small organizations to help drive security initiatives. He has helped companies succeed in attaining regulatory compliance, improving business operations and securing enterprise infrastructure. Mr. Ivkin has achieved the highest levels of certification with several major Identity Management vendors and holds the CISSP designation. He is also a speaker at various conferences and an active member of several user communities.

Planning and Scheduling SOA/BPM Development - DO NOTS!

Jonathan Machules, Technology Director

As the momentum and understanding of BPM and SOA has increased, the projects have followed. IBM WebSphere Process Server and ESB (WPS/WESB) are common products that organizations start with when moving towards BPM/SOA/Web services. Many organizations are new to this type of SDLC. This discussion is in the context of my experience on WPS/WESB projects and certainly can be applied to other workflow and ESB products/technologies.

DO NOT:

• Delay Data Model and Data Design efforts
• Plan integration validation between systems/apps/services scheduled toward the end of the project
• Assume a Sr. Developer with no experience on WPS/WESB will design/develop a functioning application
  

DO NOT Delay Data Model and Data Design efforts. The reality here is that in development there are more than likely to be changes to the data model. Some will impact your Service Message Interfaces and create a domino effect on the Consumers of that data in design and development. Try to plan as much up front as possible and reduce the costs of changes the must happen later in the SDLC.

DO NOT plan integration validation between systems/apps/services toward the end of the development SDLC. On one recent project the customer was not familiar with WPS/WESB or integration projects in general. They planned all their integration testing toward the end of the SDLC in the Testing Phase. I am not saying integration testing shouldn’t be done in the testing phase but it should NOT be planned at the end of the SDLC. A common project plan will include a ‘Vertical Slice’, ‘Prototype’, ‘Wire-frame’ or whatever term you are familiar with, the has goal to validate the integration of the various systems early on in the SDLC.

DO NOT assume a Sr. Developer with no experience on WPS/WESB will design and develop a functioning platform. WPS/WESB are enterprise platforms that have multiple layers of technologies (e.g. Java, JEE, BPEL, WS, XML, XSLT, etc…). As a proud successful Sr Developer you may very well be able to create an application on these platforms that functions in non-production environment. However, there are number of nuisances that impact performance that should be addressed by design patterns depending on the requirements. Large business is one concern that comes to mind. Acceptable object size is dependent on business transaction volume, CPU Architecture, RAM, HEAP and other dependencies. Design patterns to deal with large business objects can be applied thus giving you better performance.

WPS/WESB is a product I’ve worked with extensively. It has seen major enhancements and improvements on usability/consumability but this doesn’t mean anyone can create a well functioning app.

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.