I have to applications running on a single Wildfly container using single database. Currently they are communicated with each other using JAX-RS and I wonder is there more faster way?
What I have already found:
JAX-RS
Local EJB
Remote EJB
JMS
Seems that the most fastest way is to use Local EJB. But I am not sure about JMS. And what about Websockets?
Ok, one could complain about the question being too broad formulated but providing one possible answer would also be nice ;)
So here is my suggestion:
Simply create a clean API for the communication between the modules and deploy it as a JAR to your server. The module that contains the JAX-RS endpoint could also implement the API to provide the services you need (not only for internal usage but also for your REST service which then would simply delegate the request processing). Now you can simply inject a service using CDI when you need it for internal usage and as far as I know this is the fastest possible way to go for internal communication since it works directly with JAVA objects. Using CDI for the injection of the service implementation has also the benefit of decoupling the modules.
I hope this helps ;)
Have you looked at memory-mapped files? They can offer some very high throughput. Check out the NIO FileChannel class. For a ready-to-run solution, take a look at Jocket.
Related
I'm working on a microservice project, and I have a question about best practices.
We are using Java Spring, and all of our models are packaged in a single JAR. Each microservice depends on this JAR to function. Is it okay for a microservice to depend on a JAR containing models outside of its scope like this, or is it better practice to split this JAR up?
A very good article by Bartosz Jedrzejewski here
To quote a relevant part from his artcile...
If the service code should be completely separate, but we need to consume possibly complicated responses in the clients- clients should write their own libraries for consuming the service.
By using client-libraries for consuming the service the following benefits are achieved:
Service is fully decoupled from the clients and no services depend on one another- the library is separate and client specific. It can be even technology specific if we have mix of technologies
Releasing new version of the service is not coupled with clients- they may not even need to know if the backward compatibility is still there, it is the clients who maintain the library
The clients are now DRY - no needless code is copy pasted
It is quicker to integrate with the service - this is achieved without losing any of the microservices benefits
This solution is not something entirely new- it was successfully implemented in Scott Logic projects, is recommended in the “Building Microservices” by Sam Newman (highly recommended) and similar ideas can be seen in many successful microservices architectures.
There are some pitfalls as well, better read the entire article...
Sharing the domain models is an indicator of bad design. If services share a domain, they should not be split. For Microservices, teams working on one service should be able to modify their domain objects anytime without impacting other services/teams.
There can be done exceptions though, e.g. if the model objects are non-specific enough to be reusable in any service. As an example a domain of geometry could be contained in a geometry library. There can be other exceptions.
I have a microservice which is responsible for giving cached data over the rest end points. I have 2 big projects which need this microservice.
My confusion is, if i should use restTemplates to call the rest end points or use the client jar for the microservice in my big project.
If i use rest template I will need to add the pojos for request and response etc. My senior developer is insisting on using rest template but I don't quite like that approach.
Can someone suggest.
In order to facilitate usage of client rest calls, especially when more than one projects are involved, it is best practice to design a client wrapper that calls your desired endpoint as:
SystemApiClient client = new SystemApiClient();
List<Article> articles = client.getArticles("popular");
by designing such client wrapper, it's easy to make a jar file out of it and share it across you microservices. for ease of update you can also upload each new version on local nexus and easily get update on your project when a new one is available
It depends.
If you are using Spring in your whole project then you should go for RestTemplate. Just for calling the endpoint no need to pull another jar. Many times senior people / architect suggest to use unique libraries to maintain application standard and to avoid whole bunch of library offering similar functionalities.
Or if your application is developed in another framework or language you can use any HttpRequest supporting library. It doesn't matter what client side code you are using to access Rest endpoint.
It's always preferable to have services called through rest end-points in service based architectures such as Micro-Services. But again the big question is what should you use - JAR or WAR. That highly depends upon type of projects and their architecture. In this case, it is MicroServices, Uncle Bob beautifully describes here - http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html
In a project I have different processors for each request message that each of these processors can be enabled or disabled based on the configuration. I have two options, one is to use the jar library of each of these processors in my applications and use its classes and the other option is to make each of the processors like a standalone web api that get and return json objects and in this way the communication between these processors would be based on web api instead of using jar libraries.
Which of these options do you think is better and what I need to consider when making such a decision.
Thank you
Depends on what the service is, but overall...
Using the jar will save you network hops between your client and the new service
Conversely, if the jar is taking up a lot of your resources, it might be more performant to have it as a separate service on a different machine
jar file is easily manageable as a project dependency, whereas api service will likely involve a more involved release process
if you manage the jar file, you are probably prone to tighter coupling of code since you are in control of it. having an api somewhat pushes you in direction of writing somewhat cleaner code
I think it really comes down to what your jar is doing and what makes most sense with the service you've packaged in its own jar.
At work, we currently have a WSDL interface as well as a semi-RESTful interface that we're looking to expand upon and take it to the next level.
The main application runs using Servlets + JSPs as well as Spring.
The idea is that the REST and WSDL are interfaces for an API that will be designed. These (and potentially other things in future) are simply a method through which clients will be able to integrate with the interface.
I'm wondering if there are any suggestions or recommendations on frameworks / methodologies, etc for implementing that under-lying API or does it make sense simply to create some Spring beans which is called either by WSDL or REST?
Hope that makes sense.
Have a look at Eunicate it is great . You are using spring , Spring has had support of SOAP for a while and Spring 3 has support of REST (Creating and Consuming).
Your approach makes sense. Probably the most important advice is to make the external API layer as thin as possible. You can use Axis, Apache CXF, Jersey, etc. to handle the implementation of the REST or SOAP protocols, but the implementation of those services should just load the passed in data into a common request object, and pass that into a separate service that handles the request and returns a response object which the external API layer will marshall into the correct format for you.
This approach works especially well when you have a competitor providing similar services and you want to make it easy for their customers to switch. You just build a new external API that mirrors the competitors, and simply translates their format to your internal api model and provided your services are functionally equivalent, you're done.
This is a really late response, but I have a different view on this topic. The traditional way as we know it is to unmarshall xml to java and marshall java to xml. However if the wsdl changes then it would effectively be a structural change in the code which would again require a deployment.
Instead of the above approach if we list the fields mentioned in the wsdl in a presistent store, load the mappings in memory and prepare our structures based on these mappings we would have to have many less changes for this..Thus IMO instead of using existing libraries a configurable approach to unmarshalling and marshalling should be taken.
I am looking for something very close to an application server with these features:
it should handle a series of threads/daemons, allowing the user to start-stop-reload each one without affecting the others
it should keep libraries separated between different threads/daemons
it should allow to share some libraries
Currently we have some legacy code reinventing the wheel... and not a perflectly round-shaped one at that!
I thought to use Tomcat, but I don't need a web server, except maybe for the simple backoffice user interface (/manager/html).
Any suggestion? Is there a non-web application server, or is there a better alternative to Tomcat (more lightweight, for example, or easier to configure)? Thanks in advance.
Have you looked at OSGi ? You can load/unload bundles (basically .jar files with metadata) independently of each other, and optionally define dependencies between these (with a software lifecycle defined such that bundles are aware of other bundles being loaded/unloaded).
I have found the Jetty "contexts" concept very useful in handling applications (packaged as WAR's and with servlet context listeners), where the xml-file placed in contexts/ describe fully what you want to have started. When you remove the xml-file again, the thing described is stopped.
If you do not start a server connector you will just have a start-stop thing which sounds like what you are looking for.
Jetty can be made very small so the overhead is not bad.
You could consider Spring dmServer. It's a rather non-traditional appserver, with a very lightweight OSGi core (the web container is optional, for example), but it gives you classloader isolation and basic container services. It's not a JavaEE container, but comes with plug-in modules that are.
You're stlll going to have to do a lot of work yourself, but the basics of dmServer are very sound.
No one stops you from sending binary and text data instead of HTML-pages using http protocol. That is whats servlets are for. So I would use the tomcat server.