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
Related
As a developer, I prefer spring restdocs. But as a consumer of the documentation, I find the swagger live documentation to be very compelling. Here's the ubiquitous example: http://petstore.swagger.io/
Is there a way to document my rest apis with spring restdocs but generate live documentation like the swagger petstore with it? If so, how do you do this?
No, it's not possible out of the box. REST Docs is intended to be extensible so you could add the functionality yourself but it would be a significant undertaking.
I'm the lead of the REST Docs project and support for live documentation is of interest, but it's not a particularly high priority at the moment. In my experience, live documentation can be useful as a playground but does a poor job of actually documenting a service. My focus at the moment is on producing accurate and well-structured documentation. Using REST Docs with Slate can give you a big jumpstart on the latter if you're looking for something more guiding than Asciidoctor's blank canvas.
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 am software written in Java which read an external XML file (let's call it "datasource.xml").
This file contains different information and this information are extracted using XPath queries.
The fact is that, according to what kind of information is extracted from that file (datasource.xml) a different work flow is needed. At the moment workflows are "hard coded" in my Java classes but I want to make my software indipedent so that it can work with any datasource.xml, no matter of its structure. But of course I have to specify somewhere how to deal with the extracted data. I was thinking to use (again) JAXB and specify inside the XML file (and from its XSD I will create JAXB classes) the kind of workflow is needed.
Could it be a good solution??
Thanks
have you checked out Drools (a project from JBoss) very easy to learn & is an excellent workflow tool.
building your own workflow engine is quite complex & there are a lot of considerations to be taken into account.
You can think of using activiti, Another workflow solution. It has APIs available and can be used as a workflow service layer in your application.
Like others, I think you will be better off using a higher-level tool for this rather than hand-coding the logic in Java. Take a look at XProc (for example the Calabash implementation), or Orbeon, or Cocoon. They all have a learning curve associated with them, but once mastered, you will have a much more flexible architecture than with hard-coded Java logic.
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...
We are removing our XSL-> HTML solution annd replacing it with a Flex UI for our userbase. One of the concerns is that the BlazeDS (amf endpoint, so streaming or polling) won't be able to handle the load as well as the EJB -> XML -> XSLT -> HTML stack. My theory is that it should perform better, but I need a way to statistically prove this.
Are there any suggestions for a product and/or method for stress-testing BlazeDS? Adobe has a stress test framework for LCDS, but it says it is not compatible with BlazeDS. I think that it might be simple to test given that I am not planning on using it as a messeging solution right now, and simple want it as an endpoint for RemoteObject connections.
I would look at using JMeter to run some automated tests against the backend:
http://jmeter.apache.org/
You should be able to write a test against the backend which takes some Java objects and uses the API available in Blaze to encode them in AMF and set the result as the body of the HTTP request.
Rob de Boer has a good article on implementing such an approach here http://blog.jteam.nl/2009/07/14/performance-testing-a-flex-blazeds-application/
To expand upon Cliff's answer, there is now a JMeter plugin for handling AMF messages. It will deserialize the message to XML so that it can be edited. You can use variables to generate unique session ids that are inserted into each AMF sample.
http://github.com/steeltomato/jmeter-amf
Full disclosure: I am the project author.
Several frameworks come to mind:
jmeter
perf4j
TPTP.
, but I need a way to statistically prove this.
Hm, if you want really expressive statistics (e.g. besides average, max, min also standard deviation, or even 95% confidence interval or serial correlation), you'll have to take a close look at the tools, since most of them are weak on statistics.
Hopefully this list explaining the strength and weakness of several performance testing tools can help you.
My Company (UBIK-INGENIERIE) distributes a commercial Apache JMeter plugin to load test AMF based applications and by extension BlazeDS ones.
You can easily record, variabilize and replay Flex/AMF based application with standard knowledge of Apache JMeter.
See:
http://www.ubik-ingenierie.com/-Solutions-
http://www.ubik-ingenierie.com/blog/ubik-load-pack/