Hi there I would like to build an integration test framework that supports testing soap services mq Kafka and rest services - can someone say if citrus framework would be a better choice ? And some p tutorial to refer at ?
Thanks
Citrus already covers all of those features mentioned so I would suggest to have a look and try before heading to something else or implement it yourself.
The framework is Open Source so you can also contribute to it and enhance where you feel it is necessary.
I often give reference to the samples section where you find running samples of all features you have mentioned.
https://citrusframework.org/samples/
Related
I have a CQRS/Eventsourcing architecture with 3 microservices. I implemented 2 microservices with vert.x 4 and I implemented CQRS/Eventsourcing without framework to improve my knowledge of this type of architecture. For the third microservice I would like to use AxonIq Framework but I have a problem with Aggregate annotation because it's not avalaible with vert.x but only with Spring.
I implemented a Spring microservice using Axon and everything work fine but I would like to know if someone can help me for use vert.x with AxonIq ? If anyone know a workaround for this problem ?
Thank
Axon Farmework provide something called Configuration API. You can have a look at the Configuration class but for making use of it, you need a Configurer, which will provide you all means of configuring your components!
On the ref-guide, you also have several examples of how to do the configuration using the API or Srring Boot. Example for Commands can be found here.
To help a bit more, I can also share a small project I made using Dropwizard and Axon Framework, meaning no Spring was used and all the Configuration was done through the API.
You can find it here https://github.com/lfgcampos/axon-playground/tree/master/chat-getting-started-dropwizard
I have an application written in Scala/Akka and trying to add SOAP support. Anyone did it with Alpakka? Or what is the best way to do it. So far I think Camel is the best solution.
Currently, Alpakka does not support SOAP, but there is an open ticket. Your best bet is probably to use Camel integration in your Scala/Akka project. To that end, take a look at the streamz project or the Camel integration module in Akka (the latter is deprecated but may serve your needs).
There is also a library that provides some SOAP integration with Play.
I like the TDD approach to documenting your restful api with spring-rest-docs. However, I love "API Playground" feature enabled by swagger specification. I wish there was a way to get best of both worlds.
Is there a way to build swagger2 specs from spring rest docs? may be via building custom request/response preprocessors.
Do you have any thoughts or recommendations?
There's not out-of-the-box support for this in Spring REST Docs at the moment. The issue that you opened will track the possibility of adding such functionality. In the meantime, your best bet would be to look at writing a custom Snippet implementation that generates (part of) a Swagger specification.
Typically, a Spring REST Docs snippet deals with documentating a single resource, whereas a Swagger specification describes an entire service. This means that the Swagger specification Snippet implementation will need to accumulate state somehow, before producing a complete specification at the end. There are lots of ways to do that (in memory, multiple files that are combined in a post-processing step, etc.). It's not clear to me that one approach is obviously the right one so some experimentation would be useful. If you do some experimentation, please comment on the issue that you opened with your findings.
Spring REST Docs was released recently and the documentation says:
This approach frees you from the limitations imposed by tools like Swagger
So, I wanted to ask when Spring REST Docs is preferable to use comparing to Swagger and which limitations it frees.
I just saw a presentation here that touches on your question among other topics:
https://www.youtube.com/watch?v=k5ncCJBarRI&t=26m58s
Swagger doesn't support hypermedia at all / it's URI centric
Swagger's method of inspecting your code can lag behind your code. It's possible make a change in your code that Swagger fails to understand and won't process properly until Swagger gets updated.
Swagger requires lot of annotation, and it's painful to include the descriptive text you want in an api document in annotations.
There are just some things that Swagger can't figure out from inspecting your code.
In any case, these are just a couple of points. The presenter does a much better job discussing it than I could.
I thought I would chime in to give a little bit more context surrounding Swagger, what it is, and what it is not. I believe this might help answer your question.
Swagger 2.0 is being adopted by a lot of big names and big platforms like Microsoft Azure, Paypal, SwaggerHub.com, DynamicApis.com, etc... Something to keep in mind is that Swagger is very simply a specification. It is not a framework. There are a lot of frameworks out there built to generate Swagger output that crawl through your code looking at your API information in order to build the Swagger 2.0 JSON file that represents your API. The Swagger UI that you see your APIs on is driven directly from this Swagger 2.0 JSON file. fiddler it to check it out
It is important to note that a framework that was created to allow you to "use swagger" is not how Swagger has to work (i.e. it is completely up to the implementation of the 3rd party framework). If the framework you are using to generate your Swagger 2.0 documents and UI is not working for you then you should be able to go find another framework that generates the Swagger artifacts and swap the technologies out.
Hope this helps.
From Spring REST docs:
The aim of Spring REST Docs is to help you to produce documentation for your RESTful services that is accurate and readable
This test-driven approach helps to guarantee the accuracy of your service’s documentation. If a snippet is incorrect the test that produces it will fail.
Spring REST docs advantages:
Documentation is written in the test code so it does not overload main code with lots of annotations and descriptions
Generated docs and examples are accurate because related test must pass
Docs can provide more specific and descriptive snippets
Format is suitable for publishing
Spring REST docs disadvantages:
Requires more work
Documentation provides request/response examples but don't provide interactive tools to modify and try out requests
Swagger advantages:
Quick, automated generation from a code
Interactive request execution - can be used for acceptance testing
Built around the OpenAPI Specification
Swagger disadvantages:
For more descriptive documentation it will require a lot of annotations
Tests are not related to the documentation so sometimes documention may deviate from reality
There is some limitation with swagger and the specific spring stack.
For example : with "param" in your Request Mapping you can define more than one method with the same url ans so simplify your code.
But swagger show you just one method
One disadvantage with Swagger is: it cannot handle models which have cyclical dependencies. If a model has cyclical dependency and if swagger is enabled, then spring boot server crashes.
I've just started on a small project to create some REST services using Google App Engine and Java. I'm new to both technologies, but I've done some reading on both. I'm familiar with SOAP (have used them previously), and I think I understand the conceptual differences between REST and SOAP.
Currently I need info regarding two things:
1) I'm trying to find some tutorial which builds a simple REST service from scratch for deploying on Google App Engine (GAE). The simpler the better, but it should have at least a few routing options. I don't need any UI, if that matters.
2) Which RESTful Framework should I use with Google App Engine. Again, simplicity is what I'd like, and something which has tutorials and a newcomer can easily grasp.
My ultimate goal is to just write a REST wrapper with multiple routing options, which eventual consumes some pre-existing SOAP services and returns their results.
Have you checked out Google Cloud Endpoints for creating a REST service? Its pretty simple and straightforward, also has support for OAuth.
I would give Jello framework a try. It offers a clean, and simple to follow, JSON format and provides a very powerful and comprehensive RESTful implementation that follows the OData specification.
Here is Jello's REST development guide: http://jello-framework.com/guide/rest.html