2013-06-27 Meeting Notes
- Vishnuvardhan Piskala
Date
27 June 2013
Attendees
Goals
The objective of this meeting is to discuss what we can implement for the next release/future releases considering the limited resources we have . There was already a meeting happened during late 2008 discussing the road map. The document is here: https://docs.google.com/document/d/1LWk4Rr3HO4mqPrh1WnueJa3tBIFAGmpO84Qvic-ijYs/edit.
I have also come up with the various features comparing OpenESB with other competing products. We need to prioritize these, study the technical feasibility and try to implement them. If we cannot implement all the features, do we have alternatives in proposing the solutions to our customers which can work with open esb? Can we make some changes in OpenESB so that it can work with other products to support the solution?
Discussion Items
| Item | Notes |
|---|---|
| Which app.server we should we focus on top of already migrated ones | We agreed that we will also add support for Jboss 7 in addition to existing platforms |
. Support Enterprise Integration Patterns This is can be achieved through BPEL process. Although BPEL comes to help to do this, it is a overkill to use BPEL for everything. Performance gets affected severely. Solution: Simple integration frameworks like CAMEL can be utilized here to implement EIPs. But the problem is camel also comes with transport/protocol adapters which duplicates the already available Binding components. So how do we integrate Camel with OpenESB without transport protocols? or is there any other alternatives available? Need design analysis... | Logicoy and team will implement Camel SE |
| Webservices Registry / Repository. This is for the user to manage and monitor all the services under one roof. How can we achieve this.? Should this be a UDDI compatible registry? | We can modify HTTP BC to register the services in UDDI registry. We can use external uddi browser for browsing services. |
| XSLT SE | It is in working condition. But there is no mapper available. Low priority to develop ui based mapper. |
| IEP SE | Paul mentioned they are getting a resource to work on this. |
| Rules4JBI SE | Nicolas said he is already working on this. |
Pending items to discuss:
3. SOA Governance. I think this can be achieved only if we have registry/repository.
Some key activities that are often mentioned as being part of SOA governance are:
Managing the portfolio of services: planning development of new services and updating current services
Managing the service lifecycle: meant to ensure that updates of services do not disturb current service consumers
Using policies to restrict behavior: rules can be created to which all services must conform, ensuring consistency of services
Monitoring performance of services: because of service composition, the consequences of service downtime or underperformance can be severe. By monitoring service performance and availability, action can be taken instantly when a problem occurs.
Managing how and by whom services are used
4. Cloud integration / Cloud connectors / iPaaS - Identify cloud software and select which adapters we need to have / how to integrate with those cloud apps? Research on Mule's Cloud Hub.
5. BPMN 2.0 - Execute workflows defined in BPMN 2.0 xmls. Can we use activiti for this?
6. Business Activity Monitoring - What and How ?
7. Security and Identify Management - This is a very important topic. Our ESB should be able to integrate with existing security and identity management system. Glassfish 2.2 supports this to some extent. Like, we can configure LDAP or database security for all the apps running under glassfish. This includes webservices based on HTTP BC. But we cannot configure one security realm per app. How does other app.server fares in this?
8. ESB Monitoring
- What to monitor?
- SLA Alerts?
- Integration monitoring framework with other products like HP Open View, Tivoli etc.
- Runtime performance manager ?
9. Handling Binary content - I think should should be supported as NM attachments.
10. Better fault handling.
Currently when any fault which is thrown from a BC or SE is thrown as a system fault. This should be improved. All the BCs and SEs should be able to specify what faults they can throw. We should be able to catch those specific faults in BPEL.