View AJ's interview on Healthcare Infrastructure Demands!
Interested in learning more? Contact AJ Aronoff today - aj@prolifics.com.
To learn more about Prolifics, visit www.prolifics.com.
Showing posts with label Application Server. Show all posts
Showing posts with label Application Server. Show all posts
Monday, May 20, 2013
Prolifics' AJ Aronoff on Healthcare Infrastructure Demands
AJ Aronoff is a Practice Director and IBM Champion covering Application Infrastructure at Prolifics. Recently at IBM Impact, AJ was interviewed on current infrastructure demands in the healthcare industry. Specializing in solutions for the healthcare industry, AJ explains how he can help the industry understand the latest healthcare regulations. In this video, he discusses the value that IBM WebSphere Application Server (WAS) brings to the industry, and the latest advancements in WAS 8.5. In addition, AJ explains the impact mobile technology is having on the healthcare space, opening up the possibility to cut down on a lot of the paperwork as well as allowing doctors and medical staff to record information at each bedside.
View AJ's interview on Healthcare Infrastructure Demands!
Interested in learning more? Contact AJ Aronoff today - aj@prolifics.com.
To learn more about Prolifics, visit www.prolifics.com.
AJ Aronoff is the Application Infrastructure Practice Director for Prolifics and an IBM Champion for IBM WebSphere. AJ first joined Prolifics as a Developer, then specialized in WebSphere MQ. He has 25 years experience in the IT field — 17 of those years at Prolifics. As a Prolifics consultant, he has done MQ design, implementation, infrastructure, monitoring and security assignments at several large financial, insurance, retail and communication firms (Bloomberg, Credit Suisse, Deutsche Bank, DTCC, Fidelity, ITG, JPMC, Och Zif, Tokyo Marine, Pep Boys and British Telecom). He has presented on security and infrastructure at Impact, Hursley comes to Minneapolis and Palisades, and MQ User Groups. His customers use Omegamon to monitor over a thousand systems across the globe.
View AJ's interview on Healthcare Infrastructure Demands!
Interested in learning more? Contact AJ Aronoff today - aj@prolifics.com.
To learn more about Prolifics, visit www.prolifics.com.
Wednesday, December 19, 2012
TCO Analysis: IBM WebSphere® Application Server V8.5 vs. JBoss® Enterprise Application Platform V6
With an array of products in the JEE Application Server markets, Prolifics set out to compare IBM WebSphere Application Server Network Deployment (WAS ND) version 8.5 and the Red Hat JBoss Enterprise Application Platform (JBoss EAP) version 6. During this extensive analysis, Prolifics compared features and total cost of ownership (TCO), including tests that covered a wide variety of conditions and factors and using the same hardware, OS and patch levels and vendor agnostic applications to ensure that no vendor had an unfair advantage.
In this study, Prolifics found that in most environments, while acquisition costs for JBoss EAP are lower, IBM WAS ND provides lower overall TCO due to its advantages in stability, high availability, manageability, documentation and performance. In fact, over the period of 5 years, “free” JBoss is 35% more expensive than WAS ND.
The cost of web application server ownership doesn't end with the initial purchase. When choosing the best server for your organization, it's important to be aware of the additional costs that come with open source software. Read this in-depth analysis for more on the study.
Prolifics has over 12 years of experience in the Java sphere and is the leading specialist in migrating applications between application server environments and upgrading existing applications to newer standards. For more information, visit www.prolifics.com or email solutions@prolifics.com.
In this study, Prolifics found that in most environments, while acquisition costs for JBoss EAP are lower, IBM WAS ND provides lower overall TCO due to its advantages in stability, high availability, manageability, documentation and performance. In fact, over the period of 5 years, “free” JBoss is 35% more expensive than WAS ND.
The cost of web application server ownership doesn't end with the initial purchase. When choosing the best server for your organization, it's important to be aware of the additional costs that come with open source software. Read this in-depth analysis for more on the study.
Prolifics has over 12 years of experience in the Java sphere and is the leading specialist in migrating applications between application server environments and upgrading existing applications to newer standards. For more information, visit www.prolifics.com or email solutions@prolifics.com.
Wednesday, April 18, 2012
Ohio National Financial Services: IBM WebSphere Virtual Enterprise Implementation in a Mid-Size Company with Big Company Needs - IBM Impact Session #2417
Prolifics customer Ohio National Financial Services is presenting at IBM Impact 2012! Join Ohio National on Wednesday, May 2nd at 1:30pm for a look into the organization’s IBM WebSphere Virtual Enterprise Solution.
Here’s a preview of what Ohio National will outline during this session:
Ohio National Financial Services’ implementation of WebSphere Virtual Enterprise proves that companies of any size can reap benefits from the product. During this session, attendees will learn how WebSphere Virtual Enterprise has allowed them to do more with less by helping them consolidate their WebSphere Application Server infrastructure on a smaller set of virtual machines saving them capital costs. Operationally they have taken advantage of uninterrupted application rollouts to reduce downtime and increase staff productivity. As they mature with the product, they will be able to achieve even greater benefits for their WebSphere Application Server infrastructure using by implementing service policies to ensure service level agreements are met for their applications.
We’re looking forward to hearing more of Ohio National’s presentation! For more information, click here.
Session Details:
Session Number: 2417
Date: Wednesday, May 2, 2012
Time: 1:30pm – 2:45pm
Location: Palazzo M
Here’s a preview of what Ohio National will outline during this session:
Ohio National Financial Services’ implementation of WebSphere Virtual Enterprise proves that companies of any size can reap benefits from the product. During this session, attendees will learn how WebSphere Virtual Enterprise has allowed them to do more with less by helping them consolidate their WebSphere Application Server infrastructure on a smaller set of virtual machines saving them capital costs. Operationally they have taken advantage of uninterrupted application rollouts to reduce downtime and increase staff productivity. As they mature with the product, they will be able to achieve even greater benefits for their WebSphere Application Server infrastructure using by implementing service policies to ensure service level agreements are met for their applications.
We’re looking forward to hearing more of Ohio National’s presentation! For more information, click here.
Session Details:
Session Number: 2417
Date: Wednesday, May 2, 2012
Time: 1:30pm – 2:45pm
Location: Palazzo M
Tuesday, April 10, 2012
Business Orchestration Server for IBM WebSphere Operational Decision Management
The event runtime is a shared, secured component that runs Decision Server Events assets such as business objects, events, and actions. After the business events are defined and developed using development tools such as Event Designer and Business Space it needs to be deployed to be available at runtime to be executed.
Interaction between event runtime and outer application happens using the various connectors. The event runtime starts collecting and filtering the business event information it receives from the connectors that have been implemented and business users have described and stored. The event runtime environment sorts through the volume of event information it receives and associates the relevant information it detects, it can then match whether the event is pertinent to the defined patterns and correlations that the business users have described and sorted.
Business information can be from short activity, combination of multiple events or may be complex events processing, once runtime senses a defined pattern it initiates action which can be anything defined by the system. Once we deploy the event runtime it retrieves the assets and uses them as instructions during event handling to do tasks such as creating business objects, evaluating filters in event rules and firing actions.
The picture below depicts high level architecture for Business Orchestration Server (The event runtime)
As shown in the picture above Business Orchestration Server (rhe event runtime) is implemented on WebSphere Application Server. It is installed and deployed as an application (wberuntimeear) with in WebSphere Application Server to take advantage of all the benefits of WebSphere Application Server including high availability, scalability, security and transparency of operations and use.
Since event runtime is actually an application running within WebSphere Application Server its access is controlled by WebSphere Application Server. The event runtime is based on publish/subscribe architecture and it supports messaging layers of WebSphere Application server and utilizes WebSphere messaging platform. Basic concept and mechanism on which event runtime works on is CBE (Common Base Events) and CEI (Common Event Infrastructure)
CBE is defined as standard/platform independent XML schema to be used for the format of business events to be sent to runtime using connectors
CEI is an event notification and event transmission framework that is used as a mechanism for passing events in CBE format to event runtime
The CEI is IBM's implementation of a consistent, unified set of APIs and infrastructure for the creation, transmission, persistence and distribution of a wide range of business, system and network CBE-formatted events
CEI provides public interfaces to:
The CEI provides a point of integration to consolidate events from a number of potentially disparate and diverse sources. It also provides the ability to distribute these events to consumers. These events are represented using the CBE model described.
Using CEI products, applications and functions are able to integrate their events. This enables the support of the end-to-end business-centric process views that these services make up.
At the runtime during the execution of Business Events we need to have database system configured as the runtime configuration for Business Events is stored within the database and at the time of initialization and real run time it retrieves the data to process the incoming events. For complex processing of events and executing actions database can also be configured to store information about for subsequent processing.
The event runtime supports almost all Professional RDBMS databases
The picture below depicts the Business Orchestration server run-time architecture
Business Orchestration Server (The event runtime) mostly consists of these following components:
The following picture depicts the event runtime processing:
The event runtime manages the real-time business event coordination that was defined during application development. As an event occurs in a touchpoint that potentially requires one or more actions in another touchpoint, the relevant data (field name, field type, and value), called an event payload, and is passed using the connector of the touchpoint to the JMS message queue. Web services environments that employ SOAP to package messages and other protocols like HTTP, can direct those messages through the JMS queue.
The event runtime retrieves the message from the JMS queue and populates the appropriate intermediate objects with the values contained in the event payload. The event runtime parses the event, identifies the interaction sets that reference the event and determines whether any filters exist that require further evaluation.
If an action includes a filter, the event runtime attempts to evaluate it to determine if the filter conditions for a given action have been met. For complex event processing, this includes determining if referenced events or actions have occurred or not occurred as described in the filter condition. If any values are missing, the event runtime will attempt to retrieve the missing information from an external data source. The action is initiated only if the filter condition is true.
If the action does not include a filter, then the appropriate action will be initiated.
The event runtime passes the relevant data (field name, field type, and value) associated with the action from intermediate objects as an action payload to the outbound message queue, where it is picked up by the appropriate connector. The connector pushes the data to the appropriate touchpoint(s) and initiates logic within the touchpoint to perform the appropriate activity. The connector might return a result back to the JMS queue, where it is retrieved by the event runtime as a new event and processed appropriately.
If the action requires human intervention, it is directed to User Console, where the user can access it. When the user responds to the information displayed on the screen, the response is sent back to the JMS queue as a result event, where it is retrieved by event runtime as a new event and processed appropriately.
History for events, actions and filters used in event rule group evaluation is stored in a History database manager. This information is retrieved, formatted and displayed as charts in real time in Business Space by the Event Chart widget.
Alok Keshri, a Technical Manager for Prolifics focusing mainly on ILOG-JRules and WODM 7.5, has over eleven years of experience in the IT industry spanning across various industries. He is an experienced and resourceful enterprise software Tech Lead/Architect and has worked with J2EE/ SOA/BRMS/ BPM technologies. He is specialized in Object Oriented Analysis, Design, Development, and Estimation of projects with heterogeneous Web technologies in complex business systems based on a variety of platforms. He has extensive experience in IBM middleware products such as WebSphere Application Server, WebSphere ILog-JRules, WebSphere Message Broker and other products in the IBM BPM stack. He is also certified in WebSphere ILOG-JRules and FileNet. Alok received his BE in Electrical Engineering in 2000.
Interaction between event runtime and outer application happens using the various connectors. The event runtime starts collecting and filtering the business event information it receives from the connectors that have been implemented and business users have described and stored. The event runtime environment sorts through the volume of event information it receives and associates the relevant information it detects, it can then match whether the event is pertinent to the defined patterns and correlations that the business users have described and sorted.
Business information can be from short activity, combination of multiple events or may be complex events processing, once runtime senses a defined pattern it initiates action which can be anything defined by the system. Once we deploy the event runtime it retrieves the assets and uses them as instructions during event handling to do tasks such as creating business objects, evaluating filters in event rules and firing actions.
The picture below depicts high level architecture for Business Orchestration Server (The event runtime)
As shown in the picture above Business Orchestration Server (rhe event runtime) is implemented on WebSphere Application Server. It is installed and deployed as an application (wberuntimeear) with in WebSphere Application Server to take advantage of all the benefits of WebSphere Application Server including high availability, scalability, security and transparency of operations and use.
Since event runtime is actually an application running within WebSphere Application Server its access is controlled by WebSphere Application Server. The event runtime is based on publish/subscribe architecture and it supports messaging layers of WebSphere Application server and utilizes WebSphere messaging platform. Basic concept and mechanism on which event runtime works on is CBE (Common Base Events) and CEI (Common Event Infrastructure)
CBE is defined as standard/platform independent XML schema to be used for the format of business events to be sent to runtime using connectors
CEI is an event notification and event transmission framework that is used as a mechanism for passing events in CBE format to event runtime
The CEI is IBM's implementation of a consistent, unified set of APIs and infrastructure for the creation, transmission, persistence and distribution of a wide range of business, system and network CBE-formatted events
CEI provides public interfaces to:
- Publish (or emit) an event
- Subscribe to events that match a particular filter (event group)
- Consume an event
- Query historical event data (if the optional event data store is enabled, this can be achieved via a published interface)
The CEI provides a point of integration to consolidate events from a number of potentially disparate and diverse sources. It also provides the ability to distribute these events to consumers. These events are represented using the CBE model described.
Using CEI products, applications and functions are able to integrate their events. This enables the support of the end-to-end business-centric process views that these services make up.
At the runtime during the execution of Business Events we need to have database system configured as the runtime configuration for Business Events is stored within the database and at the time of initialization and real run time it retrieves the data to process the incoming events. For complex processing of events and executing actions database can also be configured to store information about for subsequent processing.
The event runtime supports almost all Professional RDBMS databases
The picture below depicts the Business Orchestration server run-time architecture
- The event runtime is the core of Business Events. This is where the logic of business event processing takes place.
- Connectors are internal system components that provide codeless connection to and from touchpoints via a variety of protocols.
- The repository provides shared, secured storage for definitions of Business Events assets.
Business Orchestration Server (The event runtime) mostly consists of these following components:
- WebSphere Application Server Network Deployment
- A RDBMS to contain the repository such as business objects, events, actions….
- The Decision Server Events application for business event processing (BEP), wberuntimeear
- The WebSphere Business Events application installed and deployed with in WebSphere Application Server Network Deployment.
- Java Message Service message queue managed by a message queue server such as WebSphere Application server ND service integration bus or WebSphere MQ.
- Event connectors and action connectors for touchpoints
- A database manager to serve as a message store for persistent messages
- A LDAP or Microsoft Active Directory, if user authentication is required
- JDBC drivers for database access at runtime
The following picture depicts the event runtime processing:
The event runtime manages the real-time business event coordination that was defined during application development. As an event occurs in a touchpoint that potentially requires one or more actions in another touchpoint, the relevant data (field name, field type, and value), called an event payload, and is passed using the connector of the touchpoint to the JMS message queue. Web services environments that employ SOAP to package messages and other protocols like HTTP, can direct those messages through the JMS queue.
The event runtime retrieves the message from the JMS queue and populates the appropriate intermediate objects with the values contained in the event payload. The event runtime parses the event, identifies the interaction sets that reference the event and determines whether any filters exist that require further evaluation.
If an action includes a filter, the event runtime attempts to evaluate it to determine if the filter conditions for a given action have been met. For complex event processing, this includes determining if referenced events or actions have occurred or not occurred as described in the filter condition. If any values are missing, the event runtime will attempt to retrieve the missing information from an external data source. The action is initiated only if the filter condition is true.
If the action does not include a filter, then the appropriate action will be initiated.
The event runtime passes the relevant data (field name, field type, and value) associated with the action from intermediate objects as an action payload to the outbound message queue, where it is picked up by the appropriate connector. The connector pushes the data to the appropriate touchpoint(s) and initiates logic within the touchpoint to perform the appropriate activity. The connector might return a result back to the JMS queue, where it is retrieved by the event runtime as a new event and processed appropriately.
If the action requires human intervention, it is directed to User Console, where the user can access it. When the user responds to the information displayed on the screen, the response is sent back to the JMS queue as a result event, where it is retrieved by event runtime as a new event and processed appropriately.
History for events, actions and filters used in event rule group evaluation is stored in a History database manager. This information is retrieved, formatted and displayed as charts in real time in Business Space by the Event Chart widget.
Alok Keshri, a Technical Manager for Prolifics focusing mainly on ILOG-JRules and WODM 7.5, has over eleven years of experience in the IT industry spanning across various industries. He is an experienced and resourceful enterprise software Tech Lead/Architect and has worked with J2EE/ SOA/BRMS/ BPM technologies. He is specialized in Object Oriented Analysis, Design, Development, and Estimation of projects with heterogeneous Web technologies in complex business systems based on a variety of platforms. He has extensive experience in IBM middleware products such as WebSphere Application Server, WebSphere ILog-JRules, WebSphere Message Broker and other products in the IBM BPM stack. He is also certified in WebSphere ILOG-JRules and FileNet. Alok received his BE in Electrical Engineering in 2000.
Thursday, September 29, 2011
Choosing a Messaging System: WebSphere MQ vs. WebSphere Application Server Service Integration Bus
A question that sometimes comes up in our architecture whiteboarding sessions is about the different messaging strategies that are available in Websphere Application Server. IBM developerWorks has now published a great article detailing the differences between WebSphere MQ and the Service Integration Bus that comes with WebSphere Application Server. Check it out by clicking here.
Subscribe to:
Posts (Atom)