I need some pointers for embedding an external web portal inside our web application. our web application is built on struts, spring framework. We need to integrate an external tool with our application. We need to pass certain parameters to that external tool and handle the response as well. There requirement is to show external web portal screen inside our application. How can we achieve this?
Could anyone please provide pointers on this?
Related
Is there a way to create a web app with multiple pages using Spring Boot and Vue.js?
I used to work with Laravel which allows the use of vue components in blade files which is why I found it weird that all of the tutorials that I have found about Spring Boot and Vue.js were only directed to creating single page applications.
Basically, I don't support having the background framework rely on a front-end framework or vice versa. These must be two separate entities. See microservice architecure. Of course, multiple Vue projects can use the same server, thus implementing the "two-sided" principle. From now on, we can also expand to multi-browser (more Vue or Angular projects) and mobile platforms, which are served by a specific server via API interfaces.
Spring has security, filtering modules that you use some logic to determine if project "A" can call a particular endpoint, but project "B" can no longer and will get forbidden. Or you can even put in a separate API Gateway for that purpose with Nginx or Spring Gateway before API.
For example, you can implement an application token that accepts or deny on the server-side.
Broadly just a theoretical model. You can do this better, of course.
I wanted to use all the wso2 functionalities from my own customised UI. Is it possible to do so? If yes, them how to do it?
The scenario is: I don't want to use the available wso2 pages instead I wanted to have my own theme. How to do it?
WSO2 products up to carbon 4 are based on carbon osgi services. These services exposed as SOAP web services which known as admin services. You can refer WSO2 IS documentation to get idea how those can be enabled to outside and invoke [1]
You can create any application and invoke those SOAP web services. Although there are workarounds to invoke SOAP web services from HTML JS, best approach would be use a server side language like JSP and invoke web services from there. From front end HTML JS, you can use AJAX to call those JSP resources.
[1] https://docs.wso2.com/display/IS510/Calling+Admin+Services
If you are referring to your own UI like the BPMN explorer that ships with WSO2 BPS, you can use the BPMN REST api [1] for this. This documentation [2]explains how the existing UI works. You can build your own by invoking the Rest API.
[1] - https://docs.wso2.com/display/BPS360/BPMN+REST+API
[2] - https://docs.wso2.com/display/EI610/Customizing+BPMN+Explorer
I have started to write two web application projects
RESFful API for mobile clients using Spring REST API
GWT WebApp Server for web clients using Servlets
My problem is that both web applications are using the same database and that I think that instead of having two web applications I actually should have started this project using just one web application that handles the requests for web and mobile clients.
The problem I got now is that I don't have any idea how I could "merge" those two guys and whether I should stick to Spring REST API or if I should use RestyGWT.
GWT Server-Project using Servlets
RESTful Server using Spring
All projects (in the middle of a major refactoring mission)
Is there a way that would allow me to launch the web application as a whole and have access to the REST API from my mobile clients and to the Servlets from my web clients?
It depends on your business logic implementation. If you have it in a separate module/package, then it should be easy to merge your two applications.
You will have to rework the mappings in web.xml and how you pass the input/output data to the business logic methods from both the REST implementation and your servlet code.
Personally I will recommend a single approach such as only going with the REST based approach that you already have and migrate your servlet functionality to it.
I have been Googling a lot lately, but I find myself coming up short on answers.
I have a complete Spring MVC application secured by Spring Security and with services exposing logic to controllers (controllers -> service -> repository -> POJO's).
Currently all my controllers, except the login controller, serve nothing but JSON/XML and I want it to stay this way. I do not want to render different views on each controller.
However, what I want to be able to, is to separate the web application from the backend because in time I want to be able to integration with my service using more platforms than just a web browser.
Currently I have the regular Spring MVC application:
Configuration
Domain(POJO's)
Repository
Service
Controller
Login is done using a Thymeleaf rendered view and Spring Security which does nothing more than filtering all urls under the application root. After this, it is just a bunch of static files being served as resources:
Spring Controllers send a "{ontrollerName}/layout" to serve the AngularJS HTML partial used for all data under that given Spring Controller.
What I want, is a way to separate everything in the /webapp directory from the rest of my project. I have looked into a few different solutions here such as using Apache Proxy where my Apache Http server hosts the client code which communicate with the backend using Ajax to rest controllers, and Tomcat hosting the backend. However, I hear that proxying like this is not safe. I could however be dead wrong here.
So, the questions I hope to receive answers to are:
1. Is it fine to just write a client that uses Apache http server's Proxy to provide access to Ajax on the server?
If not; How should I proceed? Is it any point in trying to extract the client side from the /webapp directory or is this just some stupid idea I created because it seemed cool to be able to deploy them without having to relay on each others?
Is there any best practices in regards to how I structure a project with separate modules? Think Gradle build scripts for multi modules.
Should I think in different terms and use an approach not based on Spring MVC at all? If so, please advice me.
I hope this was clear enough to make sense for you guys.
The solution was to use the simpler approach of a restful API that did authentication over OAuth 2.
Basically the two best alternatives are a hybrid solution (part restful API and part server side rendering of pages) or a full blown restful API where you implement all functionality in a static web client. This way there is no need for multi-module projects and packing things together in one package.
im trying to understand where WSDL's fit in, in a typical web service backend application. i am coming from a Spring background and in my experience so far, in Spring, each url request gets mapped to a specific controller class via a dispate servlet running in the web container. you can specify which url matches a given controller via xml config or from annotations.
is using a WSDL the same thing as using an xml config file to map url requests to java objects?
Thanks in advance. im moving from Spring to standard j2ee/EJB3.
WSDL is just a description of Web Service interface, most Web Service systems generate those descriptions on fly like for example when you create asmx web services you can generate WSDL on fly by typing http://yourhost/yourwebcontext/yourwebservicename.asmx?wsdl and it will return you the description of that web service. Then you can use a tools that generate stub proxies for coding using those descriptions automatically, for example in Visual Studio when you add an Web Service Reference those operations are done automatically
No, WSDLs are not like a dispatch servlet.
A WSDL file is a description of a web service (SOAP, REST, etc.). A WSDL can (theoretically) be used by anyone to generate executable code which consumes the web service described by that WSDL.
From the WSDL tag info:
"WSDL" stands for "Web Services Description Language." It is an XML language used to describe a web service to code that wishes to consume it. It describes the messages sent and received, the possible faults, and the communication and security requirements.
From WSDL Essentials:
In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.
Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.