We have this Java codebase that has a good amount of business rules written in Drools. I have been tasked with designing and recommending and alternative cloud-based rules engine, so that other services and applications within the company can utilize it too. Here is the high level plan:
Perform a "Lift and shift" by decoupling the rule execution from the java code base
Create a containerized rules service that takes in an input via HTTP or a message queue and returns output, or perform some actions (Send notifications, queue something, etc)
Host it on Azure or GCP
I'm trying to create a baby POC. I need some help with some of the implementation details. For example, would creating a .NET REST endpoint and then passing in the data to the drools Java container be a feasible idea? Or would it be simpler to just create simple Java REST endpoint that uses Drools behind the scenes?
Any tips or examples of this would be highly appreciated, as I don't want to re-invent the wheel!
Drools has a native build in REST web service that can be embedded in Java Containers (JBoss, Tomcat).
This framework is the KIE Server and can be activated to host build in Drools Process/Rules.
https://docs.jboss.org/drools/release/7.69.0.Final/drools-docs/html_single/#_ch.kie.server
There are some docker images that contains default KIE Server that you can use and deploy your rules to.
Ex : https://hub.docker.com/r/jboss/kie-server/
Hope this helps,
Best,
Emmanuel
Or would it be simpler to just create simple Java REST endpoint that uses Drools behind the scenes?
You might want to consider using Kogito for your DRL rules, instead of having to deploy a containerised Kie Server.
Then, to have a Docker image generated easily with Kogito-on-Quarkus, it's enough to add the Quarkus' JIB extension to your Kogito-on-Quarkus app.
Related
I created a simple two-player game (Connect 4) with a Java/Spring backend and React.js frontend. I understand it would be simpler to create the entire app in React, but I’m studying Java development and decided to learn React to demonstrate my understanding and create a portfolio website.
I’m struggling to decide how best to deploy the app. I deployed the backend on its own to GC App Engine. After a few false starts it eventually worked. However, if I visit the project url from two separate browsers/devices, both devices are looking at the same instance of the backend, i.e. two individual users are looking at the same ‘game’, which is not what I intended.
What is the best approach to deploy the front & backend so each user is playing their own individual game?
This is literally my first foray into any kind of web development, so I may have bitten off more than I can chew.
Thanks.
I would suggest you use multiple services on your project. You can either use the same deployment command for deploying or updating the services that make up your application.
services in App Engines behave like microservices and therefore you can deploy multiple services to run as a set of microservices.
Here are the requirements for deploying multiple services:
You must initially deploy a version of your application to the default service before you can create and deploy subsequent services.
The ID of each of your services must be specified in their corresponding app.yaml configuration files. To specify the service ID, include the service element definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to the default service.
You can deploy one service as frontend and the other as backend.
You can check this documentation on services for additional information.
I looked at the documentation regarding services but I still don’t understand their use in the context of my problem. I may have misunderstood your explanation, but I don’t think I explained my problem clearly. Having looked at the documentation, my use of the word ‘instance’ is not the same as an app engine instance.
It would make sense to me to have two services in my project; one for the backend and one for the frontend. To solve the problem of each individual player interacting with the same backend API, and so unwittingly interacting with the same single Connect4 game, generating multiple services would not be a solution. Is my understanding correct?
The comment from NoCommandLine on my original post is probably a better description of what I want to achieve.
We have 13 years old monolithic java application using
Struts 2 for handling UI calls
JDBC/Spring JDBC Template for db calls
Spring DI
Tiles/JSP/Jquery for UI
Two deployables are created out of this single source code.
WAR for online application
JAR for running back-end jobs
The current UI is pretty old. Our goal is to redesign the application using microservices. We have identified modules which can run as separate microservice.
We have following questions in our mind
Which UI framework should we go for (Angular/React or a home grown one). Angular seems to be very slow and we need better performance as far as page loading is concerned.
Should UI/Javascript make call to backend web services directly or should there be a spring controller proxy in deployed WAR which kind of forwards UI calls to APIs. This will also help if a single UI calls requires getting/updating data from different microservice.
How should we cover microservice security aspect
Which load balancer should we go for if we want to have multiple instance of same microservice.
Since its a banking application, our organization does not allow using Elastic Search/Lucene for searching. So need suggestion for reporting using Oracle alone.
How should we run backend jobs?
There will also be a main payment microservice which will create payments. Since payments volume is huge hence it will require multiple instances. How will we manage user logged-in session. Should we go for in-memory distributed session store (may be memcache)
This is a very broad question. You need to get a consultant architect to understand your application in depth, because it is unlikely you will get meaningful in-depth answers here.
However as a rough guideline here are some brief answers:
Which UI framework should we go for (Angular/React or a home grown one). Angular seems to be very slow and we need better performance as far as page loading is concerned.
That depends on what the application actually needs to do. Angular is one of the leading frameworks, and is usually not slow at all. You might be doing something wrong (are you doing too many granular calls? is your backend slow?). React is also a strong contender, but seems to be losing popularity, although that is just a subjective opinion and could be wrong. Angular is a more feature complete framework, while React is more of a combination of tools. You would be just crazy if you think you can do a home grown one and bring it to the same maturity of these ready made tools.
Should UI/Javascript make call to backend web services directly or
should there be a spring controller proxy in deployed WAR which kind
of forwards UI calls to APIs. This will also help if a single UI calls
requires getting/updating data from different microservice.
A lot of larger microservice architectures often involve an API gateway. Then again it depends on your use case. You might also have an issue with CORS, so centralising calls through a proxy / API gateway, even if it is a simple reverse proxy (you don't need to develop it) might be a good idea.
How should we cover microservice security aspect.
Again no idea what your setup looks like. JWT is a common approach. I presume the authentication process itself uses some centralised LDAP / Exchange or similar process. Once you authenticate you can sign a token which you give to the client, which is then passed to the respective micro services in the HTTP authorization headers.
Which load balancer should we go for if we want to have multiple
instance of same microservice.
Depends on what you want. Are you deploying on a cloud based solution like AWS (in which case load balancing is provided by the infrastructure)? Are you going to deploy on a Kubernetes setup where load balancing and scaling is handled as part of its deployment fabric? Do you want client-side load balancing (comes part of Spring Cloud)?
Since its a banking application, our organization does not allow using
Elastic Search/Lucene for searching. So need suggestion for reporting
using Oracle alone.
Without knowledge of how the data on Oracle looks like and what the reporting requirements are, all solutions are possible.
How should we run backend jobs?
Depends on the infrastructure you choose. Everything is possible, from simple cron jobs, to cloud scheduling services, or integrated Java scheduling mechanisms like Quartz.
There will also be a main payment microservice which will create
payments. Since payments volume is huge hence it will require
multiple instances. How will we manage user logged-in session. Should
we go for in-memory distributed session store (may be memcache)
Not really. It will defeat the whole purpose of microservices. JWT tokens will be managed by the client's browser and expire automatically. You don't need to manage user logged-in session in such architectures.
As you have mentioned it's a banking site so security will be first priory. Here I have few suggestions for FE and BE.
FE : You better go with preactjs it's a react like library but much lighter and fast as compare to react. For ui you can go with styled components instead of using some heavy third party lib. This will also enhance performance and obviously CDNs for images and big files.
BE : As per your need you better go with hybrid solution node could be a good option.e.g. for sessions.
Setup an auth server and get you services validate user from there and it will be used in future for any kinda service .e.g. you will expose some kinda client API's.
User case for Auth : you can use redis for session info get user validated from auth server and add info to redis later check if user is logged in from redis this will reduce load from auth server. (I have used same strategy for a crypto exchange and went pretty well)
Load balancer : Don't have good familiarity with java but for node JS PM2 will do that for you not a big deal just one command and it will start multiple instances and will balance on it's own.
In case you have enormous traffic then you better go with some messaging service like rabbitmq this will reduce cost of servers by preventing you from scaling your servers.
BE Jobs : I have done that with node for extensive tasks and went quite well there you can use forking or spanning this will start a new instance for particular job and will be killed after completing it and you can easily generate logs along with that.
For further clarification I'm here :)
I have created .NET web services. I want to run it on a remote server and have the Java Applications (clients) contact the server for data. How should I implement the Server such that the Clients can make use of the org.apache.xmlrpc.client.XmlRpcClient package?
I just want the clients to generate a request for data and does not want to have any other dependencies.
Here is a good material on using eclipse for this purpose: http://wso2.org/library/tutorials/creating-web-service-client-3-steps-using-eclipse
Thanks.
Although both are rightfully called "web services" the SOAP based web services usually created in .net are incompatible with web services following the older XML-RPC standard.
In my opinion you can follow 2 routes to solve your problem:
either you go the SOAP route under Java, one of the most common API's for that purpose would be jax-ws - some excellent pointers to tutorials here, in Pascal Thivent's answer
or you transform your .net webservices to XMl-RPC by using xml-rpc.net
Both routes have advantages and disadvantages, it's hard to make that choice for you without knowing more about your project. A priori choosing the SOAP route might look "safer" as there the entire communication will be based on standard components.
If you have the Web Services on the .NET side, you must have a Web Service Description Language (WSDL) (if you are not talking about REST), you can easily create the client classes to consume this Web Service using an IDE, check this link here: http://netbeans.org/kb/docs/websvc/client.html
If you are using Eclipse I suggest you this tutorial to build a simple WS client.
You can adapt this example application to your real needs.
NOTE the example uses an old version of Eclipse, but the wizard is very similar also in newer versions.
Just looking for confirmation that the GWT RPCs play well with app-engine's new multi-tenancy support based on name-spaces.
The two technologies are very compatiable. I have been using them together for a long time. In fact there are some syntatic sugar that makes them easy to be used together, such are RPC calls. Plus now your server and client code are in the same language. Using eclipse and the setup that google developed for eclipse and GWT/AppEngine I have all the code in one project with a client, server and shared code. The client and Shared code gets compiled with GWT and the server and shared code get compiled for AppEngine.
I hope this helps.
https://developers.google.com/web-toolkit/doc/1.6/tutorial/appengine
Michael
You can try to use multi-tenancy in your GWT-RPC, but it will not be just configuration. You can use per-user multi-tenancy setting NameSpace using filter, but do not forget that if you start AsyncTasks from gwt-rpc calls you will not have valid user in tasks requests so you will need to figure out how to choose namespace in tasks.
As long as your server-side implementations correctly handle the multi-tenancy, you'll be fine.
There is no additional load to using multi-tenancy with GWT-RPC, but there is additional load using multi-tenancy and you won't be able to avoid that with GWT-RPC.
I am working on a desktop Java application that is supposed to connect to an Oracle database via a proxy which can be a Servlet or an EJB or something else that you can suggest.
My question is that what architecture should be used?
Simple Servlets as proxy between client and database, that connects to the database and sends results back to the client.
An enterprise application with EJBs and remote interfaces to access the database
Any other options that I haven't thought of.
Thanks
Depending on how scalable you want the solution to be, you can make a choice.
EJB (3) can make a good choice but then you need a full blown app server.
You can connect directly using jdbc but that will expose url of db (expose as in every client desktop app will make a connection to the DB. you can not pool, and lose lot of flexibilities). I would not recommend going this path unless your app is really a simple one.
You can create a servlet to act as proxy but its tedious and not as scalable. You will have to write lot of code at both ends
What i would recommend is creating a REST based service that performs desired operations on the DB and consume this in your desktop app.
Start off simple. I would begin with a simple servlet/JDBC-based solution and get the system working end-to-end. From that point, consider:
do you want to make use of conenction pooling (most likely). Consider C3P0 / Apache DBCP
do you want to embrace a framework like Spring ? You can migrate to this gradually, and start with using the servlet MVC capabilities, IoC etc. and use more complex solutions as you require
Do you want to use an ORM ? Do you have complex object graphs that you're persisting/querying, and will an ORM simplify your development ?
If you do decide to take this approach, make sure your architecture is well-layered, so you can swap out (say) raw JDBC in favour of an ORM, and that your development is test-driven, such that you have sufficient test cases to confirm that your solution works whilst you're performing the above migrations.
Note that you may never finalise on a solution. As your requirements change, and your application scales, you'll likely want to swap in/out the technology most suitable for your current requirements. Consequently the architecture of your app is more important than the particular toolset that you choose.
Direct usage of JDBC through some ORM (Hibernate for example) ?
If you're developing a stand-alone application, better keep it simple. In order to use ORM or other frameworks you don't need a J2EE App Server (and all the complexity it takes with it).
If you need to exchange huge amounts of data between the DB and the application, just forget about EJBs, Servlets and Web Services, and just go with Hibernate (or directly with plain old JDBC).
A REST based Web Services solution may be good, as long as you don't have complex data, and high numbers (try to profile how long does it takes to actually unmarshal SOAP messages back and to java objects).
I have had a great deal of success with using Spring-remoting and a servlet based approach. This is a great setup for development as well, since you can easily test your code without deploying to an web container.
You start by defining a service interface to retrieve/store your data (POJO's).
Create the implementation, which can use ORM, straight JDBC or some pooling library (container provided or 3rd party). This is irrelevant to the remote deployment.
Develop your application which uses this service directly (no deployment to a server).
When you are satisfied with everything, wrap your implementation in a war and deploy with the Spring DispatcherServlet. If you use maven, it can be done via the war plugin
Configure the desktop to use the service via Spring remoting.
I have found the ability to easily develop the code by running the service as part of the application to be a huge advantage over developing/debugging something running on a server. I have used this approach both with and without an EJB, although the EJB was still accessed via the servlet in our particular case. Only service to service calls used the EJB directly (also using Spring remoting).