I have implemented service layer which interacts with Data Access layer for data. So basically business logic is implemented at service layer. Services are implemented on spring framework. So basically each service can run on JBoss independently(as SAR). Now i want to implement presentation layer in smartGWT. So basically presenation layer code should call exposed methods of services for access of data. I want to know how well DataSource of smartGWT can integrate with a service and how to do same?
We did something similar. We put a Web layer on top of the Service layer. The Web layer contains Spring controllers that talk to SmartGWT (LGPL) RESTDataSources.
We've got it working nicely, but it's not a trivial task. The SmartGWT datasources are designed to integrate with the SmartGWT Pro libraries, which can make life tough if you're not using these. Make sure you understand the format of the requests/responses the datasources expect, see here:
SmartGWT RestDataSource
You'll probably find you have to customise the transformRequest() method on the datasource, see this question:
SmartGWT Datasource customization tutorial
We encountered a lot of problems with XPath support; basically it was fine for extracting data from complex objects sent to the datasource, but it was a nightmare trying to return complex objects in the correct format. We had to do a lot of work in transformRequest() to support this.
If you wish to use filtering, you will find yourself writing server code to interpret the Basic/Advanced Criteria objects SmartGWT sends.
You could also consider using Restlet, as mention in this question:
SmartGWT RestDataSource
In summary, you can do it and I encourage you to give it a go, but be prepared for a little work.
Related
We are trying to split a big monolithic J2EE application into a set of modules to provide unified business logic for all web application clients.
Our goal is to have smaller and more specialized business modules that can be used in any combination by many distinct web applications. This way we expect the applications get easier to maintain individually (compared to the now heavily coupled monolithic one).
We are planning to arrange it like the following diagram:
Where Web Apps call module services on the upper layer to handle business logic through method calls (RMI was the intended protocol but we are open to other options).
J2EE makes it easy to arrange services on three tiers like this through EJB remote beans.
But we are also trying to setup these modules as spring boot applications (using the Spring Boot JPA Starter) because it makes development much more convenient.
My initial plan was to implement the modules with Spring Boot and expose a thin layer of EJB beans as proxies to spring beans with the actual implementation of the service. EJB beans would have spring beans injected using the SpringBeanAutowiringInterceptor class as in spring v4 documentation.
But since this kind of integration was removed from spring v5 I don't know how to proceed.
They are also considering "EJB as an effectively deprecated technology now" as stated in the issue above. But for my use case I can't find a good enough alternative.
So far I have thought of the following options:
Using a custom interceptor as the issue suggests. But it looks like reinventing a discarded old wheel (if that analogy makes any sense).
Spring remoting is an alternative but it's challenging to make it work with Wildfly JNDI for RMI configuration and trying to looks like re-implementing EJB remoting.
Spring Integration I think will add too much complexity and overhead for this simple task.
Message based integration (JMS, MQTT, etc...) may not fit well because of the synchronous nature of what we are trying to achieve.
REST API calls would add a lot of boilerplate code (for serialization and deserialization of objects into JSON, endpoints configuration and so on) and also add some ovehead because the HTTP handling.
Our goals, in this order of priority, are:
Make this integration as solid and fail-proof as possible.
Make calls to business logic from the web layer to the service layer as simple as possible.
Have as little overhead as possible.
With all that said which of those five options mentioned (or maybe another one I haven't considered) would be the best way and why?
I would like to design and implement a mobile web application using JQuery mobile and Java EE technology.
The application will consists of sales persons using the mobile device to take an order when they visit the customers. So the application will contain complex business logic.
I am confused as to with what frameworks I should pick/select to design and implement the server side of the application. So my question is should I use Spring, Spring MVC and Hibernate together or some other suggestion?
But I want to stick to Java technology as I am comfortable with it.
My next question is how will the JQuery mobile and the server side integrate with each other. I mean what are the ways/methods to integrate them?
Your best bet would be to avoid Spring in this case.
Use straight Java EE, with JAX-RS, CDI/EJB and JPA.
Your jQuery code will call JAX-RS resources (which are ReSTfull web services). Those resources are injected with Service beans, which are a combination of CDI and EJB. These beans will contain your super complex business logic. If they need to retrieve or store something from/into the DB, they will use JPA for this via an injected entity manager.
In our application we have an Adobe Flex client that communicates to our Java/Spring backend via a facade (using AMF) that is exposed via Spring.
Any recommendations on how I could leverage this facade to make remote calls from iOS? Note that I would prefer backend frameworks that would be reusable from other clients (Android, etc).
I hear about JSON & RESTful web services. Would there be a way to rather easily get existing facade services to be exposed as RESTFul web services that uses JSON for object serialization?
Or would you recommend something different?
Any information and/or pointers will be appreciated!
Update:
So we have one option so far for this: JSON requests and responses via Spring
Anybody want to suggest any other ways?
Spring supports JSON requests and responses (see for instance, this article from the Spring In Practice blog), largely through the use of annotations.
While I don't think that it is likely that you'll be able to go through your existing AMF facade, I think that it should probably be pretty straight-forward to create a JSON-over-HTTP facade using the same underlying Spring controllers (assuming that you're using Spring MVC).
Edit: Whether the JSON-over-HTTP facade that you create is truly RESTful depends largely on your implementation.
I'm creating a prototype for a java web application.
Frontend is a Swing-based java applet.
Backend should be a type of web-service, that is called by applet.
Backend should run inside a servlet container and should have its own security (username/password) database. I know, that Tomcat has its own user database (realm), but the app should have own. Web-services, in turn, carrying out app logic and database access (via Hibernate).
I'm a newbie for a web development and I'm getting lost in a huge amount of the java web frameworks. Even just reading 'introduction' and 'getting started' documents takes a lot of time.
So I need an advice which framework(s) are suitable for the task and not very complex for a quick start.
Thank you
I would avoid any web framework in such case. Most frameworks are designed so that it is easier to connect bussines logic (backend) with WWW user interface. In your case you don't need web GUI - you have an applet, so web framework like Stripes, Struts, etc. would not help to much.
I think you can use servlet or several servlets as a connector between backend and you applet. Servlets are simple, easy to learn.
If you want to have some abstraction layer with additional services, like security, for instance, you can consider Spring Framework, but it has its own learning curve.
Spring (http://www.springsource.org/) seems like a good choice to handle DB access, and server side logic. Spring-security can be used to integrate security (it takes some time to get started, but it works very well). SpringMVC can be used to output simple XML documents, or if you need more complex remoting capabilities, SpringRemoting is a good solution.
If you want to go the full WebService (with a capital W and a capital S) Spinr-WS can be useful.
A little context: I would like to separate the Java application I'm writing into a more or less typical server-client model. I would provide a "server" which takes care of business logic and persistence, but write it in a very service oriented fashion. Any front-end code (GUI) would then call upon the server to provide the functionality in a user friendly fashion.
As I'm writing the application using Spring (and an ORM framework), it would make sense to explore the usual suspects to expose the server functionality, with the usual suspects being RMI, Spring HTTP, Hessian, web services, etc (the Spring natively supported options). These are well well documented, both in reference documentation and on here.
However, for the actual question: are there any less obvious, more exotic options I could consider to use for exposing my server services?
It's important (as always) to get the right balance between ease of use (from a front-end POV), performance and scalability. For example; since I've thought about providing the Spring-BlazeDS integration in the server any way (for Flex/AS3 clients), it dawned on me that BlazeDS provides a Java-native API for calling AMF services.
Any pointers are much appreciated.
I would recommend BlazeDS if you have a Flex front end and Spring HTTP if not. Both eliminate the non-productive work introduced by having to translate XML to objects and back again.
Spring HTTP is especially attractive because you can write POJO Spring service interfaces just as you always do, deferring the choice to expose via HTTP remoting until the end. You keep your options open that way. If you decide that Spring web services work better for you later on, you can keep re-using the same POJO Spring interface.