I came to know that aqualogic service bus is renamed to oracle service bus when oracle acquired BEA. Is there a relationship between oracle fusion middleware and oracle service bus or are they totally independent of each other? Thanks
Oracle Service Bus is a product within the Oracle Fusion Middleware suite.
Enterprise Integration aims to connect and combine people, processes, systems, and technologies to ensure that the right people and the right processes have the right information ant the right resources at the right time.
Integration can be done using
Integration Framework
ESB
Integration Suite
The Enterprise Service Bus (ESB) has been most widely accepted as a tool to support application integration. However it is to be noted that on the integration complexity path, an ESB usually falls between a framework and a suite as an alternative for application integration.
OSB is an Enterprise Service Bus and Oracle Fusion middleware is an Integration Suite.
Related
I am new to IBM Integration bus and I would really appreciate if anybody tell me how to connect IIB with the PD (IBM BPM). I tried to get some reference materials for the same but the description in the material is for Message broker fix pack 1 and its different from what we have now in IIB 9.0.0 & 10.0.0
IBM BPM can expose some Web Sercives if you build then within a Process Aplication. By the book the IBM BPM come with a REST API to interact to product itself.
Consider this charecteristcs the way to integrate with then is using HTTP Request ou SOAP Request in the IBM Integration Bus Flow.
there are certain ways to communicate IIB with IBM BPM.
1 through web services (SOAP and REST).
2 UCA(Under Cover agent)
3 Database
but preferred way would be UCA and Web Services
I have got a requirement to test an application which upgrades from web methods 8.2 to 9.5 in ESB.
While I tried to understand what is an ESB, I assume that ESB can be of 2 types - Web Sphere Enterprise Service Bus V6.0.2 and Web Sphere Message Broker V6.0.0.3.
Now what does the Term web methods imply ? What is the relation between the 3 terms - Web Sphere Enterprise Service Bus, Web Sphere Message Broker aESBnd Web Methods ?
I tried to google and in some places, it is mentioned as broker is part of ESB and some places, it is like we can use either broker or esb ... But I am still not clear how this 3 terms are related with each other.
Please clarify
There is no connection between WebMethods and WebSphere products. WebMethods is an ESB made by SoftwareAG. ESB is a generic term for referring to messaging busses (let's say software for transferring messages). Latest version seems to be 9.5. Your requirement is to upgrade their ESB (that is WebMethods) from version 8.2 to 9.5.
WebSphere Message Broker is also an ESB. This one is made by IBM. So is WebSphere Enterprise Service Bus, but this one is made to cover other use cases. The later is discontinued, and the former is being renamed to IBM Integration Bus.
IBM Websphere documentation says that It's possible to use third-party jms providers: http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftmj_instp.html
In oracle folder I've found resource adapter ojms.rar, but how to use it?
Maybe somebody uses WAS7 with AQ?
I haven't used OracleAQ myself, but here are links to the documentation; Since AQ is JCA compliant you may start with Managing messaging with a third-party JCA 1.5-compliant messaging provider. First step of this configuration is installing the resource adapter (ojms.rar).
Also, for sake of completeness, let me add that you may also access AQ using WebSphere Adapters. In this case, you don't configure AQ as JMS provider, but use the IBM suuplied adapter to access AQ, which acts as a client to your AQ and exposes AQ services to your applications in a JCA compliant fashion. You may find more information about this alternative at education assistant for WebSphere Adapter for Oracle E-Business Suite.
I recently tried to integrate Websphere with Oracle AQ and found one solution that works. I have explained how to do it in a Blog. http://itsolutionsarchitect.blogspot.com/
If you are still trying to get this to work, let me know if this helps.
If you're still looking for the answer, follow the steps to install the resource adapter using ojms.rar
Sadly `ojms.rar`` doesn't contain the classes required for installation.
Download mqjra.rar, extract it and take out gjra.jar from the extracted files.
Place gjra.jar inside your <WAS installation directory>\lib
Try to install the Resource adapter with ojms.rar
It'll get installed. Revert if you face issues.
I want to adopt a solution of EIP for cloud deployment for a web application:
The application will be developed in such an approach that each layer (e.g. data, service, web) will come out as a separate module and artifact.
Each layer has the opportunity to deployed on a different virtual resource on the cloud. In this regards, web nodes will in a way find the related service nodes and likewise service nodes are connected to data nodes.
Objects in the service layer provide REST access to the services in the application. Web layer is supposed to use REST services from service layer to complete requests for users of the application.
For the above requirement to deliver a "highly-scalable" application on the cloud, it seems that solutions such as Apache Camel, Spring Integration, and Mule ESB are of significant options.
There seems to be other discussion such as a question or a blog post on this topic, but I was wondering if anybody has had specific experiences with such a deployment scheme on "the cloud"? I'd be thankful for any ideas and sharing experiences. TIA.
To me this looks a bit like overengineering. Is there a real reason that you need to separate all those layers? What you describe looks a lot like the J2EE applications from some years ago.
How about deploying all layers of the application onto each node and just use simple Java calls or OSGi services to communicate.
This aproach has several advantages:
Less complexity
No serialization or DTOs
Transactions are easy / no distributed transactions necessary
Load Balancing and Failover is much easier as you can do it on the web layer only
Performance is probably a lot higher
You can implement such an application using spring or blueprint (on OSGi).
Another options is to use a modern JavaEE server. If this is interesting to you take a look at some of the courses of Adam Bien. He shows how to use JavaEE in a really lean way.
For communicating between nodes I have good experiences with Camel and CXF but you should try to avoid remoting as much as possible.
I understand JMS spec allows me to write MDBs. Then I can deploy them on an appserver like websphere or jboss (and they have inbuilt implementation of JMS provider which is Java EE compliant). The question is when to use a full fledged product like IBM WebSphere MQ or ACtiveMQ instead of using App server's inbuilt JMS provider.
This appears to be a good reference to what you are asking, specific to IBM products but can be generalized to using an application server integrated messaging system vs a standalone messaging system - http://www.ibm.com/developerworks/websphere/library/techarticles/1109_wallis/1109_wallis.html
A built in JMS provider, such as WebSphere SI Bus, possibly others, are built for JMS messaging.
WebSphere MQ (MQSeries), ActiveMQ etc. have clients for multiple languages and are built for applications other than Application Server hosted applications to connect to it (C++, Java SE, Python, etc).
Say you want a local messaging server on the same physical server (or network?) as a non JavaEE application, you don't want to install a Java EE App Server, but want a stand alone messaging server instead (WebSphere MQ, Active MQ).
That said, ActiveMQ, for instance, is the messaging system inside Apache Geronimo. So there is overlapping here.
Then there is a whole discussion about management, clustering and security. Java EE messaging systems are pretty much optimized to follow the cluster layout of Java EE. In other deployment scenarios, the clustering might be optimal in other ways, such as cluster for different security zones. Also security models and management tools might be different in stand alone messagaing servers.