Client Showcase: Retailer Better Meets Customer Needs with Managed Services

Prolifics is committed to helping our clients create (and grow) competitive advantage in their industry. We are proud to have empowered this well known Retailer to do just that, again. After a successful e-commerce solution, Prolifics and our client teamed up again to bring ongoing managed services to further differentiate from the competition.

Our client is a high-end department store chain based in the United Kingdom. Business leaders previously began a strategic initiative to expand the Company’s e-commerce capabilities by expanding the product lines available online and improving connectivity with their distribution service to shorten delivery times in support of a higher volume of online purchases. Prolifics successfully led the implementation of a centralized Warehouse Management System (WMS) that would serve as the foundation for this project. The Prolifics team continued to provide support as needed to deliver the necessary IBM WebSphere MQ and IBM Integration Bus skills required to troubleshoot issues and make updates within the system. Over time, the Company found that their internal IT staff was spending approximately 60% of their time supporting the WMS production environment rather than deepening the capabilities of the solution. Finally, as ad hoc support service costs for the solution began to balloon during the holiday season, their busiest season for online purchases, business leaders began to explore better long-term support options with Prolifics. Valuing the deep technical expertise Prolifics has with IBM WebSphere MQ and IBM Integration Bus, our client engaged the Prolifics team to provide ongoing managed services in order to effectively maintain their WMS system while releasing internal staff to focus on other critical business issues. Prolifics recommended the implementation of SmartCloud APM and SmartCloud Control Desk to enable real-time alerts and provide a centralized ticketing system for submitting and addressing IT issues. Prolifics experts then led the implementation of these tools and developed reasonable service level agreements (SLAs) for the ongoing services that would meet the Company's needs. With managed services now in place, the Company is assured of timely, knowledgeable support for the more than 50 workflows in their WMS solution, with dedicated Prolifics staff available during regular call center hours to rapidly address issues and provide development support as needed. Further, with the new monitoring tools in place, staff can more proactively identify and address potential failures to ensure functionality and ultimately create a better user experience for online consumers.

To learn more about Prolifics Managed Services, visit: http://www.prolifics.com/managed-services

Implementing an Enterprise Services Layer - Reusable Lessons Learned

Technology implementations can be challenging. When the implementation involves several teams, multiple business units and requires a different approach than the one that is in place currently, the process can become even more demanding and at times daunting. However, if done right, the results can deliver significantly positive results for an organization.

In this article, we will be looking at the implementation process of an Enterprise Services Layer built on Service Oriented Architecture by the Prolifics Integration team and the important lessons learned during the course of the implementation. After all, reusable lessons go hand in hand with the process of developing and implementing reusable services.

This article is divided into three sections:

• Details of the solution and the major decisions taken during project lifecycle
• The lessons learned during the implementation process
• Project Success

Solution Details

The Business Challenge

Due to the lack of an enterprise wide integration layer, business units were unable to easily consume the services offered by other units and share business data. This prevented the organization from providing new and value added services to consumers resulting in lost market opportunities and revenue growth.

The Business Requirements

1. Develop a common service hosting layer that various business units can utilize to access enterprise services
2. Build a highly available, scalable and flexible solution that provides maximum throughput and 99.999% uptime
3. Implement an effective service governance framework
4. Implement a platform and services monitoring and reporting solution

Project Kick-Off Approach

The Prolifics team worked with leaders and representatives from customer IT departments and business units to understand the corporate culture in general and team culture in specific. The idea was to understand the way projects typically get done at the customer and customize our approach to developing and deploying the solution by understanding the current processes and practices. 

1. Team Education

One of the first tasks undertaken was to educate the stakeholders involved and bring about a common understanding of the project goals and solution. The goal was to make sure that we clearly communicate the scope of the solution; that is what the solution is meant for and what the solution is not meant for. 

2. Create SOA principles

This project being the first to build an enterprise-wide services layer based on SOA, we established a set of SOA principles in-order to keep the project implementation aligned with the project requirements and maximize the organization’s return on investment in this project.  

1. Consistent service definitions and implementation
2. Consistent and secure access to corporate processes and data
3. Standard-compliant enterprise governance
4. Consistent and well-defined data model
5. Cross-enterprise platform and services monitoring

3. Establish an SOA Center of Excellence

A successful implementation of a large scale SOA initiative requires bringing people from different business and technical areas together to support the implementation goals. The COE team was tasked with creating a solution blueprint to drive the overall implementation tasks and help the organization to adopt, formalize and improve the development process. 

The following were the main responsibilities of the COE team.

The Technology Foundation

To meet the service layer requirements, choosing the right technology foundation to host the solution is an important aspect; this is especially true since multiple components and systems need to integrate and function together seamlessly. It is important to consider not just the current requirements, but rather the long-terms requirements; the future growth, flexibility to add additional services, integrate with new and disparate systems, support additional throughput and at the same time maintaining the performance, scalability and availability. 

The solution comprised of the following products:

Key Factors in Choosing the Technology:

Deployment Topology:

The below diagram shows the solution deployment topology.

1. The service consumers connect to the global Load Balancer which based on the consumer region and load balancing algorithms, connect to one the of the available downstream load balancers
2. The service consumers can use a single endpoint that provides abstraction and high availability
3. The DataPower devices act as a secure gateway, provide additional internal load balancing and SOA policy enforcement point
4. IIB – A Highly available IBM Integration Bus architecture provides the service execution, message flow orchestration, advanced transformation and data enrichment platform
5. Fail-over infrastructure – Multi-node, inter-frame and cross site infrastructure provide advanced fail-over mechanisms 
6. WSRR – WebSphere Service Registry and Repository provides service life-cycle governance features and acts as the service policy definition point

Lessons Learned

Educate the Stakeholders

Ensure that the stakeholders understand SOA principles, project scope and project goals.  This step needs to done right at the start of the project; saves significant amount of time and money during the overall project roll-out and helps keep the project on schedule.

Security 

Plan for security right at the start of the project; this includes determining the protocols, encryption technologies, authentication and authorization processes etc. If the customer does not have an enterprise wide common security standards, it is possible that individual teams use different and at time incompatible security practices and processes that can lead to substantial challenges during the integration process. 

The Center of Excellence needs to provide sample code, documentation and implementation approaches to assist the different teams in pursuing a common security standard.

Make sure service consumers understand the implementation details

Ensure that the service consumers understand the details of connecting to the service layer and consuming the available services. Most often, service consumers face challenges when it comes to connectivity details, security implementation details etc. To make the process easier, have test beds made available for the consumers. Additionally, a functioning and well documented integration environment will further help in this process. 

Follow industry and internal standards

As part of the Center of Excellence enterprise architectural decisions, make sure that the stakeholders agree on the industry as well as internal standards that need to be followed. With limited resources and budget, common standards and practices will help in easier and simpler overall implementation process. This will additionally help in ensuring that the various teams can talk a common language and provide common support and maintenance services. 

Avoid Service Layer Complexity

The service layer complexity needs to be avoided. Additionally, only the necessary operations that directly enable integration connectivity and facilitate associated supporting activities should be deployed on the Service layer. It is important not to task the service layer with an application or service provider specific activity or functionality. The service layer needs to be lightweight, scalable and highly available. 

Iterative Deliverables

When an organization is just getting started with an SOA based service layer approach, identify the services that can be easily and readily hosted on the service layer. By taking a long term and iterative deliverables approach, the return of investment can be maximized and risks can be reduced. 

Performance Testing

Most often, it is difficult to understand the performance behavior of various applications and systems in an Enterprise Service solution. With services hosted by multiple business units and often running on different technologies, performance bottlenecks can be a recurring problem. 

In order to properly understand the performance behavior of the various systems and the overall solution, it is important to do performance testing early and often. Surprises such as a bad network route or a wrongly configured server can be avoided if performance testing is incorporated as part of the development life-cycle and performance engineering best practices are followed. 

Monitoring and Reporting

In a typical SOA based environment, tracking down performance and availability issues can be extremely challenging due to the loosely-coupled design. Additionally, with services hosted by multiple providers, keeping tracking of SLA and performance counters can prove to be even more difficult. 

In order to deal with these challenges, it is important to have an end-to-end monitoring solution. The solution should ideally monitor not just the operating infrastructure (performance, availability etc.) but also the business services (SLAs, service availability etc.). It is also important to have a solution that can provide useful and easy-to-understand reports that will assist in planning for capacity planning and performance analysis.  

Organizational Readiness

• IT departments and organizational units typically find that the process of introducing new initiatives that change the way projects are typically done is difficult. To ensure project success and maximize IT investment returns, strong leadership support for these initiatives is required. It is essential that the leadership team communicate the significance of the project and establish a strong project management team.

Importance of Service Governance 

• In order to provide consistent and standardized development, delivery and implementation of services and reduce risks, a strong governance model needs to be established as part of the project life-cycle. In a large scale implementation involving numerous teams, a strong service governance model that can handle the entire service life-cycle can ensure that the implementation process aligns perfectly with the business requirements and organizational goals.

Project Success

The Enterprise Server Layer currently handles over 6 million transactions per day. With a strong architectural foundation in place, the platform can seamlessly support additional throughput by horizontal or vertical scaling in a highly available environment. Additionally, the solution delivered end-to-end governance, monitoring and performance reporting. 

The solution proves that with proper architecture, design principles and team partnerships, organizations can achieve excellent return of investments and realize project success that can enable new market opportunities and business growth.


Authors:
The team of integration experts at Prolifics enable customers to maximize the return on their IT investments by providing end-to-end integration, governance and monitoring capabilities. To learn more about Prolifics' integration solutions, visit: http://www.prolifics.com/soa-universal-connectivity

Client Showcase: Insurer Wins with Centralized, Reliable and Secure ESB

At Prolifics, our commitment to client success is at the core of our business. Recently, we celebrated a successful solution "go-live" with one of our clients in New York. The solution highlights our team's expertise and technical skill across IBM software.

Our client is a large health insurer based in New York, servicing over 3 million people. Facing increasing challenges to maintain the disparate legacy technologies from the merged providers, the Company sought to integrate their systems under a centralized, reliable and secure enterprise service bus (ESB). Additionally, the Company wanted to move away from their traditional paper-based model by integrating a messaging framework into the new ESB that would enable faster, easier patient onboarding and care. They reached out to Prolifics to lead the project, wanting to leverage our strong ESB capabilities to build an optimal solution. Prolifics experts designed and installed an infrastructure architecture built on IBM Integration Bus (IIB), IBM Decision Server Rules and IBM DataPower to enable a robust ESB and integrated IBM Business Monitor and IBM Tivoli Composite Application Monitor (ITCAM) for Transactions to provide deeper monitoring and reporting capabilities, conducting testing throughout the effort to ensure optimal performance. The Prolifics team also developed a common rules framework to connect the disparate customer enrollment programs to various other internal systems. With the new ESB and rules engine in place, the Company can ensure consistent, secure sharing of customer enrollment information across the enterprise, improving efficiency and ultimately quality of care.

To learn more about Prolifics' integration solutions, visit: http://www.prolifics.com/soa-universal-connectivity

Prolifics Employee Showcase: Alan Shemelya, VP of Healthcare Business Development

Alan Shemelya is the Vice President of Healthcare Business Development and is responsible for growing Prolifics’ healthcare services and solutions for customers around the world. With more than 30 years of experience and thought leadership in the Healthcare industry, Alan has accomplished an impressive list of milestones over the course of his career and is passionate about not only helping businesses achieve success but also making significant strides in patient care.

Commitment to Healthcare
Alan’s passion for the healthcare industry began as a young child after a trip to the hospital. His interest grew in college when he wrote a thesis on healthcare finance. During this project, he realized that hospitals were manually driven in just about everything they did on a daily basis and were operating 10 years behind. From registration to billing, automated processes simply did not exist.

It was at this time that Alan recognized an opportunity in the industry. Throughout his career, his work has always been driven by a consistent mission: finding ways to improve the care of sick children.

The Road to Prolifics
Alan joined the Prolifics team in March 2014. Over his career, he has worked with a number of leading healthcare information technology (HIT) and consulting companies in Sales, Product Development, Marketing and Implementation of EMR, Revenue Cycle and ERP solutions. Prior to joining Prolifics, Alan provided his leadership and expertise at HCA/Parallon, Xerox/ACS, Allscripts and McKesson.

Alan is driven by his motivation to provide innovative IT solutions for the provider and payer markets, specializing in improving patient, provider and payer communications, business process enablement, and outcomes. With Alan’s expertise in the healthcare industry, experts will have the experience, skills and knowledge necessary to deliver in this highly complex industry, aligning innovative and proven solutions to solve clients’ business goals.

Innovation & Thought Leadership
Alan has written articles on the redesign of business processes and advancement in technologies that enable the automation of workflow decisions impacting both providers and payers. He has been a featured speaker with the Southern Healthcare Administrative Regional Process (SHARP) and has been on the National Speakers List for the Healthcare Financial Management Association (HFMA). Below is a list of articles that Alan has published throughout his career.

HFMA ANI, 2009
HFMA Georgia Meeting, 2010
HFMA Patient Friendly Billing – Accessibility of Data

The Future is Bright
When asked, Alan selected the following three words to describe Prolifics: agility, intelligence, responsibility. He finds these characteristics as key drivers for success in building innovative healthcare IT solutions.

A Recent Journey
Alan recently participated in the AIDS/LifeCycle 2014 bike ride. This is a fully supported, 7-day bike ride from San Francisco to Los Angeles designed to raise money and awareness in the fight against HIV/AIDS. This event delivers a life-changing experience for thousands of participants from all backgrounds and fitness levels united by a common desire to do something heroic. Prolifics proudly supports Alan and this worthwhile cause!

Alan Shemelya is the Vice President of Healthcare Business Development at Prolifics. He is responsible for growing Prolifics' healthcare services and solutions for customers around the world. Alan has 30 years of experience and thought leadership in the Healthcare industry, specializing in Sales, Product Development, Marketing and Implementation of EMR, Revenue Cycle and ERP solutions. As an industry expert in the healthcare financial arena, Alan has written articles on the redesign of business processes and advancement in technologies that enable the automation of workflow decisions impacting both providers and payers. He has been a featured speaker with the Southern Healthcare Administrative Regional Process (SHARP) and has been on the National Speakers List for the Healthcare Financial Management Association (HFMA).

IBM Impact Session Preview: Enabling a Digital Strategy that Fits the Healthcare System around the Consumer Using BPM SOA

Aetna is making connected health care systems a reality and empowering consumers to live a healthier life. The key to the strategy is enabling new mobile technologies and partner integration. To enable this transformation, Aetna is implementing a Business Process Management (BPM) Service Oriented Architecture (SOA) Center of Excellence (COE) that will enable their business to rapidly orchestrate and integrate their systems & services in order to seamlessly provide users with data & IT resources with faster integration, lesser cost and higher return.

We will showcase the BPM COE approach and the components being used to build it out. Aetna’s Enterprise Architecture will ensure separation of business rules from data integrity rules and provide enterprise level decision services. This BPM architecture will also enable to integrate with Aetna’s DataPower, Enterprise Bus and mainframe systems to communicate with the Data Access Services layer. The solution involves using IBM tools like ITCAM for monitoring, Service Registry and eXtreme Scale for caching needs.

At IBM Impact, we will be hosting a subject on this topic. In this session, we will focus on how to enable a digital strategy that best fits the Healthcare system around the consumer using BPM and SOA.

Session Abstract: 
Aetna is making connected health care systems a reality and empowering consumers to live a healthier life. Key to the strategy is enabling new mobile technologies and partner integration. To enable this transformation, Aetna is implementing a BPM SOA center of excellence (COE) that will enable their business to rapidly orchestrate and integrate their systems & services in order to seamlessly provide users with data & IT resources with faster integration, lesser cost and higher return. We will showcase the BPM COE approach and the components being used to build it out. Aetna’s Enterprise Architecture will ensure separation of business rules from data integrity rules and provide enterprise level decision services. This BPM architecture will also enable to integrate with Aetna’s DataPower, Enterprise Bus and mainframe systems to communicate with the Data Access Services layer. The solution involves using IBM tools like ITCAM for monitoring, Service Registry and eXtreme Scale for caching needs.

Session Number: ICU-2748
Date/Time: Wednesday, April 30, 2014; 5:00 PM – 6:00 PM PDT
Location: Venetian-Marcello 4401 A

Add this session to your calendar!

To see a full list of Prolifics sessions, visit www.prolifics.com/impact-2014.htm.

IBM Impact Session Preview: How PSCU implemented their Intelligence Platform through a SOA COE

Hear how PSCU implemented a Service Oriented Architecture (SOA) Center of Excellence (COE) - a linchpin solution that Prolifics has delivered to several customers. The COE ensures viability of PSCU business goals, especially as they relate to credit union connectivity and delivery of PSCU enhanced services such as credit/debit, banking, billpay, and PSCU mobility efforts through 2015.

PSCU worked with Prolifics and IBM to help deliver a seamless integration and runtime SOA governance aspects of PSCU's next-generation "intelligent platform" - a high-performance integration web service and connectivity platform with state-of-the-art integration, interoperability, security, and enterprise SOA governance capabilities. PSCU utilized IBM Integration Bus, IBM WebSphere DataPower Appliances, and IBM WebSphere Service Registry and Repository as part of this effort.

At IBM Impact, Prithvi Srinivasan will be hosting a subject on this topic with Prolifics' client PSCU. In this session, we will focus on how PSCU implemented their intelligence Platform with a Service Oriented Architecture Center of Excellence.

Session Abstract: 
Hear how PSCU implemented a Service Oriented Architecture (SOA) Center of Excellence (COE) - a linchpin solution that Prolifics has delivered to several customers. The COE ensures viability of PSCU business goals, especially as they relate to credit union connectivity and delivery of PSCU enhanced services such as credit/debit, banking, billpay, and PSCU mobility efforts through 2015. PSCU worked with Prolifics and IBM to help deliver a seamless integration and runtime SOA governance aspects of PSCU's next-generation "intelligent platform" - a high-performance integration web service and connectivity platform with state-of-the-art integration, interoperability, security, and enterprise SOA governance capabilities. PSCU utilized IBM Integration Bus, IBM WebSphere DataPower Appliances, and IBM WebSphere Service Registry and Repository as part of this effort.

Session Number: ICU-3358
Date/Time: Tuesday, April 29, 2014; 2:15 PM – 3:15 PM PDT
Location: Venetian-Marcello 4402

Add this session to your calendar!

To see a full list of Prolifics sessions, visit www.prolifics.com/impact-2014.htm.

IBM Impact Session Preview: Extending IBM WebSphere Service Registry and Repository to Legacy IBM WebSphere Application Server

Almost all organizations today have embraced the concept of SOA and have aligned it to the path of application agility. One such bottleneck comes in the form of legacy applications where the endpoint of the service provider is stored either in a constant or in a property file. This restricts the ability to change both at the service provider and consumer ends.

Applications integrated with IBM WebSphere Service Registry and Repository (WSRR) have the ability to select the endpoints based on policy. Not only are they immune to constructive changes at the service provider but this also eases the overall governance process.

At IBM Impact, I will be hosting a subject on this topic. In this session, we will focus on the integration of Legacy Java applications with WSRR using APIs.

Session Abstract:

Almost all organizations today have embraced the concept of SOA and is aligned to the path of application agility. Bottlenecks can come in the form of legacy applications where the endpoint of the service provider is stored either in a constant or in a property file. This restricts the ability to change both at the service provider and consumer end. Applications integrated with WSRR have the ability to select the endpoints based on policy. Not only are they immune to constructive changes at the service provider, but this also eases the overall governance process. In this session, we will focus on: pattern to integrate WSRR with legacy java applications based on Spring framework, different scenarios in which it should be use, deep dive into the development and maintenance aspect, and extending this pattern to make it framework independent.

Session Number: INO-2740

Date/Time: Wednesday, April 30th; 2:15pm - 3:15pm

Location: Venetian-Marcello 4405

Add this session to your calendar!

To see a full list of Prolifics sessions, visit www.prolifics.com/impact-2014.htm

Animesh Jain is a solution architect at Prolifics with over 10 years of experience in application development and maintenance. He has worked on projects of varying complexity and magnitude and has performed in various capacities as Technical Architect, SOA Lead and Senior Developer. Specializing in integration, Animesh takes deep interest in understanding the business issues which helps him to guide and suggest the best approach to our clients. He also has been involved in numerous pre-sales projects and enablement activities. He has mentored several resources and has created enablement documents on Web-Services, SOA, BPM and WESB.

Thinking Out-of-the-Box: A Unique Implementation of BPM Batch Process

One of consultants’ biggest challenges is to fulfill our clients’ requirements entirely. Some requirements are straight forward and easy to implement, while others are quite complex and force us to think out-of-the-box. It is those complex requirements which bring our “best” by making us venture into unknown, ultimately resulting in innovative solutions.

One of my recent client engagements posed a quite interesting requirement. Below is a full description on how I solved it with advice from other team members.

Client Requirement:
In a recent BPM project, we had a requirement to implement Batch Process such that it runs every day at a certain time. But another requirement along with that was, the time to run the batch process should be changeable. For example, a batch processes is set to run at 12.00 am every day as per the present requirement; however, after 3 months we might need to run them at 3.00 am everyday instead of 12.00 am.

For this project, we were using IBM Business Process Manager V8.0.1 Advanced.

Challenges in Designing Solution:

1. One of the obvious solutions I thought of was to use Time-Elapsed UCA assuming it will allow us to change the trigger time at the run-time. However, there is no way to change the trigger time of the Time Elapsed UCA at the runtime. It needs to be changed using Process Designer and deployment needs to happen across all the environments before finally promoting the change to Production environment.
2. Another option was to use WAS Scheduler to run the Batch jobs. However, it needed some learning curve to develop a solution and would have hampered the timeline. Another challenge was that the client wanted to use the IBM BPM (Process Designer) capabilities to develop a solution which will be easily supported by the client.

Solution Description:
Here is the high-level design for implementing above requirement for the Batch Process.

• A batch process will run systematically once every day at a specific time. 
• Use Singleton design pattern such that at any point of time one and only one batch process instance will be running in BPM which will set off every day at a certain time.
• At any point, if the time for the batch process needs to be changed, we should be able to do it by doing following step:
• Check if there is an existing instance of the BPM Batch Process and terminate/delete it.
• Create a new instance with new time to run the batch processes.
• On a specified time, this process instance will invoke multiple batch process use-cases. For example Batch Process UseCase 1 and Batch Process UseCase 2 and so on as in the High Level Diagram below.

Advantages:

1. It is a generic solution which can be implemented once and then batch process use-cases can be added at any time.
2. It is not performance heavy. Even though there is always an instance in the background, it will consume resources only when it is executing at the batch process time and will release them while it is in wait state.
3. It uses Process Designer capabilities with no java components, schedulers and properties files.
4. It avoids any complications of running multiple schedulers at different server locations and on multiple nodes.

Disadvantages:

1. A new instance needs to be created by the Admin when a change in time is proposed either by running scripts, using Human Service URL or Process Portal.

Implementation Details using Process Designer

“BPM Batch Process” Business Process Diagram: 

Here is the implementation of the “BPM Batch Process” BPD which is exposed to be accessed by Admins. This BPD helps get the time for the batch job execution using SetBatchProcessTime Human Service and then every day it invokes multiple batch process use-cases at that time.

This implementation is based on Singleton design pattern i.e.at any given time only one Process Instance of this BPD should be active in BPM. If we want to change the time of batch job, then we need to call SetBatchProcessTime human service which will terminate the old instance and then create a new one with new time.

“SetBatchProcessTime” Human Service:

“SetBatchProcessTime” human service is used to set the batch process time such that it will run every day at the same time. This human service will be started with “batchDateTime” as the input. This will help to change the batch process time whenever required.

Since there can be only one instance of BPM Batch Process running at any point when a new time is being set for batch process, it will make sure there are no instances running beforehand. If there are then it will terminate it before creating a new instance for BPM Batch Process with new time. 

Here is the implementation of the Human Service “SetBatchProcessTime”

Batch Process Use Cases:

Batch Process Use Cases can be different implementations in order to achieve any business relevant goals like changing a status of certain business cases, terminating business process instances, sending emails, and so on to name a few. These use cases can be any type of implementation, like a BPD, a General System Service, an Integration Service or any other Process Designer specific artifacts.

Invoking Batch Process

There are multiple ways to invoke this Batch Process via SetBatchProcessTime Human Service. 

The SetBatchProcessTime Human Service will accept the trigger time for the batch process to be triggered every day. This Human Service will in turn instantiate BPM Batch Process BPD.

This Human Service can be invoked in number of ways as listed below.

1. Using SetBatchProcessTime Human Service URL

SetBatchProcessTime can be invoked by the administrators who are part of “Admins” group using the URL as mentioned below:

http://{hostname}:{portnumber}/teamworks/executeServiceByName?processApp=SPA&serviceName=SetBatchProcessTime

where:

SPA = Process App Acronym

SetBatchProcessTime = Name of Human Service

2. Using SetBatchProcessTime REST URL

The REST URL which can be used for invoking SetBatchProcessTime Human Service using POST method call is:

http://{hostname}:{portnumber}/rest/bpm/wle/v1/service/SPA@SetBatchProcessTime?action=start&params=%7B%22batchDateTime%22:%222014-02-27T00:00:00Z%22%7D&createTask=false&parts=all

where:

SPA = Process App Acronym

SetBatchProcessTime = Name of Human Service

batchDateTime = Batch Process Time parameter (%22 stands for quotes “”)

3. Using Process Portal

SetBatchProcessTime Human Service can be invoked using Process Portal by exposing it as Startable Service.

Process Portal:

For this particular solution, I exposed it as REST URL to be invoked using REST API in the deployment scripts to automate creation of the process instance instead of doing it manually.

Conclusion:

Yes, I was able to successfully achieve the client requirement by designing and implementing a solution but the significance of this experience is how thinking out-of-the-box helped me come up with an entire analysis while designing and implementing a solution. Not only was the Singleton design pattern used to design this solution but also it was generic along with flexibility to change the batch process trigger time in the future; there by sticking to the guidelines around good practices which is equally important in a solution.

Acknowledgements:

I would like to thank the following individuals:

• Soundarajan Mannathan for his advice. 
• Salem Hadim for his advice and approvals. 
• Eva Khalil for her valuable inputs on this blog piece.

Want to learn more about Prolifics?

• Visit www.prolifics.com
• Learn about our presence at IBM Impact
• Connect with Jimit:
• Twitter
• LinkedIn
• Email

Jimit Sukkawala is a Consultant in BPM and Connectivity LoB in Prolifics specializing in Service Oriented Architecture, System Integration & Business Process Management. He has been with Prolifics for past 5 years and worked across different industry domains like Financial Services and Leisure & Hospitality. He has worked on projects through different phases of software development cycle and most of them making to Production. His main expertise is in WebSphere Process Server, WebSphere ESB and IBM BPM. He holds a master’s degree in Management Information System from University at Buffalo and bachelor’s degree in Information Technology from University of Mumbai.

Migrating IBM WebSphere Message Broker v6.1, 7, 8 to IBM Integration Bus v9 on Distributed Platforms - Checklist for a Successful Migration

IBM’s endeavor to offer one integration product capable of supporting .NET, Java, and various heterogeneous integration scenarios resulted in the launch of IBM Integration Bus (IIB). IIB v9 offers a standardized and flexible integration backbone. It allows placement of WebSphere Enterprise Service Bus (WESB), Rules Engine, and WebSphere Message Broker (WMB) under one software umbrella. One can expect significant benefits including enhanced support for .NET, improved Global Cache, a new Real-Time Performance Monitoring Tool and many other new features and upgrades such us Policy based WLM and BPM integration.

The below checklist is a compilation of IBM Integration Bus Information Center v9 instructions and offers a guideline to a successful migration of WMB v6.1, 7, 8 Broker Component to IIB v9 on distributed platforms. The checklist is comprised of the following topics: Migration of Broker Components and Migration of Development Artifacts.

Migration of Broker Components

The earliest version of WMB that one can migrate resources from is WMB v6.1. In a case where a migration from earlier versions is required, one must migrate to WMB v6.1, 7 or 8 first, however earlier version migrations are not in the scope of this document.

Migration from Windows x86 product to x86-64 product is not supported as well as migration of Linux x86 product to Linux x86-64.

In addition there are restrictions on migrations of earlier versions to IIBv9 Developer Edition. Supported operating modes are Full Edition, Remote Adapter Deployment, Express Edition and Standard Edition.

Finally, IIB v9.0 requires a minimum WebSphere MQ (WMQ) v7.5.0.1 on distributed platform. If publish/subscribe functionality is utilized by WMB v 6.1, a migration of WMQ Queue Manager is required first, followed by migration of subscriptions and then Broker component.

Remember: back up all of your resources prior to migration!

Migrating WMB v6.1, WMB v7.0, and WMB v8.0 Broker Component

• Back up all resources: configuration repository (WMBv.6.1), Broker database(WMBv6.1),  and development artifacts.
• If using ODBC connections, back up ODBC connection files.
• If using configurable services, back up configurable services properties.
• Install WMQ v7.5.0.1 and up.

In Place Broker Component Migration

Install at least Integration Bus component under new location on the same machine

Remove WMB v.6.1,7.0, 8.0 Broker from the domain configuration

Stop all channels connected to WMB v6.1,7.0,8.0 Broker

Stop WMB v6.1, 7.0, 8.0 Broker

Migrate WMB v6.1 Broker‘s Queue Manager to appropriate IIB v9 WMQ version

Migrate Pub\Sub components if required

Update ODBC connection filesto IIB v9.0 format if required

Set up IIB v9.0 command environment

Run the mqsimigratecomponents command to migrate WMB v6.1, 7.0, and 8.0 Broker (mqsimigratecomponents command migrates configuration data in forward and backward fashion (use “t” option for rollback): broker databases, queues and broker registry are migrated)

Copy environment settings if required

Start IIB Broker

Deploy migrated artifacts

Parallel Broker Component Migration:

Install at least Integration Bus component under new location on the same machine or on another machine

Update ODBC connection files to IIB v9.0 format if required

Set up IIB v9.0 command environment

Create IIBv9.0 Queue Manager on appropriate WMQ version

Create IIBv9.0 Broker

Copy environment settings if required

Start IIB Broker

Create Integration Servers (Recreate WMBv6.1, 7.0, 8.0 Execution Groups)

Deploy migrated artifacts

Migration of Development Artifacts

Development artifacts from all previous versions cannot be shared with IIB v9.0. 

Artifacts developed on IIB v9.0 cannot be deployed to earlier versions.

User Defined Node Jars developed in earlier versions  cannot be migrated to IIB v9.0.

User defined nodes require an extra diligence during migration. 

Resources which are imported into IIB v.9.0 cannot be used in earlier versions of the product.

Message flow projects are replaced with integration projects.

Message sets are “Read-only” once imported and not modifiable. (Modify message sets by

enabling msgset development in IBM Integration Toolkit -> Preferences)

WMB v6.1 and v.70 msgmap can be viewed, compiled and deployed but they are “Read- only” In order to modify .(msgmap) convert (.msgmap) to .map file

 Migrating WMB v6.1, WMB v7.0, and WMB v8.0 Development Artifacts

• Development resources can be imported into IIB v.9.0 as PI files.
• Workspaces can be migrated into IIB v9.0.
• Migrate Development Artifacts

PI Import:

Export development artifacts from a previous WMB version into a PI file

Import PI file into an IIB v.9.0 workspace

Convert integration projects into applications or libraries if required

Workspace migration:

Point IIB v.9.0 IBM Integration Toolkit to location of an existing workspace

Click OK

In case of errors during migration apply “Quick Fix” by right clicking task list warning or error in the Problems view, then click Quick Fix.

Resources:

*Figure 1, 2: Migrating to IBM® Integration Bus v90

http://www-01.ibm.com/support/docview.wss?uid=swg27038933&aid=1

*All Content: IBM Integration Bus Information Center

http://pic.dhe.ibm.com/infocenter/wmbhelp/v9r0m0/index.jsp

Eva Khalil is a middleware solutions designer with more than 12 years of experience in systems and applications integration area.   She has been working with Prolifics for the past five years.   Eva has successfully led many integration projects for various business industries: financial, government, healthcare, insurance and utilities. She is especially fond of WMQ and IIB.

IBM Business Process Manager Integrations: Designing SCA Based MQ Integration for BPM

Problem Statement:
For integrating IBM WebSphere MQ with IBM Business Process Manager (BPM) applications, solutions can be built using SCA components bundled into main business process applications to consume messages from external messaging systems when BPM Advanced edition is used. If the business requirement is to have multiple active snapshots then IBM BPM deploys separate SCA Modules for each snapshot. Though the solution works, it is not an elegant solution because as the number of snapshots increases, the number of listeners (SCA Modules) on MQ will continue to increase.

Solution:
The solution is to separate SCA modules from main business process application by creating a lightweight standalone process application with SCA components which in turn routes the incoming message to the main business process which is expecting the message from the external system. Use the MQ export component to listen on MQ and trigger short process using one-way interface, the short process will have all system activities to digest incoming message and route it to appropriate messaging event (ME) of main business process using UCA components.

Assumptions
To explain the design, assuming the following:

• Input messages are XML messages over MQ and IBM BPM Advanced 8.0 environment. 
• External Message is expected after business process has been started, i.e. external message event is not used to trigger the business process instead used within the process.

Process Designer Components

• Create Process App “MQ Integration” with BPD called “Process MQ Message” which needs to be triggered when the MQ message arrived in queue using SCA component in IID. This process should have all required logic to send the message to appropriate main process with correlation information.

• The BPD should have appropriate input variables based on payload.
• The BPD should also have service to send the message (payload) to main process using UCA. Use correlation id such as Instance Id to send the payload to correct process which is expecting the payload.

• Create a toolkit for UCA to send the message from “Process MQ Message” to actual (main) BPD and include this UCA tool kit in both main process app and Integration process app.
• Another option is to drop the message with UCA format into SIB (event queue) which would automatically triggers waiting IME based on correction id. In both approaches, payload should have correlation id or any other data which can be used to derive actual correlation information.

Integration Designer Components

• Create MQ Export one-way invocation style to start BPD “Process MQ Message”.

• Configure MQ Export to listen on MQ queue using appropriate connection details.
• Configure data handler based on payload, OOB data handler UTF8XMLDataHandler is used in this case as payload is XML.

When the message arrives in the MQ queue, SCA component will trigger BPD “Process MQ Message” in “MQ Integration” application with payload as input. The BPD in turn sends the message to actual process using UCA with correlation information available in payload.

When multiple main process snapshots are active on process server, there will be only one SCA module from Integration application “MQ Integration” listening on MQ Queue and routing the messages to all active snapshots of main process.

Advantages

• As the SCA components are not bundled with main business process app, only one instance of SCA component (one listener) will be deployed on process server
• Easy to maintain as it is not tightly coupled with main business process application.

Disadvantages

• It needs to be deployed separately.

Conclusion

Decoupling SCA Modules from business process application will allow changes to integration logic and routes the messages to appropriate process without impacting main business process application much when production environment expect to have multiple active snapshots.

Shanmugam Golla is Solution Architect proficient in developing web-based enterprise applications using JEE, BPM, and SOA technologies. Possesses over 11 years of experience in all phases of software development, with exposure to all aspects of project life cycles, from inception to production support. Shanmugam has lead teams for top-tier consulting firms providing multifarious and complex IT business solutions to prestigious firms in banking, finance, securities, and insurance brokerage.

Is Your Integration Project Costing More Than It Should?

Over the years I’ve been directly involved in a great number of IT software development projects at Prolifics. And without exception these have all involved integration of a number of software components – whether it is integrating back-end systems such as SAP, plugging in external services from business partners, or the more relatively straightforward integration of new business systems or processes to in-house business services.

And something I’ve seen all of these projects having to deal with is the fact that software integration introduces some very real dependencies in development and test plans and environments – all of which require a fair amount of attention and a non-trivial amount of coordination and resources which could impact the time and budget estimates.

But what if there was a way to reduce the cost and planning impact of these dependencies?

Monica Luke and I tackle this topic in a new IBM whitepaper that discusses the usage of business service virtualization and testing techniques and tools to remove bottlenecks and reduce costs in building today’s modern, interconnected applications.

Many of our IBM customers will be interested in the discussion on example service architecture as well as mobile and portal domains. We briefly contextualize the value for customers using products such as WebSphere Application Server, WebSphere Enterprise Service Bus, IBM Integration Bus (previously WebSphere Message Broker) and MQ, WebSphere DataPower, IBM Business Process Manager, WebSphere Portal Server and IBM Worklight.

Read our whitepaper here:

Use Service Virtualization to Remove Testing Bottlenecks






How do I get started?
This is a great time to highlight Prolifics' very own IV&V (Independent Verification and Validation) practice. IV&V is an important aspect of our global delivery model, providing customers with end-to-end testing solutions that help to improve productivity and quality while reducing overall cost of all software development activities.

Our team has extensive experience in testing large, interconnected, critical business applications, and is ready to help you reinvent the way you approach your testing – backed by a service framework and testing accelerators that have been field tested and refined for over a decade.

Interested in taking a deeper dive? Connect with me!
Twitter - @greg_hodgkinson
Email - ghodgkinson@prolifics.com
LinkedIn - Greg Hodgkinson

To learn more about Prolifics, visit www.prolifics.com.

Gregory Hodgkinson is the Lifecycle Tools and Methodology Practice Director at Prolifics and an IBM Champion for Rational. Previous to that he was a Founder, Director, and the SOA Lead at 7irene, a visionary software solutions company in the United Kingdom. He has 16 years of experience in software architecture , initially specializing in the field of component-based development (CBD), then moving seamlessly into service-oriented architecture (SOA). His extended area of expertise is the Software Development Lifecycle (SDLC), and he assists Prolifics and IBM customers in adopting agile development processes and SOA methods. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods at both IBM (Rational and WebSphere) and other events, has also co-authored a Redbook on SOA solutions, and contributes to DeveloperWorks.

Integrating with Salesforce.com

Salesforce.com (aka Salesforce) is the most commonly used cloud-based Software as a Service platform for Customer Relationship Management (CRM). Recently, we have been involved with a lot of customers who are planning to start migrating to or have made a strategic decision to use Salesforce to manage their customer contacts, track sales orders, streamline their sales processes, etc. In fact, Prolifics itself is a Salesforce customer.

Our own experiences, and those with our customers who use Salesforce, have given us an in-depth understanding of what it takes to ensure that this CRM solution is made universally available within the enterprise – to business processes that require customer information or to portal applications that mash up customer information with data from other systems. This blog entry details three patterns that we have commonly used when integrating with Salesforce and that we believe can be reused – entirely at the design level and to a good extent at the implementation level.

1. Enterprise CRM Services – Every enterprise has defined standards when it comes to their enterprise services and data formats. The reusable enterprise services are exposed via the ESB and all the end applications use these enterprise services to communicate with end systems so that the ESB can provide the common functionality and the governance needed when performing system integration. Using this same concept when working with Salesforce allows enterprises to centralize the Salesforce integration at the ESB layer (the ESB communicates with Salesforce using SOAP/HTTP web services), do transformation, security, etc. at one common place and provide clients – processes, portals or mashups, etc. – with the consistent enterprise-wide data representation to which they are accustomed. The enterprise services provide the generic CRM interface to the clients, so that if the CRM system has to be changed, the hundreds of clients that use the CRM system in the enterprise do not have to change. The IBM WebSphere Enterprise Service Bus is commonly used for implementing this pattern.

2. Publish CRM Data – Another common requirement is to ensure that CRM data is passed from Salesforce to back end systems based upon changes that happen within Salesforce to this information. The ESB provides a service (SOAP/HTTP web service) that gets invoked by Salesforce (with all the relevant information from Salesforce) when data of interest changes in Salesforce. This data is then transformed and passed to the back end systems. The benefits of this approach include a centralized service definition on the ESB, transformation of data, centralized security management, supporting legacy applications that are not web service enabled [but still need CRM data], etc. The IBM WebSphere Enterprise Service Bus or IBM WebSphere Message Broker is commonly used for implementing this pattern. [Note: the reverse flow from end systems to Salesforce is handled similarly, instead of being invoked by Salesforce; the ESB invokes a service on Salesforce.]

3. Bulk Load of CRM data – It is very typical for customers to need the ability to bulk load customer data from their existing homegrown systems into Salesforce. These kinds of requirements are also common when mergers and acquisitions happen and new customer data needs to be loaded. During the bulk load of CRM data, there may also be a need to cleanse the information before loading it into Salesforce. The IBM InfoSphere DataStage, IBM InfoSphere QualityStage, and the IBM InfoSphere Information Server Pack for Salesforce.com together support this pattern that involves the definition of ETL jobs that extract data from different sources, cleanse, map the data to Salesforce format, and load it into Salesforce.

I want to conclude by saying that we at Prolifics believe in “eating our own dog food.” Prolifics has a production implementation of IBM WebSphere Enterprise Service Bus that was built using the pattern described above (Publish CRM Data) that enables the data we have in our Salesforce instance to be published to IBM’s Global Partner Portal based on Siebel.

In my next set of blog entries, I will focus on couple of related topics:

• IBM’s acquisition of Cast Iron Systems and how the solution supports these patterns of integrating with Salesforce


• A set of assets that we are currently working on at Prolifics to help customers jump start their own Salesforce integration initiatives.

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.

Building an Enterprise Application Integration Solution

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

Having an integration infrastructure that connects all enterprise systems to one another and provides seamless and secure access to customers, partners, and employees is the foundation of a successful enterprise. I have been involved with a lot of customers discussing their EAI architectures. More often than not, I have noticed that the approaches considered to implement such an architecture are not complete and do not provide the benefits that may be achieved with a well connected enterprise. In this blog entry, I would like to highlight aspects that need to be considered to build an end-to-end integration solution. (Note: This blog entry will not get into the details on how to implement each of these areas, which would result in me writing a book J.)

1. Connectivity – Avoiding point-to-point connectivity and ensuring that you have loosely coupled systems is key to ensuring that your EAI architecture is flexible and can scale.Use an ESB as the heart of you EAI architecture and ensure that your ESB has support for all major protocols (HTTP, SOAP, JMS, JCA, JDBC, FTP, etc.) and comes with adapters for common enterprise applications like SAP, Oracle, Siebel, PeopleSoft, etc.
   
   
2. Patterns - Build a pattern based integration solution. The following is an excellent paper that outlines some of the common patterns used in the integration space:http://www.ibm.com/developerworks/library/ws-enterpriseconnectivitypatterns/index.html
   
   
3. Data - Data is of great significance when it comes to integration. Different systems have different data formats and there are common items to consider that can help you deal with these differences:




• Define canonical data formats and ensure that you have mapping from application specific formats to canonical formats. Understand the various data formats that exist in your enterprise today and evaluate what it will take to map and manage complex data formats.


• EDI data is common in many enterprises and will require special handling.


• Define a strategy for handling reference data, how lookups can be done against this data and how reference data can be maintained.


• Define rules around both syntactic and semantic validation of messages. Do not over do validation as you will pay a price when it comes to performance. Be judicious in what you want to validate and where.




4. Monitoring - An aspect that is often overlooked when building integration solutions is monitoring. Ensure that you have the right framework(s) in place to monitor your integrations and service components. You will need the ability to monitor every protocol the ESB supports. You also need to couple monitoring with notifications and error handling. You will need a strategy for auditing your messages. Again, as in the case with validations, be judicious in what you want to audit and when. There is a price to pay. Define a centralized service for auditing requirements and ensure that all integration components make use of this service.
   


5. Security - Security is the most critical part of implementing an integration solution. I have to say that most customers realize that security is important but sometimes, because of a lack of expertise in how to correctly secure their solution, the end result is a solution that is way more costly and in fact less secure than desired. Some considerations are:




• Define your security requirements – authentication, authorization, encryption, non-repudiation, etc.


• Decide what aspect(s) can be supported by transport level security and when you need message level security.


• Decide where hardware components can be used to better implement security than software components.


• Use open standard protocols so that you can easily integrate with different systems – both internal and external.





6. Service Oriented Integration – With the adoption of SOA, one of the key architectural models used for integration is to connect to service interfaces that are exposed by various systems. With this architecture, it is also now possible to choose what service / functionality you use dynamically at runtime. Another aspect that SOA has brought to the integration world is a policy-driven approach to integration – that is, data that is being passed to a system or between systems is used to check what policy needs to be applied at runtime to determine what service to use and what actions to perform (auditing, validation, encryption etc.). Integration coupled with SOA introduces another component into the EAI architecture – a registry and repository where services and policies are cataloged and can be used to bring about dynamic, policy-driven behavior.

This confluence of pattern based connectivity, data handling, monitoring, security, and service-oriented integration can provide you with a well-connected enterprise that can respond quickly to changing business needs.

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.

Integrating WSRR (WebSphere Registry and Repository) and RAM (Rational Asset Manager)

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

One of the challenges we are facing as part of a current project that we are working on is to demonstrate the integration of WSRR (WebSphere Registry and Repository) and RAM (Rational Asset Manager).

First and foremost there are a lot of questions on the roles and responsibilities of both these products.

• Do we need both products?
• If so, what do we use RAM for and what do we use WSRR for?
• What is an asset?
• Is a service an asset? Can there be other assets other than services? Does that mean only service assets go into WSRR?
• What is a service? Is it just a WSDL? What about the service code? Should that also go into WSRR?
• How do these products work with one another?
• When I make a change in RAM does it reflect in WSRR and vice versa?

There are more questions than answers. I don't have answers to all these questions and as we work on this project, I am sure we will learn more. The team will post more answers here on this BLOG.

Today we took the first step. How can we get WSRR and RAM connected? I should tell you to my surprise I found that it was not difficult to accomplish this.

We had a RAM instance (v7.1) running on a VM Image.

I installed WSRR v6.2 on the same image and since it was for a POC, I used the Derby DB for WSRR. (I had installed WSRR with a DB2 backend and it had worked fine.)

There were just 2 things I needed to do to get the connectivity working

• RAM runs on a WAS instance. WSRR was running on a separate WAS instance. The communication between the two was over HTTPS. So I had to ensure that WSRR server certs were part of the trust store of the WAS server running RAM. Nothing RAM / WSRR specific here, pure WebSphere stuff.
• Log into the RAM WAS console using the following URL (https://localhost:13043/ibm/console/logon.jsp)
• Go to Security -> SSL certificate and key management > Trust managers > Key stores and certificates > NodeDefaultTrustStore > Signer certificates
• Do Retrieve from Port, Provide the following values: Host -> localhost, Port 9443, Alias WSRR
• Log out

We needed to set the configuration in the RAM Admin Console to connect to WSRR.

• Log into the RAM UI as admin
• Go to the admin tab, click on 'Community Name'
• Go to Connections
• Add a WSRR Connection
• Call in LOCAL WSRR
  - The URL to provide is https://localhost:9443/
  - User id and password is admin / admin
  - Do 'Test Connection' and that should be successful
  - Click on Synchronize and you should see the message -> WSRR-Asset Manager synchronization started
  

That’s it. Now I was able to search in RAM and have visibility into assets that were in WSRR. This was a simple test. These were stand alone instances . I assume when we do have clustered configurations we may have some challenges but it was a pleasant surprise to see something work the first time you try it.

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.

Service Gateway Pattern in WebSphere Enterprise Service Bus (WESB) 6.2

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

On of the new patterns that have been introduced in v6.2 of WESB is the Service Gateway Pattern. There are two implementations of this pattern – A Static Gateway and A Dynamic Gateway. In this blog entry I will focus on my experiences on using the Dynamic Service Gateway pattern.

One of the basic requirements that I expect in an ESB is the ability to introduce an ESB in the middle between a client and a service (without impacting either the client or the service) and be able to do provide value added services like logging, monitoring, auditing etc. This is exactly what we are able to accomplish with the Dynamic Service Gateway pattern. This gateway pattern is implemented as a mediation component. The interface for this mediation component has 2 operations, a request operation and a request response operation. Both these operations accept xsd:anyType (they are not bound to the type definitions exposed by any particular service). The reference partner for this mediation also maps to the same interface. The reason this pattern is dynamic, is because there is no coupling to services at compile time. You can dynamically set the service endpoint at runtime and invoke that service.

However what needs to be understood is that this pattern implementation works only for SOAP 1.2 based JAX WS Web Services. The reason why this restriction exists is because in JAX-RPC the invocation was RPC based -> a particular web service operation had to be specifically invoked. In JAX-WS the invocation is more messaging based. There is no specific operation invocation required. The following article series provide an in depth analysis of the differences between JAX-RPC and JAX-WS.
http://www.ibm.com/developerworks/library/ws-tip-jaxwsrpc4/index.html

The following diagrams show a sample implementation of this pattern for monitoring and auditing service invocations.


Assembly Diagram

Mediation Flow

Look up Table

Audit Table

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.