One of our US-based customer in the business of distribution of HVAC products wants to use Epicor Prelude product.
We want to know whether Prelude can be integrated with a java based web application and if it supports -Web services, Messaging queues and Enterprise Service Bus / Middleware(eg. BizTalk).
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 few basic douts.
I have developed a JMS application for P-P and the messages are geeting stored in Jboss 7.1 JMS engine. My questions are below.
1.For any JMS application do we need to have any messaging engine like IBM MQ,HornetQ,Active MQ etc
If Yes then we need to configure the MQ to atlk to Appserver Messaging engine.
3.If No, Then we need to have to create a message consumer
JMS is a specification of a messaging interface - and a state model for how messages are handled in transactions.
jms.jar contains pretty much all interfaces - no implementations. Therefore whilst you can write an application against jms.jar you can't actually run it.
You'll need to pick some type of messaging provider. That's appropriate to your requirements.
That's not a discussion for here however keep in mind that they each have possible extensions and functional behavior outside of the specification so if you want to be portable between providers pay close attention to only use specification defined functionality.
Within a JavaEE Application Server there will be a JMS implementation that provides messaging features. Therefore an app here in JBOSS will be a MOM (messaging oridentated middleware) application. If you want the message to be accessed by an application not running in a JavaEE server then that is possible with some providers. There's often a JavaEE client container. Or the messaging engine will have a JavaSE based client that can be used. (WAS thin client client for example).
Remember that with JavaEE servers you are not restricted to a the choice of messaging provider - you can use the JCA interface to directly plug in a external messagin implementation. This might present an easier route if a lot of messaging will be outside the JavaEE server.
EDIT - added JavaEE notes
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The high degree of modularity encouraged by OSGi is desirable for a set of SOA services that I am working on.
Each service will consist of a back end service (which includes some persistence) a service interface (e.g. SOAP/REST) and a front end UI.
The native carbon product seems to be a nice fit whereby my services would be created as custom OSGi Carbon components.
What are the pro's and con's of custom OSGi Carbon components versus using the WSO2 Stack (DSS, ESB, AS, etc) for implementing SOA services?
Summary of responses received
As this question has been closed, this is a summary of the responses received.
Reasons for creating WSO2 Custom Carbon Components (OSGi) based SOA services:
You are extending WSO2
You already have OSGi components that you wish to reuse
You would like to reuse the Carbon UI framework
Reasons for using WSO2 Product based SOA services
Ease of monitoring and management of service lifecycle using Carbon admin UI
Easier to develop SOA functionality (no java code required for ESB and DS functionality
I guess a combination of approaches could be used, for example backend service created as WSO2 Product based service and front end created as a WSO2 custom carbon component?
If you're providing the UI for your service in the Carbon admin console itself, which probably means you're extending/enhancing product functionality then yes, you must go down the path of writing OSGi bundles. Example: you're adding a new throttling algorithm which allow users to configure new throttling policies through the admin console which accepts many different parameters.
If you're developing functionality which will be used in a user level application, then you're not suppose to go down the OSGi path. Unless you're enhancing/modifying the platform you don't have to know anything about OSGi. For end users, when configuring the ESB, you don't have to write custom code unless your scenario cannot be configured with the existing mediators. ESB and DSS therefore follows a configuration driven approach (for end users) when you have to develop new services.
custom OSGi Carbon components
I believe that you have implemented your services as OSGi bundles. So, the service control can be done by at OSGI level. If you look at our carbon admin services, those are OSgi services and you can control them at OSgi level.
using the WSO2 Stack (DSS, ESB, AS, etc) for implementing SOA
services
Here wso2 stack provides to implement an interface for an existing service (eg: esb proxy), or exposing an existing data layer to outside the world( eg: DS) or You can implement your own services, which are in common pattern such as spring/*.aar and deploy them in (eg: AS)
For my understanding, OSGI service and the services which you try to create using wso2 stack , both should work without any major issues.
But when comes to monitoring, i think OSGi services wont be that much easy, since you have to use OSGi commands..
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.