We have a Java/Spring/Hibernate codebase which is the core to our pretty large platform. We also have quite a few separate Java webapps (Struts or Spring MVC) running alongside which reference the core system, pulling in the applicationContext and services from it.
We have a requirement to build another webapp that also references the same core system, so I was hoping to do this with Grails. From what I've found it appears you can easily jar up legacy Java code, place it in your Grails project lib directory and reference it that way.
http://www.itexto.net/devkico/?p=333
Unfortunately this will not work for me as I need to reference the running core system and its services from my Grails app, as you would reference a Java app from another Java app. Is there any way to do this or is it just not possible with Grails?
Any information would really help...
Thanks,
Justin.
I would look into building a Service Layer on top of your Spring services/beans. This is a pattern documented in Martin Fowler's Patterns of Enterprise Application Architecture book. Essentially you want a thin layer that wraps your Spring services (your business logic) that can be called by a web service or a remote call of some sort from your web-apps. This will allow you to host your applications in different processes but still be able to communicate between them without trying to hack everything into the same web container and figure out how to reference the same running processes.
See documentation on Grails+Spring integration. When you have gotten Spring working inside Grails, next steps should already be standard Spring.
As you have not detailed, how your existing Struts and Spring MVC applications "pull in applicationContext and services" I cannot comment on the details. However, it should be similar to the way your existing applications do it.
EDIT: check also answers to this question on how to organize your Spring beans.
Related
I have a question to ask. Some time ago I was working on a project as a junior Java developer. It was a Java Enterprise Web App which uses Spring and Hibernate frameworks. I didn't completely understand the architecture of the project and I had only a small contribution to the project. But it was a multi module maven project and each module was built and deployed as a WAR file separately in the Oracle Web logic 12c. They didn't use docker and I don't know how the modules interact with each other (it might be REST or something). My question is: can we consider this type of multi module maven project that each module is deployed separately a microservice architecture?
Also, could you please inform me about a good book to start learning microservice architecture in Java?
Yes. Not using docker (or any other containers) does not necessarily mean that the architecture is not a micro-services based one. It can perfectly be as you are describing: multiple "WARs" (modules) communicating through REST APIs or gRPC or similar.
I agree, this is certainly microservice architecture, as a single overall application is broken out into seperate running instanes. Spring makes it very easy for separate microservices to communicate with each other via REST APIs, Eureka and Feign Clients. Idk about a book on microservices, but a simple project is always a good way to learn. Those might not sound meaningful to you but i recommend finding a simple eureka feign client tutorial online, and doing your own version of it. I did that and was able to deploy the same spring service to both my laptop and a pi, call these microservices repeatedly from another microservice on my laptop (the method i was calling just returned the environment hostname) and see that eureka was passing the call to each one in turn, giving me alertnating results. This demonstrates how easy you can horizontally scale using this architecture (i.e. if i need more power i can just keep deploying new instances of that getHostname microservice and no matter what device they are on eureka can link them up)
It is difficult to say about architecture style with given information.
Docker or without docker is not a constraint for microservice architecture style.
If you want to study microservice in Java than I suggest that you may refer to "Microservice Patterns - Chris Richardson".
I just develop a tool with my classmates and we want to use Vue.js as Web interface.
For Description what we programmed. We developed a Java EE web application in Eclipse. We use Tomcat 7 as web server. I search a long time and i found nothing.
Vue.js is a javascript front-end framework. There is nothing to stop you from using that with a middle-layer/back-end technology like Java EE.
In your HTML pages(or JSP) just include the Vue.js file as mentioned in the documentation, and other .js files that you create as part of your vue.js frontend application.
The library can then interface with any HTTP-based backend methods that you expose (using Servlets, Controllers, etc.) depending on how your Java EE project is structured and what frameworks it uses.
While investigating the same question, I found this good blog that has a git repository too
https://blog.codecentric.de/en/2018/04/spring-boot-vuejs/
From a glance it looks like a read solid implementation, however it has some sticky setup i haven't come across before.
It dose however seem like a professional and scalable solution i will definitely
give a try.
https://github.com/jonashackt/spring-boot-vuejs
Thankyou 04/24/18 by Jonas Hecht
For sure you can.
Your java application, which is your "backend", has to expose its functionalities as Web services (REST Json WS should be the easiest for what you are trying to do).
To expose your services as Web services, you need to find the easiest framework fitting your need. You will probably need to dive into Maven if you haven't yet, because these frameworks tend to have tons of dependencies.
Your Vue.js interface will make calls to the backend via HTTP requests each time necessary (get a resource, update a resource, ...).
I have a college project that manages bookmarks, a CRUD with folder structure. The project uses swing and hibernate all in the client. Now I want to make both a web and an android application version, but I don't know how to split the modules. For example, I thought about creating a web application with websockets and hibernate, and connect the swing, web and android in the websocket server.
Is that a good choice? If not, what better options are there?
Please note that the project has to be synchronized between the platforms and
I wonder about the technologies that can be used also, and not just the pattern.
I can use Spring too if necessary.
just an opinion, the project module structure should look like this:
android client (androidUI)
web client (webUI)
service part
db
integration tests
I'm developing an application which has two main 'parts' to it...
The public facing website
The RESTful API for the mobile application.
I'm developing the application with Spring 3 using Spring Tool Suite as my IDE. At first I thought that the API would be part of the same project as the public website. But then I tried to mix basic auth in with my form based auth for the public website things started to get a little confusing with Spring Security.
So I thought it might be best to develop the API as a separate project and share my domain objects, services and DAOs between the API and website projects. My question(s) now are:
Is this a dumb idea?
Should create a 'core' project with the shared domain objects, services, etc?
Should I use Maven and add the 'core' project as a dependency for the API and website projects?
Is there a better way to do all this?
It very much depends on what your needs are. I am currently working on a fairly large GWT application (using SpringSource Toolsuite and Maven).
We make extensive use of Maven modules and profiles. It can get a bit messy at times but it does enforce separation, which I think is generally a good thing.
I would say, if your front end and back end code are going to be completely separate, it might not be a bad idea to create them as separate modules. You can then set up your Spring Security as you wish for each project etc.
So, to summarise, I would say modular is a good way to go, but do investigate Maven modules as this may help you with dependencies.
I have the same specs as you
The public facing website
The RESTful API for the mobile application.
I have to separate web projects one for my RESTFULL services based on JSON and a database dependency. For my frontend project I don't have a dependency to the database but only to my restfull services.
With this strategy it is possible to use the same codebase for webprojects and mobile applications.
We have a desktop java application (image-processing) that is working great, now we have to add a client/server architecture using Java EE plateform.
We must use also MVC, and interacting with many other libraries like JDOM, JMatlink(MATLAB), and calling some exe files.
Based on your experience what is the best choice to do that (framworks, ... )
Correct, you must use an MVC framework to design a flexible and reusable web application on the Java EE platform.
I suggest the following design:
Use JSF (Java Server Faces) to design the front end. As you are migrating your desktop application then it will better suit you becuase it's Component and Event driven framework.
Middlware: EJB 3(or EJB3.1) This will provide best available flexibility, performance and security to call your Business components directy from JSF Beans or any other remote application.
Over here you can use various design pattern to encapsulate Library and database access i.e. DAO (Data Access Object).
Use DTO (Data Transfer Objects) to transfer your request/response.
Hope it will give base to start your research.
If you can abstract the layers that talk to the backends such that your frontend (Swing?) doesn't need to know where those service are located, you are half-way there.
The key should be a good module concept. Frameworks like the NetBeans platform help you with that, and they can easily integrate non-visual modules that handle the backend code.
I'm not sure what you mean with "We must use also MVC"
MVC is a design pattern not a library or framework.
But if you use something like the NetBeans platform, you'll be applying that pattern anyway, because it forces you to think in modules. Each module will have a defined responsibility and during startup it registers itself with the application.
Take an application that allows you to manage people (e.g. for a human resource department). One module is responsible for displaying a form where the user can look at a single employee. That module in turn looks for a provider that can load or list all employees. How that provider gets the data is invisible to the front end. It could use a flat file, a relational database or a call to a remote EJB server (this is were you could plug your JavaEE stuff in)
The application could even download the modules from the server if correctly configured.
The key is to make the modules independent from each other. This is true for any large scale application regardless of the technology used (web application, a server side daemon or a desktop application)