I'm currently working on a specification for a web application which consist of a administration interface, and a set of web-services which will be consumed by parter websites.
I been playing around with GWT and it seems like an amazing fit for the administration interface, but at the same time, I would love to use the Spring framework to produce the REST based web-service API exposed by the application.
My plan is to create two separate web applications, one for the admin and one for the web-services. One set up for spring and the other with the GWT app. Obviously, I wish to share the domain model between the two applications, I'm guessing this should be fairly trivial to accomplish? I'm thinking just to keep it simple, implement the full domain model in the GWT client project, and simply setting the sourcepath of the web-service to include the domain model from the relevant folders in the GWT project.
Now, to my question. I'm sure somebody out there have done something similar to this, are there any potential pitfalls I should be aware of before starting out?
I got a fair amount of time set aside for this project, but I never actually used GWT before for anything "serious" I just played around with it out of personal interest and I'm fairly experienced in both Swing and Android UI development, so I'm confident I can mange to use it for the (very simple) UI. The "unknown" in this equation is sharing of a domain model. I cant imagine this being a problem, since the domain model will be just POJO's (using JDBC, but again, I cant really imagine this being a problem).
Also, are there better ways of integrating GWT and Spring than simply doing to separate web applications and sharing their domain model?
Why do you want to create two separate applications?
Create one, with a clearly separated application services tier. Expose this services via standard Spring annotations as webservices, and also expose access to this services via GWT requestfactory (unfortunately, as far as I know, currently requestfactory does not play nice with REST requests, mainly because their way of serialization). This approach results in only one entrance (facade) to your application and allows to use this facade in two different ways.
I've worked on several GWT+Spring projects - for standard cases development goes very fast, frameworks integrates very well. However, if you want to do some customization, e.g. introduce security based on spring security - you will need to do some hacks, such as overriding transport classes. Of course it takes some time, but results are very nice.
I would definitely recommend to take a look at Spring ROO sample applications (as far as I know, roo is partially developed by google guys).
Related
I was watching a webinar made by lightbend talking about refactoring monoliths into microservices and a question came to me. The framework's main target seems to be refactoring monoliths, but lagom seems to run on its own container and set of technologies. When I think about monoliths and legacy Java apps, the main technology that came to my mind is Java EE. I think most of the applications in productions today rely on some Java EE technologies. The one I work in is based on EJB's mostly. So my question is: how Lagom solves this issue? I imagine refactoring this kind of application involves convert the remote EJB lookup into rest calls. But how would I keep the local EJB's of my application if lagom does not run in a Java EE container? Is it possible to use both?
I don't have a deep knowledge about Lagom, however, the market that is using architectures based on Microservices are heavily relying on spring boot/cloud. Currently, I'm working on a really large project using Microservices and it seems that the spring guys provide a lot of frameworks/tools for each microservices pattern that you should have in mind when you're thinking in microservices. By other hand, Netflix (the biggest microservices user) rely on Spring, I think that Spring Boot/Cloud is a good way to refactor your Java EE monolithic app to microservices
I suggest watching https://vimeo.com/163760711. The answer is that you shouldn't just be taking your EJBs and turning them into services, if you do that, you'll just introduce all the complexity and performance pain of having many services, and get none of the benefits of microservices. You need to rethink your architecture if you want to benefit from microservices.
You can start with representing your existing EJB services with a set of REST web-services, which in turn will be consumed by your new Lagom-based microservices, like this:
[EJB services] <- [EJB based REST services gateway] <- [Lagom based microservices]
or as deployment modules:
[your EJB app .EAR] <- [EJB-REST gateway .WAR] <- [Lagom based app]
Since your EJB app will run in a container (e.g. Wildfly), your Lagom app will be deployed independently (possibly on different host). Introducing the REST Services layer will allow you to develop each of the modules independently, which is the key to success in this case.
Next, gradually you would implement new functions and possibly reimplement some of the legacy functions in the new Lagom based app.
This is exactly what I did, and it works like a charm.
I am working on a project where the business object model and their persistence are already defined and implemented in Java (with JPA), my task is to develop a Web UI on top of them. The UI will be customized for the business operations, so it is not simple CRUD. Another goal is to build a set of REST API for external clients to access these business objects.
My question is, is Grails a good framework to use for my situation? Can I use Grails to wrap around my existing business object model instead of handling the persistence by itself? How easy it is for Grails to build highly customized UI (instead of straight CRUD UI that it generates for you automatically)? I suppose it should be really easy to build a REST API layer with Grails, is that correct?
Thanks for any feedback,
Yu
The short answer is Yes.
The reason why the answer is Yes, is because Grails is a framework. Just because Grails has Hibernate and GORM and uses Domain classes defined in Groovy doesn't mean your application has to. Have JPA backed objects? Great. Wire up some services (Since Grails is a Spring application you can do JPA through Spring) and make use of that.
Same with the UI. You don't have to use scaffolding. Plenty of Grails applications have very customized UIs that have nothing to do with scaffolding.
Grails offers you lots of tools for building REST APIs, they may fit your needs.
Take a good look through the Grails documentation and you will see it covers all layers of a modern web application. I know it's a lot of information to take in but there is a lot of details along the way in each layer that explains your options. That's the key. You always have options with Grails. This could be anything from a new view rendering engine to some Spring project or feature to one of the many Grails plugins. Take the time and do some research and I think you will find Grails is a very flexible option to consider.
The key take away is that Grails is a framework. Powered by Spring and Java. You can use all of the framework or some of it. You can use Groovy or Java. You can use Spring. The entire Java ecosystem is available to you. All in, Grails.
So, Yes.
I'm developing a web application with multiple frameworks (spring, hibernate, spring-security, ZK for GUI), and using Tomcat as app server. I must say I have absolutely no experience with java web services technologies. Thing is, I will almost certainly have to expose number of services for some external applications in the near future, and I was wondering what would be the way to go (considering the frameworks I'm using)...
I saw and read various tutorials and some questions (link) regarding Axis, Axis2, JAX-WS... Thing that confuses me a little bit is that I don't know what is the common practice (if any) to integrate services within existing web application (mainly in the terms of project organization). As I see it now, these services that I need to implement will rely partially on the existing source code, so I don't know whether I should use completely separate project, or I can put it inside my existing web app folder (which I tried with Axis2, but don't know if it's a good practice).
Thanks.
How to organize the projects?
In general I agree with #ericacm, but there is one thing you should keep in mind... You said you're going to develop a number of services in the near future. You may come to a point at which you want to host the services on a separate server, e.g. for performance, availability or maintainability reasons. This may influence your decision of separating the projects. Furthermore, separation "enforces" loose coupling, but therefore introduces other challenges like session sharing across multiple WARs. It's a case-by-case decision.
If I were in your situation I'd first ask myself whether the service(s) logically belongs to the web application or not.
Implementation
When in comes to WS-* implementations you have to make 2 decisions:
Decide for an API to use; today, I can't see any reason for not going with JAX-WS together with JAXB as API, they work well and they are standardized.
Decide for a Framework; I've experience using Axis2 as well as METRO (keep in mind that JSE 1.6+ provides basic JAX-WS support). Both work well. It's fairly easy to change the frameworks if you use the JAX-WS APIs.
I have good experience with Spring-WS 2+ and manual Castor mapping . Is is easy but powerful combination.
Spring-ws 2:
provides contract-first development (specially good for the web app with number of services).
provides WS annotation
supports XML mapping (Castor, JaxB, etc)
Castor:
mapping based on xml configuration
allows map multiple messages (requests/responses) to one java object (based on xml configuration)
If you are using some Java EE 6 server, consider also JAXB for manual mapping:
mapping based on annotation
should be faster than Castor
allows map multiple messages (requests/response) to one java object (when you use java inheritance)
You can go ahead and put them into the same project. Each web service will be an additional interface and implementation class along with some configuration.
Since you are using Spring CXF is a good choice as a for JAX-WS as it integrates well with Spring. See this page as a starter.
Spring-WS is complex framework for simple web services. If you want to understand web services completely and to know the nuts and bolts of web services, learn Spring-WS. It is extremely flexible and provides lot of options.
Else, if you want simpler alternative use JAX-WS. Spring supports JAX-WS annotations. Refer to the section 17.5.7. Exporting web services using the JAX-WS RI's Spring support.
http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html
Is it possible to create WS Server and WS Client manually (without generators) by JAX-WS? Specially if you are developing a big application you want to re-use objects but generators are generating a lot of classes that can be in 99% the same (for example if your app is WS Client and you have to connect to badly designed external WS Server). Is there some tutorial how co create ws manually?
There is a lot of reasons why I don't like generators and completely agree with http://ogrigas.eu/spring/2010/04/spring-ws-and-jaxb-without-a-code-generator
Looking to implement a RIA using AJAX with Java on the backend.
I was looking at DWR for an RPC style approach, but the project hasn't been updated since 2008.
I was also looking at DOJO and GWT.
Can anyone recommend a core set of technologies that works best for a Java based back end, that contains a rich set of client side widgets and backend integration with Spring WebFlow/MVC?
thanks
I would recommend Spring 3.0. It's up to date, lightweight, easily configurable, supports dependency injection, annotated classes, and is a great framework.
It supports REST, so it's easy to implement classes that return JSON to your HTML pages. This will help keep your content, behavior, and presentation all separate while still enabling you to build a Rich Internet Application.
Although outside the scope of your question, I'd suggest you use JQuery on the frontend as I've had really good results using it to transfer JSON back and forth from the server.
I would stay away from DWR. They merged with Dojo, which in my opinion is a better choice than DWR. DWR sounded good, but in practice it was buggy and difficult to use. Dojo was much cleaner and more modular. But unless you're using Comet (aka Reverse Ajax) just stick with Spring and JQuery.
Spring 3.0 is also supported on Google App Engine... just worth mentioning as Platform as a Service is in our future.
My recommendation is a RIA framework like SmartClient or ExtJS + a REST-based backend (built on Jersey, for example). I have also found JQuery to be extremely helpful when combined with these frameworks. Together. this allows you to build your GUI right on top of a REST API, which itself could be reusable for programmatic integration.
These kinds of questions are always religious ones, but FWIW I am personally not a massive fan of GWT, for multiple reasons. One of those reasons is because I don't want server side folks constructing GUI-targeted data structures (I'd rather have them stick to pure data and let me GUI folks handle the GUI stuff). So I actually don't appreciate that capability of GWT, but obviously many other people welcome that aspect, so again it's a religious choice.
you can try GWT.That supports Spring well.
http://www.springbyexample.org/examples/simple-gwt-spring-webapp.html
If you use a Spring MVC back end, you can use any AJAX frontend there is.
And if you are going to develop a RIA, I would suggest either Prototype with Script.Aculo.Us (Killer GUI effect library) or MooTools (which is either an extension or a re-write of prototype, that also includes many GUI tools).
The great thing about both ProtoType and Mootools is their Object-Oriented methodology (MooTools Class() docs, Prototype Class.create() docs), but the extension mechanism that gives additional methods and properties to DOM elements (How Prototype extends the DOM, MooTools Element reference). Of course this mechanism is exactly what the JQuery guys loathe about these libraries. But the nice thing is that because of these extensions, you hardly ever have to resort to browser-specific programming, the abstraction handles that for you.
I choose JSF for RIA applications.
It is J2EE 6 standard
it built-in in J2EE application servers (glassfish, jboss),
it has several implementations - if you have problem with one, you can switch to another
I has at least 4 (richfaces, myfaces, icefaces, primefaces) independent, big components libraries.
Spring can work well, but my personal preference is for simplicity, and Spring is bit heavy platform. So I prefer deploying services on JAX-RS containers (like Jersey); Guice for wiring things together, and in case I want to override or change data bindings, Jackson for JSON handling.
Other useful pieces would be jDBI for database access (much simpler than hibernate or other full ORMs), async-httpclient for doing calls to other web services.
Best of all, these all work nicely for many other kinds of uses.
I'm developing a java application or service for execute remote commands or another applications and receive the results of these commands. And I think about to project this application to be possible his use with a swing interface or a web interface.
I have to take care with the parameters to pass for my businnes classes and how I will deal with the results. I need to use a architecture and project that let me able to use my classes with a desktop application or web application too.
I believe this is related with API and service design. Some popular applications have a web interface or dashboard for control services, and the services are manageable by agents installed for execute some demons, services or applications. To do start or stop commands for database systems, directory services an other tasks
There are some guides to how develop applications and services in java that can I use with web and desktop environments?
I felling a bite confusing about this, because in my mind if I choose to develop this with a swing approach all the thinks turn clear for me. But when I imagining the same project using the web perspective I lose my directives.
Sorry and Ihope that someone could undertand me. :-P
Consider spring and MVC architecture. Neither of them is constrained to Web development only, however they are extensively used as such.
You might look into Naked Objects ,where you develop a domain object model and gets the UI more or less for free (You can get a desktop GUI, and various forms of web UIs). This is probably not a feasible approach if you're developing a public facing application, but more suited towards applications developed for expert users.
I have been in a similar situation recently while I started working on a simple CMS. I wanted my cms engine to be free of what UI/client is used to interact with it and finally I settled for a Web Service oriented approach. As a student of RESTful WS/ROA I usually like to take that approach.
If I understand your problem correctly, I would design it to be, each external program, service, web service I want to provide remote access to would be a 'Application' to my web service, where 'Application' would be a 'Resource'. Performing actions on the 'Application' resource would mean executing GET requests with different query parameters. How the 'Application' infers would depend on the 'Application' resource.
A similar approach I took in the CMS engine is for generating representations for a content. I support Ruby (JRuby), Groovy, JavaScript (Rhino) and Velocity template for generating representation. User creates the template script as a resource and refers then in the content type definition. Clients are provided URI's to the representation from the content generic media formats (Atom XML, JSON) and upon fetching them receives the output generated by the script. I am tempted to take a similar approach for your problem. It would not only separated the UI from the business objects, but also provide flexibility to add new backend services in the long run.
As tools for RESTful WS over Java I would recommend, Jersey, Abdera, Jackson. As an example for how use them together you can have a look at the CMS project I was referring to.
Hi i would suggest you to build your system with a modular approach such that
you have all your business logic is exposed as a service which can be accessed by REST,
in addition create you can have web application layer and a desktop layer.
schemantically it will look like be at a higher level
weblayer/desktop---------{REST interface} ------- {business logic}-----EIS
and for modularisation you can consider OSGI
hope this helps