The eclipse-maven-tomcat project(containing html/css, jquery, javascript) will make ajax-jquery calls, using exposed web service url's(using json/xml) and interact with database. The database persistence layer and web framework (spring), etc, modules are part of another project which exposes web services.
Will using the above mentioned technologies will follow the headless websites/decoupled architecture?
Quoting this answer:
A "Headless Architecture" is a buzz phrase in the software development community pertaining generally to web applications describing an approach which splits the code base cleanly between server side (e.g. REST webs services) code which defines data and business logic from client side (e.g. JavaScript) code which invokes the logic and renders the data and typically as part of an MVC pattern.
So of course you can implement this using HTML/CSS/JS for the front-end and Spring for backend in separate projects.
Eclipse, Tomcat or Maven are quite orthogonal to the question.
Related
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 am trying to consume a public Web Service:
The Web Service uses SOAP communication
The Web Service doesn't expose the WSDL. It is possible to download it from the creator's website.
The Web Service only allows to connect via "whitelisted" static IPs.
The Web Service is hosted on GlassFish, so I am guessing it is written in Java.
The Web Service specification is rather long and contains many mandatory fields.
I would like to expose the Web Service to different type of developers during a Hackathon challenge, which may be using Python, Java, C# or other programming languages.
I used SOAPUI to test the Web Services and it was rather easy.
When I tried to use the standard packages in Python (SOAPpy) and C#, I had many difficulties. When using Java and CXF, it was a nightmare creating the request object.
How would you go about exposing the Web Service in a way which is friendly to developers?
No changes can be made to the original Web Services.
Thanks in advance!
If you want to access the original web service I recommend use its native protocol (SOAP) even though SOAP can be a major PITA and sometimes library support might be lacking (especially in modern script languages like Python, Ruby) because SOAP is not "cool".
ReST/JSON web services are deemed to be more "easy to work with" by many developers but shoehorning a "wrapper"/proxy on top of the existing web service will probably cause even more confusion and subtle bugs.
If the web service is fairly complicated this could mean this project is not ideal for a hackathon. If I were in your position I'd prepare client stubs (including a simplified library API) for 1-2 languages like Python and Java. For Python check out one of jurko-suds, pysimplesoap, or soapfish and check out which one works best out of the box with your service.
As I feel I'm drifting out of the StackOverflow scope I'll stop here :-)
I need to build a desktop application for internal users for certain business. It also needs web based GUI for external users. I know, with web GUI both internal and external users can access it, but there are certain factors which are outside our control - due to which, desktop application is really unavoidable. For the purpose of this question, I would like to focus on the way to support both Desktop client (Swing) and Browser client.
Are there any best practices to be followed? I could think of below:
Expose service classes as web services and use these from both Swing client and web client
Expose service classes as EJB (business is into Java EE techs) and use Swing client as EJB client. Web client can use controller classes to interact with EJB
Are there any known benefits of using either approach, apart from technology agnosticism offered by web services?
Also, for swing client, I am thinking of using Java Web Start for easy distribution. I have never used it before, but from what I understood, it can support automatic version check at startup and update the client when required - is this correct?
If you need to avoid dependency to Java/JVM on the browser (which you most likely at least want to), you should definitely go with mixed Swing-Vaadin approach. Build the internal application with Swing or JavaFX and web part with Vaadin. The programming model in Vaadin is so close to typical desktop UI library that it is really easy for the same developers to work with both code base, and naturally you'll use exactly the same backend.
See the example application I recently built to demonstrate a setup like this.
I in the process of designing the server side of a web-based user interface that will be very JavaScript intensive.
I originally thought of going with an MVC solution, but now I am thinking I want to use a REST-based solution such as Jersey or Restlets.
Is this often an one or the other type decision or can they be a combined solution?
Thanks,
Mike
MVC is about how the inner side of your app works.
REST is about how your app "talks" with other apps.
You can combine them.
A lot of modern frameworks actually are MVC based and make implementing REST web services easy: Ruby on Rails, Java Spring Framework with SpringMVC , Django, Backbone.js
One of the best Java frameworks I've seen for building MVC webapps with the ability to support REST is SpringMVC. This blog post outlines the REST capabilities in SpringMVC since version 3.0. I've developed REST services using SpringMVC and Jersey, and they are fairly comparable.
They are patterns / solutions to solve different problems.
REST sanitises & simplifies addressing access to features of a web application, for users, client software, etc.
MVC provides a means to organise your application code, making it easier to maintain.
MVC is an architectural design pattern for the layers of your application.
The folder structure:
Models/YourClassModel.php
Views/Home/HomeView.php
Controllers/Controller.php
index.php
The application style REST is the Representational State Transfer of the application.
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)