I've seen that it is possible to run the django web framework on a GlassFish application server. Is it also possible to use a simple Enterprise Java Bean in a django project which runs on the basis of Jython? My idea is to have a django website for the frontend and Java EE in the backend (to manage the database access, etc.). Does anyone have experience with that?
A possibly easier variant would be to expose the EJB functionality using REST or possibly SOAP to get around interface problems between jython and java rather than do the call directly.
Related
My company currently has a Java project that allows us to run jobs to process data. The current project has a web interface, but its rather old, and most of the web interface is implemented through Java Servlets by printing HTML out to the web browser.
We want to instead create a REST API using the same core process, and replace the web interface with a different implementation in the future. Then eventually, we may have customers use the REST API.
My question is this: I understand NodeJS is pretty powerful, and from what I've read, makes the most sense when developing a REST API with the JavaScript and JSON integration. Should I attempt to create the REST API with Java, and if so, should I use JavaEE and Glass Fish, or should I have the API be built with NodeJS, then have the NodeJS server call the core Java service to process the requests?
I understand I may be introducing unnecessary complexity, however the project is rather large, and it won't be feasible to port the project over to NodeJS. I don't have experience with REST API creation (or SOAP), so this is new territory for me.
Thanks for the help,
Colby
Your aim is to create REST API so that your customer could use the API.
For this you can use :
NodeJS to create all your complete application code and Rest API.
There are plenty of
Java is good to create Rest API. You can use JEE and server you are comfortable with. For example, GlassFish.
My suggestions : Use Java because your current application is on Java. You could save time because working on same language. You already have skills in Java languages. You can use Spring framework ( Spring MVC, Spring Security and Spring Boot). Theses frameworks offer some great features and are simple to learn.
Since your current application is already in Java, based on Servlets, the easiest way to create a REST API is just to use the JAX-RS API in your current application. You can start with this JAX-RS tutorial. You would probably also want to use JSON-P for converting between Java objects and JSON. GlassFish, Payara, or any other application server should already provide both the API out of the box.
If you want to use plain servlet container, such as Tomcat, you can add Jersey library to our application, which provides a servlet to support the JAX-RS API in the same way. Or you can alternatively use Spring REST to build the REST API.
I don't recommend to use Node.js just for the REST API - it would introduce a new language for a thing, which can just as easily be done with Java, which is already used by your application. In the end, you would still need to connect the additional Node.js application with the current Java app, which is cumbersome. You would probably end up creating a REST interface between the Node.js app and the Java app, making the Node.js app redundant.
I want to develop a web service.Out of Java web service and .Net Web API which should I select.
.My requirement is that it should be stable and should be effective in performance.Which should bare load of thousands of requests and won't fail.Out of this two which should I choose and why?
My suggestion would be implement Rest WS in Java, Since it's platform independent, rich API's, you can go with Spring for rapid development.
My suggestion is Java. I'm used to Java to build REST server that serve thousands request and it's still working well.
The Jersey is good framework for you. Also Java is open source and independent platform.
In JavaOne 2013 I attended a seminar on Project Nashorn. I was astonished after knowing about it. Calling Java From JavaScript and vice versa.
But one question is still unclear to me, that how can we use Nashorn in favor of Web Application Framework like JSF, ADF Faces or Wicket etc. If someone give any pointer, it would be highly appreciable.
Scripting API for Java Platform, in general, and Nashorn, in particular, open wide range of opportunities for web app development on JVM. Frameworks like node.js and vert.x solvency of JavaScript as server-side framework. Yes, we still waiting news about node.jar - mystery Oracle's project of implementing node.js API on Java platform.
In todays modern web applications we should think about server-side more as service provider (RESTful services) rather than presentation framework that generates html on the server. But even for server-generated pages you not necessarily need stick to frameworks like JSF, Wicket, ADF. With Nashorn/Rhino you can use JavaScript templates to generate html markup on the backend. LinkedIn, for instance, already described benefits of having templates written in JavaScript in both browser and on the server. In case when your browser unable to precess client-side templates you can graceful degrade and switch to server-side rendering.
If you're looking to example for to leverage JavaScript in server-side web framework you can start with Dust4j. Do not be confused by words Rhino in description. Dust4j doesn't use internal Rhino's APIs. It uses jsr223 APIs so if you run it on JDK8 or JDK7 with Nashorn backport it should work. Dust4j project shows how you can integrate scripting into you JSP/Servlet/Filter-based application.
Nashorn is a JavaScript compiler and runtime for the Java Virtual Machine. It is not a Web Application Framework in itself, but might enable one to be built on top of it.
Therefore, it isn't a replacement for JSF or ADF.
Apache Wicket provides a functionality to post javascript code against the server, now and also allow to access session / request scoped objects. It does not replace the Web Framework itself, but allows you to create a programming interface to run code on the server and modify java objects, calculate values and return the calculcation.
The documentation of Wicket's Nashorn Integration can be found here: https://github.com/wicketstuff/core/wiki/NashornIntegration
And if you fork the git repository you can run the nashorn integration examples:
https://github.com/wicketstuff/core/tree/master/nashorn-parent/nashorn-examples
One thing left to be mentioned: Because it is an arbitrary code execution this might lead to security issues, so ensure that only logged in users can access this interface.
I'm gonna be creating a fairly straightforward Java app for my company that will process a csv file nightly. It's going to be running on our existing Small Business Server 2011 box so it definitely needs to run as a service (cause it has to run whether someone is logged into the server or not). Eventually I'd like to add a web component to it so I can view the log files from this app via a browser instead of having to pull them off the server manually.
I'm looking for feedback on what would be the best approach for this project. Should I use Jave SE and use a service wrapper around the created app to turn it into a service. Or should I use Jave EE (which I assume already runs as a service)? I've never used or developed for Java EE, so I'm not sure if this would be the best approach or if it would be overkill. If Jave EE is the best approach any and all information you can share on how to get started with it would be much appreciated.
Thanks,
Harry
For the short term, are you looking for a web interface through which someone uploads (web interface) or some process pushes (web service) a csv file that you then process? If yes, then consider Java EE: servlets, RESTful web services, and such, as others have mentioned.
Otherwise, are you just going to process an existing csv file that's "out on the file system somewhere" on a scheduled basis? If yes then consider timer based Java EE service.
Your production environment's management team might have some insight on what they'd prefer. If they are oriented around a windows management scheme they might be more comfortable with the "native windows" approach to deployment, start, stop, restart, scheduling, etc (i.e. the service-wrapped java program). Another layer of "service management" for just one process may be unnecessary complexity.
Document your setup/configuration/expectations whatever you do.
Longer term, as pointed out by others, your desire for a java-based web monitoring interface will require an app server. Consider your short/longer priorities, schedules to be met, etc. What do you need, when?
Java EE is a set of APIs, including JMS, servlet, JNDI, JDBC, EJBs etc. Consequently by using any one of these APIs you can pretty much claim that you're using Java EE, for what it's worth.
As to your particular problem, I would perhaps develop your program as a simple servlet based app and run it under a small container such as Jetty. That way you have a lightweight container (Jetty) and a fairly trivial program to write that can have a simple front-end for admin/monitoring. Note that the Servlet API forms part of the Java EE spec, so you're Java EE compliant, albeit in a minor fashion.
An alternative to this is (depending on how important that web interface is) is to write the program as a standalone program, and run it as a service using the Java Service Wrapper. At a later date you can then embed Jetty into your program and write your simple servlet-based API to run under the embedded web server. I used this approach on a number of projects and it works very well.
Anything that requires enterprise-level functionality should be done using Java EE:
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
http://docs.oracle.com/javaee/6/firstcup/doc/gkhoy.html
Others have explained you what is JavaEE.
Since you say "simple", I guess JSP and Servlets can do the work. You will need a web container like tomcat and that's all(it is easier than having a ejb container + web!). Actually servlets and JSP can do stuff which are not simple too.
If you are willing to use something like sessions, which have great design than Servlet sessions, then you might want to deal with EJB and all.
Unless you're ready to implement a web server yourself from Java SE, you don't have much choice: you'll need some web application framework. It can ba a Java EE web container, or another implementation like Play, for example. But Java SE won't be sufficient.
You may use webservices for instance axis2
I'd like to learn how to create a java web service that can be consumed by a web tier, which is constituted of java and flex.
What books can help me learn how to create a java web service and consume it via java & flex?
Should I look to build a web service from scratch or from frameworks like: XFire, Axis, CXF, Spring Web Services, etc.?
If using a framework is recommended, which of the above or any others makes the most sense to learn/use?
EDIT:
Both the java AND flex components of the web tier need to independently access the web service. For example, the flex component helps the user create & save a spreadsheet; the java component retrieves the spreadsheet data and displays it accordingly.
Flex should do the job: Web Services with Flex tutorial
You may not need a web service. Your Flex app can consume Java POJOs directly using Spring and BlazeDS.
What kind of a service are we looking at? If it requires database integration you probably need at least some kind of a framework - you really don't want to be putting your SQL queries hard coded into the app. Spring + Hibernate seems to be one of the most popular choices for a Java server implementation, but both of them are quite massive and require some effort. Appfuse could be something that provides a good starting point for building a service.
Why do you want to do your service with Java anyway? Is this because you know only Java or because there is a Java container already running on your server? I've seen great results with Ruby on Rails too and now there's some buzz about Scala too in the Java world. This could be your chance to try out something new and more flexible ;)
I'll take this opportunity to plug my own book, Eclipse Web Tools Platform: Developing Java Web Applications. Chapter 10 deals exclusively with creating Java Web services. Although the examples are all shown using WTP tooling the lessons discuss Java Web services created with Apache Axis.