I am new to the enterprise integration area.
We have a requirement to develop a solution where multiple OSS (operations support systems) should talk to multiple EMS (element management systems) and network devices (Different transports and protocols has to be supported), solution should be such that, that it should run in Weblogic.
Queries
Which will be the best fit for this situation ESB/Apache ServiceMix/Spring Integration?
If we use opensource ESBs ( like WSo2 and Talend ESBs) I think we need to maintain two servers ESB server and Weblogic server and ESB/Weblogic integration will be an issue?
Apache servicemix or Spring Integration be deployed/run inside Weblogic?
Whether Apache ServiceMix is supported now, as I could see most updates are happening in fuse ESB only?
You need to analyze your scenario and then decide. If you need only transformation or alongside with a simple routing you can use some frameworks like smooks, camel etc.
You need to transform and still a lot of system involved where you need those transformed messages then you could use an ESB.
Then comes selecting the ESB product is also based on you application eco system. All products are amazing and each fits the better than the other in their own application eco system.
First you need to know a few things on Camel / Fuse ESB / Service Mix
All the above revolve around the same, each of them are projects where camel integration framework is the coding De fact o
1.Camel -- Integration framework and the De fact o coding way(sophisticated in its own way and much flexible)
2.Service Mix -- Container for deploying the your integration code. (Camel integration code)
3.Fuse ESB -- Enterprise Feather on the hat of Service Mix where it provides a Studio for coding , a list of components and wrappers like clustering and other facilities around service service mix
.
I would like you to also consider Mule ESB which could also and it will be a good contender in your list.
Some answers for your questions
1.You can deploy Camel code or the spring integration code into the what so ever container (all in the hands Maven and jar management thing you need to do....)
2.Service mix is a Apache license and is complete open source and if you need some support I suggest you to choose the FUSE ESB which is not part of JBoss family and powered by RedHat
Please follow this link below for more detailed discussion from other stackoverflow.com users
use the below for your analysis
Apache Camel and other ESB products
What is an ESB and what is it good for?
Messaging, Queues and ESB's - I know where I want to be but not how to get there
JMS and ESB - how they are related?
Related
I'm trying to build MQTT support into my Spring application. For this I'm looking at the references provided by Spring, which can be found here here.
They provide sample code for inbound and outbound channel adapters, but this concept of adapters is unclear to me. I couldn't find a lot of information about it on the web.
What exactly are these adapters and why are they needed?
Where do I need to define these adapters and how do I access them?
I'm using eclipse as my IDE and maven as my buildtool.
The adapters are a concept from Spring Integration which is yet another Spring project that provides an implementation of the Enterprise Integration Patterns and provides an abstraction layer that standardizes the way you integrate with external system, whether they are based on JMS, FTP or as in your case MQTT.
As with so many other Spring projects, the driver behind it is a loose coupling and standardization that will enable you to swap your channel provider (e.g. if its a JMS provider swap RabbitMQ with ActiveMQ or vice-versa) with a minimal impact to the rest of you code.
Its comparable to Apache Camel, in case your more familiar with it, and this comparison is quite an interesting read
I'm not too familiar with ESB or Biztalk and am trying to get my head around what makes the most sense from an EAI perspective if you already own Biztalk. As I understand Biztalk is a message broker(hub and spoke) and the ESB pattern is an anti-broker where the conceptual "bus" is made of individual distributed components that talk to each other somehow.
Message brokers inherently represent a single point of failure as opposed to an ESB where one component failing does not bring down the "bus" as a whole. Also my understanding is that Biztalk is monolithic in the sense that messaging, orchestrations are tightly coupled and scaling is problematic.
If the scenario at hand is:
Biztalk is already being used primarily for running different orchestrations based on different files received from outside parties.
A bunch of inhouse custom appications which are currently tightly coupled to system such as CRM and payroll need to be refactored to abstract out these dependencies.
Would it make sense to use Biztalk directly or Biztalk ESB toolkit for achieving ESB functionality or would it make sense to use a proper ESB implementation such as NServiceBus or Service Bus for Windows which is based on Azure Service Bus.
What are the pros and cons of using Biztalk directly to achieve EAI vs. using a proper ESB.
Would each application take a hard dependency on Biztalk and whether this is desirable?
I will leave this as an open ended discussion since there is no right or wrong answer.
#StuartLC:
Thanks for your response. I've read several of the links you posted but still did not get a clear sense of whether Biztalk would make sense as an ESB solution vs. using something like NServiceBus. Both seem to implement the "ESB" pattern in one way or another. Question being which one has a cleaner implementation, better development experience and low ramp up time. My assessment so far(from pure research only) is that yes Biztalk can be used but it is painful and requires very specialized dev. skill sets. Latency and scaling being problematic and the fact that Biztalk will
eventually be assimilated into the (Azure?) Service Bus and the Biztalk SKU will cease to exist.
On the other hand, a framework like NService bus has relatively low ramp up time, can be easily picked up by a dev. having good .NET programming skills in general and can interface easily with Biztalk.
Given the above, would it still make sense to go the Biztalk route even though you currently have Biztalk in house or to future proof yourself go with a proper ESB such as NService Bus ?
I believe many components of your open-ended question have already been covered on SO:
Pros/Cons of using BizTalk instead of NServiceBus or MassTransit
What ESB systems work best for the .Net stack?
Microsoft BizTalk Server vs Azure AppFabric Service Bus...?
BizTalk 2009 ESB Confusion
Is BizTalk an ESB?
However, IMO it is just a flawed / short-sighted implementation which which would result in tight coupling between apps and endpoints. Loose coupling is easily achieved : (even without the ESB toolkit):
By using multipart messages and canonical internal schemas for decoupling dependencies.
Orchestrations and ports should be decoupled by publishing via the message box
Single point-of-failure is also avoidable:
Configuring Retries and Alternative / backup transports on communication adapters
Redundancy achieved e.g. via Server Groups and Clustering
And fall back using compensation for failed delivery
IMO the Achilles heel when using BizTalk as an ESB is the lack of guaranteed latency e.g. here which is exarcebated if BTS gets into a throttling state.
Update
IMO the choice boils down to a matter of whether you have control over all systems in your environment.
If you are integrating an internal enterprise consisting only of homogeneous, contemporary (and mostly SOA and EDA) applications over which you have direct control, MassTransit or NServiceBus would likely more than do the job give and you better productivity and ramp up time.
we are building a distributed Java system (should be scalable ;-) ) that is connected only with JMS (ActiveMQ). I studied Spring Integration and I am not sure what the advantage would be if we use it. I think we are better off with using the JMS-Templeate from the Spring Core Project as we send only messages from a JavaService to another JavaService and so on.
Use Spring Integration (or any other framework) if you think the extra abstraction that it buys you is worth the cost. It should give you a more solid foundation on which to build your application. Software written by Spring is better than anything you or I would write from scratch.
All frameworks have a cost. There are additional dependencies. Sometimes greater abstraction can obscure too much.
You should prototype with and without Spring Integration to see if it's worth the cost.
If you're not a Spring user already, I'd recommend that you learn Spring before jumping into a big enterprise project.
SpringIntegration will give your Enterprise Integration Pattens ready to use.
Are you going to need splitters, routers, filters, gateways, aggregators, transformers, etc?
If the answer is no, go for plain Java+ActiveMQ.
If you need a really powerful system integration tier, then you should use Spring Integration - it's an additional level of abstraction which may help when your system will grow. With SI it's a matter of seconds to add new integration processing rule between two systems.
From the other hand, I've worked on some SpringIntegration+ActiveMQ project, and it was almost impossible to configure this broker to work with SI in the reliable way. So if you decide to use SI I'd recommend HornetQ as a JMS broker - this one works fine.
I am a BTS dev with four years experience implementing "classic" BTS solutions.
I have to do a surprise presentation tomorrow on the ESB toolkit 2. Don't ask why. I would like to be as prepared as possible. I am looking for resources which can be quickly assimilated. Ideally (in rough order of importance):
A technical overview of the main moving parts
A few of the implementation details, descriptions of itineraries, resolvers, on-ramps etc.
Installation and deployment.
Any swift help would be greatly appreciated.
If you're familiar with the picture in the Pro BizTalk 2009 book the ESB poster might help you translate some of that info.
Here are some resources:
(obvious) ESB 2.1 on MSDN
The Pro BizTalk 2009 book has a chapter in it on ESB with sections:
BizTalk and the ESB Concept
The Architecture
The Functional Components
Working with Itineraries
Using the Toolkit
Summary
Interesting thread where Richard Seroter posts some info. (author of SOA Patterns with BizTalk Server 2009)
The ESB Toolkit is large toolkit, it's somewhat unfair to ask you to a presentation on it with so little time to prepare.
In its most simple form, say you have a classic BizTalk implementation that does something simple like pickup a file a directory, drive it through some biz process in an orchestration, transform it, and drop it in another directory.
With the ESB toolkit, you would create an itinerary that gets attached to the message and the itinerary are basically instructions on how/what should happen to it. So your business process orchestration and maps are de-coupled from the solution. This also affords you the ability to make changes to the itinerary without re-building the solution. As the itinerary is being driven, services like the map that is needed to transform your messaged can be "looked up" in the UDDI registry. All the while the ESB exception management piece can give devs/admins/users a nice web interface into a central location where all your exceptions are sent. The exception management portal can also provide notifications and alerts for all kinds of exception criteria.
In addition to Derek's answer, I would also suggest readidng up on the ESB Portal and Exception Handling framework components in the Toolkit. I would say that most of my clients using the ESB components are only using those components, and not itineraries, UDDI, etc.
I have been able to configure Hyperic HQ to identify servicemix 4, however, It could only see the "ServiceMix 4.x Garbage Collector" service. I would like to be able to monitor activemq Queues, Endpoints, and Camel Applications (if possible)
Has anyone been able to do this?
I ran into the same issue at a client recently. We didn't find any support for doing this with HypericHQ, so we built our own basic web app using JSP, Ajax/jQuery and JMX to interface with AMQ/Camel. Another option is to customize the ActiveMQ and Camel web consoles...
Here are some notes on using JMX to monitor/manage both ActiveMQ and Camel...
http://benoday.blogspot.com/2010/08/managing-camel-routes-with-jmx-apis.html
http://benoday.blogspot.com/2010/08/monitoring-and-managing-activemq-with.html
Also, I know the Camel team is looking to enhance the web console in future releases (see the 3.0 roadmap)
good luck...