Following a merger of two companies, what would be the best tool for enterprise integration:
- Camel or XAware?
- or both for different needs?
It seems that there is some overlap with maybe XAware more focused on data integration and Camel having a wider view of integration (including workflow, routing, etc.)
Your comments?
What are the strengths and weaknesses of each product in such a context?
I would vote for Camel. Though I never used XAware... You can do lot of stuff very easily in Camel and is one of the best frameworks I ever used
Given the lack of more specific information, I'd recommend giving Camel a serious look to see if it meets your needs. It has a strong community following, its open source, has good documentation, is lightweight and flexible (see architecture page for more information).
That being said, I've never used XAware and I am a Camel Committer/IT consultant that uses Camel everyday...
Related
May be this question broad and hard to answer at current moment
But,when i went through different frameworks emerging by one after another like
Hadoop Distributed File System
HBase,
Hive,
Cassandra,
Hypertable,
Amazon S3,
BigTable,
DynamoDB,
MongoDB,
Redis,
Riak,
Neo4J,
Stripes,
Wicket,
Compojure,
Conjure,
Grails,
JRoR,
JSF,
Lift,
Netty,
Noir,
Play,
Scalatra,
Seam,
Sitemesh,
Spark,
Spring MVC,
Stripes,
Struts,
Tapestry,
VRaptor,
Vert.x,
Stripes,
Tapestry
OpenXava
It is always buzzing me.
Each framework has some unique features.Each one promises to solve some particular testing,development and production need with respect to increasing no of users ,data expansion,distributed computing and security ,performance and many more .
But,many functionality is common on them .Striving for unique some functionality we have to shift from one framework to another As,a java developer i would like to have following features included in one framework
like
Out of box support for testing for unit and integration testing
Fast prototyping
Distributed multithreading,caching,logging ,session management ,moduaralization
Security extension
Framework extension
Easily integration with big data .
Distributed data computation
Asychronous operation
High performance
I would like to know what other features others really want to have in one framework ?What others developer really want to have features included in one framework .What are the necessary and essential featues that every framework must include .Please share yours idea.
The reason they differ is because there is no consensus on these matters. Depending on your background and expertise the answer will be different. Every project was started knowing full well what the alternatives were and not being content with them.
This question is useless I'm afraid.
I think XKCD describes it well (replace standard with framework):
There is simply no way given an enough complex problem to solve it for all use cases and users.
The key to understanding is not in how much common is there about all those frameworks but in that most of them cover only part of needs. For instance, Hadoop and Stripes do nothing in common. Only few frameworks claim they cover everything (Java EE and Spring in fact) but in reality they just try to collect several unrelated technologies under one brand name.
The real domains are: presentation layer, data access layer and (arguably) something else.
I'm trying to wrap my brain around JMS and have been reading up on some very helpful sources and examples. I'm now trying to see the "big picture" here and put all the theory behind JMS into a practical context where real enterprise technologies are used.
So here we have four elements: (1) JMS - a Java API for MOM, (2) ActiveMQ - one of the many JMS implementations, (3) EIP - an intriguing and mysterious beast I am only beginning to understand, and finally, (4) Apache Camel, an open source implementation of that beast.
I am trying to now relate these components together to see JMS (and, in general, enterprise-class messaging) in action.
I guess the first thing I'm looking for is a simple and concise definition for what EIPs are. They seem to be a whole set of design patterns for how MOMs should behave, but since I'm already fuzzy on the concept of messaging to begin with, this is just a fuzzier definition being added on top of an already-fuzzy understanding of some pretty hardcore concepts.
Even if I don't "get" what EIPs are, I do "get" that frameworks like Camel, Mule and ServiceMix implement them and allow server-side components ("endpoints") to message each other efficiently.
Most important to this question is my understanding of how these four components relate to one another. I think understanding this will help me connect most of the dots; well, the important ones anyway.
So in the diagram above I labeled all 6 possible relationships and refer to them below:
JMS:ActiveMQ - I understand ActiveMQ to be an implementation of JMS, much like Hibernate is an implementation of JPA. Is this correct?
ActiveMQ:Camel - Camel has the ability to push messages to any JMS implementation, such as ActiveMQ. In this case ActiveMQ is a camel endpoint. Correct?
EIP:Camel - Camel is an implementation of EIPs. Understanding what EIPs are in the first place is also important to my understanding of this entire setup.
EIP:JMS - Although there may not be a direct connection between these two, it seems as though messaging is at the core of EIP, and JMS is Java's foundation for messaging. Is this a fair assessment?
I left relations between EIP:ActiveMQ and JMS:Camel in case there are any "big concepts" that I should be aware of between these systems.
Any help in putting a simple-to-understand definition to EIP and in understanding how all these components relate to each other is greatly appreciated. Thanks in advance!
ActiveMQ is an implementation of a MOM. It provides a client-side implementation of the JMS API for use by JVM languages. JMS is just an API, but implementations are tied to whatever broker they talk to by a wire format, so you can't use the ActiveMQ JMS implementation to talk to WebsphereMQ, for example. There exist other APIs to talk to ActiveMQ from other language platforms - C/C++ via CMS, .Net via NMS. You can also talk to ActiveMQ via other "non-JMS-like" mechanisms, such as via the STOMP protocol which has client libraries in Ruby, Javascript and others.
Yes.
Yes and no. Camel uses the same "language" as EIPs, so by using Camel, you naturally pick up the EIPs. Having said that, knowing them lets you know what you are looking for in the API. I recommend Camel in Action to get a good understanding of the two, and refer to the EIP site (http://www.eaipatterns.com/) when you want to get a bit more info.
Again yes and no. There are a number of patterns implemented via messaging (JMS is only one flavour), but there are a large number of patterns that have a much broader application (e.g. Splitter, Aggregator). Have a look through the EIP site index to get a feel for this.
Camel can talk to other systems using it's JMS component, which uses any underlying messaging provider that supports that API (Websphere, Sonic, OpenMQ etc.). It can also talk over other messaging technologies, such as those that support the AMQP API.
Hope that helps.
I need to write integrations to multiple external web services. Some of them are SOAP (have WSDL), some of them pretty much ad hoc - HTTP(s), authentication either by basic auth or parameters in URL (!), natural-language like XML which does not really map nicely to domain classes..
For now, I've done the spike integrations using Spring Web 3.0 RestTemplate and binding using JAXB2 (Jaxb2Marshaller). Some kind of binding is needed because domain classes need to be cleaner than the XML.
It works, but it kind of feels bad. Obviously this partially just because how the services are built. And one minor issue I have is naming of RestTemplate as services have nothing to do with REST. This I can live with. JAXB2 feels a bit heavy though.
So, I'm looking for some other alternatives. Ideas? I'd like to have a simple solution (so RestTemplate is fine), not too enterprisey..
While some of your services may be schemaless XML, they will still probably have a well-documented API. One of the techniques that the Spring folks seem to be pushing, at least from the web-service server side, is to use XPath/XQuery for retrieving only the information you really need from a request. I know that this may only end up being part of your solution, but I'm not sure that this is a situation where one particular binding framework is going to meet all your needs.
If I understand correctly you have 1 application that has to make calls to various external (web) services by use of different technologies. The first thing that comes to mind is to have some intermediate level. While this could be something as elaborate as en ESB-solution, my guess is that is not what you're looking for.
You could for example achieve this intermediate level by having a class hierarchy with at its top an interface 'Consumer'. Method to be implemented: doConsume() and so on.
If you look into it you'll probably have the opportunity to make use of several design patterns like Strategy or Template. Remember to be pro-active and try to ask a few times 'What if ..' (As in: what if they need me to consume yet another service? etc.)
If JAXB feels too heavy there are other API's to be found:
Axis
JAX-WS
CXF
other
It'll depend on the situation which one would be better. If you run into troubles with any of them I'm sure you'll be able to find help here on SO (and from people who have more hands-on experience with them than me ;-)
I have several Camel contexts in my project and i would like to document the routes if possible in a reverse engineering fashion since we want to keep the documentation up to date related to the context. what would be the best approach?
We tend to actually design the routes up front and model them using the iconography from the EIP book. That gives us a guide to then test drive our routes. Are your routes changing really often that reverse engineering is required? We are slowly looking at building a dynamic UI for our routes - but that won't be until will into 2011 :)
You can just add documentation in the actual DSL and then have some tooling or whatever that extracts that route and documentation.
In the Spring XML DSL you ought to be able to add elements to the EIPs in the route. Also you can also add general XML comments as well.
Also as mentioned above some GUI tooling is also what some people want to use. Then often the visual diagram of the routes using the EIP icons is the documentation.
FuseSource is current building a GUI tool called FuseSource Rider. It will be in public beta later this month.
At Apache Camel there is some maven tooling for generating gui diagrams
http://camel.apache.org/visualisation.html
I have just started to work on a Java Based CMS and I am trying to figure out how would my application architecture look like.
To elaborate a bit, I have developed Java EE applications using Hibernate ans Spring and I am now used to thinking in terms of a
Presentation Layer --> Business Layer --> Database Access Layer --> Database
When I look at the CMS, I try to relate this to the Application Architecture of the conventional Web Based Application. I also try to figure out where would Hibernate and Spring integrate into it or would this integration be supported?
In simpler terms, I am unable to perceive a General Architecture of an Application based on a CMS.
Have I made myself clear?
Any Help/Hints/Pointers?
I've never found an elegant solution to this; app builds I've done seem to sit better alongside rather than within CMS-managed content, using similar but copied HTML/JSP templates. Any presentation layer reuse you can get is a bonus!
One particular issue is version control of app source code and DB structure/data, which is obviously A Good Thing. Other site content may not sit within source control (SVN, etc) and you sure as hell don't want to take that risk with your app...
Having said all this, it's perhaps worth making a feature of such separation rather than apologising for it. Base your architecture around it prominently and design for a clean integration.
Here's an explanation of how you can integrate Spring and Hippo CMS (apache licensed Java CMS): http://www.gridshore.nl/2008/07/06/integrate-hippo-cms-into-a-spring-application/.
The architecture of Hippo CMS is explained here: http://www.onehippo.org/about/architecture
Disclaimer: I work for Hippo and this is based on my own experience. There's a big chance there are more solutions out there than the one I'm describing.
you can see this,
Magnolia CMS
Presentation Layer --> Business Layer --> Database Access Layer --> Database looks like a fairly reasonable layering to me. The question this immediately raises is why you have doubts about this. I'd tackle the problem from a different perspective (that usuall helps to shake the brain-cells into action!).
What kind of CMS are you building? In what way does it differ from the many other CMS's? Is there anything about your "unique selling point" that would influence the architecture to be non-standard in some way (if I can put it like that)?