I come from a website programming background and I recently started to learn Java with the primary intention of being able to create a Back-end "Scheduling" service. This means that users should be able to create/configure methods to be run at specific date/times.
The solution must work on for a Windows OS.
I understand a number of required concepts;
Singleton Javabean
SOAP/REST Web Services
The plan is that my PHP front-end would need to communicate with a Java SOAP/REST Web Service which would, in turn, communicate with a "Singleton Javabean", The Javabean must start at boot time. I need another Bean to loop infinitely that would read SNMP(and other network messaging systems) and have those values read into a Web Service.
In the future I wish that these solutions to be able to be read into an Android Application.
However, I don't know how I would run a method that listened for specific times from a config file updated from a database or have a Bean run as a service to facilitate reading SNMP.
I've looked into some Java Servers, like JBoss, Glassfish and Tomcat but the documentation is so vast that it is intimidating to troll though to find out if they support the features I require.
I don't require a step-by-step guide here, just a push in the correct direction.
How would I configure a Javabean that listens for specific times? How would I configure a Javabean to run as a service to facilitate reading SNMP in an infinite loop?
Executor
For the periodic execution of the task in Java, learn about the ScheduledExecutorService. Search StackOverflow for many examples and discussion.
besides that class, you will find much discussion about the Timer class. But Timer is older, less flexible, and most importantly, should not be used in a Servlet environment.
The tricky thing is learning how to properly handle thread-safety. By definition you have multiple threads working with the same data.
Servlet
Those servers you mentioned such as Tomcat and Jetty are based on Java Servlet technology. Servlets are an alternative to your PHP.
If you want to keep your PHP, you can use one of those Servlet servers only as a Web Service server. So you will not need to master all that documentation.
Launch
The way to kook into your web app launching in a Java Servlet container is to make a class that implements the ServletContextListener interface. A pair of methods will be called by the container, one when the web app is being deployed (launching) and another when the web app is being I deployed (shutdown).
Again, search StackOverflow for many examples and discussion.
No Need For Singleton
No need for a Singleton. Singletons "are evil" as some people say (such as Miško Hevery), making testing difficult and keeping the instance in memory endlessly. Having a single instance is not the problem, it is the Java implementation of the Singleton Design Pattern keeping an instance in a static var that is the problem.
ServletContext
You can access the ServletContext to store and retrieve instances for your entire web app. Call the setAttribute and getAttribute methods to pass any Object subclass you want.
Annotations
Be sure to learn about annotations in Java. They can greatly reduce the configuration work of your server and web service. For example, #WebService and #SOAPBinding(style=Style.RPC).
Java Enterprise Edition
Java version numbers are confusing, and there is more than one kind ("edition") of Java.
Regular "desktop" or "standard" Java follows certain number scheme. The "enterprise" Java ("Java Enterprise Edition" or "Java EE") built on top of standard Java follows its own numbering scheme. So currently as of 2015-01 we have Java Standard Edition 8 but Java Enterprise Edition 7 (tutorial) (built on Java SE 7).
Be sure to look at the information on Java EE 7 rather than 6. I'm not an expert on publishing web services with Java. But I believe you’ll find many advances that may be easier now in Java EE 7.
Furthermore, there is a lighter smaller version of Java EE 7 called "Web Profile" that supports Servlets and a handful of additional technologies. The full Java EE layers on dozens of other technologies as well. For a list of those Web Profile technologies, see my answer on another question.
Tomcat & Jetty are both outstanding products. But both Tomcat & Jetty aim at mainly Servlets, that being a subset of the Web Profile which turn is a subset of full Java EE. You may, or may not, find the additional features of the Web Profile or full Java EE useful for publishing web services. In that case you may want to use the full Java EE servers such as TomEE or Glassfish or others. Or, sometimes the lighter way to go is to start with Tomcat or Jetty, cherry-pick a few of those additional technologies, and add their jar files to your project.
In particular, you may find JAX-WS useful (tutorial, reference implementation). Or if you prefer REST style, look at Java API for RESTful Services, JAX-RS.
I certainly agree with your statement that the documentation is vast. Unfortunately I think you're going to have to deal with that problem head on. As for scheduling a task, you could use Spring's Task Scheduling feature. This will work on any webapp, but it will also work without a webapp.
Related
I'm doing a project and the main concept is to develop an engine for Java EE that validates HTTP requests from the client.
I have looked at one engine related to this and it's the OWASP PROJECT STINGER. My own understanding of this engine is that a developer that uses the STINGER engine sets all the rules or configures everything, like setting regular expressions that are allowed and cookie rule sets by filling out an XML file (which they call an SVDL file).
Now my main question is how will I develop an engine for Java EE? Where will I start?
Well, it is not called J2EE anymore. There has been several years since it was changed to Java EE. Now, Java EE is a compendium of technologies (i.e. JAXB, RPC, EJBs, JSP, JTA, etc., etc., etc.). Implementing a full container is a major task and I doubt this is what you intend. You appear to be talking about implementing an HTTP server, which is probably a small part of what Java EE does.
Now, if you insist in implementing them, the starting point is always reading the Java Specifications for the particular technology you intend to implement. Download the JSRs from the Java Community Process and desing your implementation according to its requirements.
For instance this is the Specification for Servlets
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
Why is there so much confusion in the java world with various servers like apache, tomcat, jboss, jetty, etc and in .Net world it is just IIS that does that job. I would like to understand the need and use of it and am not starting a java vs. .net.
There are several reasons.
A Java EE app server is a transaction monitor for distributed components. It provides a number of abstractions (e.g., naming, pooling, component lifecycle, persistence, messaging, etc.) to help accomplish this.
Lots of these services are part of the Windows operating system. Java EE needs the abstraction because it's independent of operating system.
It should also be said that the full Java EE specification isn't necessary for developing web applications. JDBC, the part of Java that deals with relational databases, is part of Java SE proper. Java EE adds on servlets, which are HTTP listeners, and Java Server Pages, which is a markup language for generating servlets. You can develop fully functional web applications using just these technologies and Java SE. Tomcat and Jetty are two servlet/JSP engines that can stand in for full Java EE app servers.
If you take note of the fact that .NET has HTTP listeners built into the System.Net module, you realize that it's as if .NET took a page from Java and folded the javax.servlet functionality into the framework.
If you add Spring and a messaging functionality like ActiveMQ or RabbitMQ, you can write complete applications without having to resort to WebLogic, WebSphere, JBoss, or Glassfish. You don't need EJBs or the full Java EE spec.
UPDATE:
Spring Boot offers the possibility of developing and running full-featured Java applications as an executable JAR file. There's no need for any Java EE app server, just JDK 8 or higher.
This is because Sun and Microsoft had very different goals with their software, and ways to reach that goal.
The Sun mantra for Java has been right from the beginning "Write once, run everywhere", and that has resulted in that much effort has been put into creating _API_s that specify how the environment should look like to allow a minimalistic piece of code do its job.
The API for "process a web request and return a web response" was named Servlets, and has been extremely successful due to it filling a void and being well specified. All mainstream Java based web servers I know of allow to run servlets. An early implementation of a complete servlet capable web server is only 1500 lines Later this was expanded to include JSP's to provide for HTML with server side code (like PHP).
For any solution to be truly scalable, including web solutions, it means that eventually the load is so high that one computer is not powerful enough to run it on its own anymore. A scalable solution MUST be able to spread over multiple computers aware of each other, and that single requirement brings a LOT of other things to the table:
Code must be able to invoke code running on a different computer (EJB's).
Data must be available to all computers in a consistent way (database).
Access to said database must be efficient (database connection pooling).
... and much much more
Sun then created API's for all of the functions they found were necessary for this to run, and named it "Java Enterprise Edition" (those days the word "Enterprise" was used for a lot of things), and created a system implementing all these API's which people could buy and use.
The difference between Microsoft and Sun now comes in play. Here Microsoft would just make IIS public, and say "use these API's" in clients but not actually want anybody to create another server providing these APIs. Because they want to sell Windows to run it!
Sun wanted people to use the language instead, so they made it possible for ANYONE to implement the Java EE specification, but they had to pass a rigorious test suite from Sun (and pay) to be allowed to use the Java EE brand. This has caused a large number of Java EE servers to be available where you usually can reuse the core business logic, but have to configure the Java EE server to provide the resources the application needs.
See http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers for the state of servers today. Both commercial and open source are available based on your needs - pick the one that suits you best.
So, the reason is that Java EE is a set of well defined API's that anyone can implement, and they have.
First off, you can run .NET code off Apache using mod_mono, so it is not limited to IIS. There are also several other web servers (Cassini and XPS come to mind) that will run ASP.NET as well.
In order to run a dynamic web application you need both a web server and an application server. Sometimes these integrate so well they appear to be one and the same, sometimes not.
In regards to Java - it has always supported more platforms than .NET and has been more open, therefore got integrated to more web servers (on the Linux stack).
As both .NET and IIS are technologies that came from Microsoft, ASP.NET and the application server aspects of it (aspnet_isapi.dll) were bundled with IIS and the different .NET installers integrate with IIS. Of course, Microsoft only implemented it on their OS and for their web server.
Apache is very analogous to IIS, and doesn't have much to do with Java.
Application Servers in Java provide additional services that .NET provides in various ways, with different products or from the Windows operating system.
Apache is typically used in Java deployments as a proxy to an application server behind it, and potentially serves static content, or handles SSL, and similar concerns. It is entirely optional, although there are good reasons to use it.
Tomcat and Jetty are basically java web servers, which provide a defined framework (Servlets among other things) for creating dynamic web sites with Java code. They are often components of a larger application server, or can be deployed alone.
JBoss is an example of an application server (Glassfish and Weblogic are two very common others), which provides the full J2EE specification. The idea behind the J2EE specification is to allow a defined way to build an application server so that an application can be switched between different application servers from different vendors that comply with the spec. The specification is about how to interact with defined services that are useful for server-side program.
Because Java EE is a specification, not a product itself. Remember that Java is a lot more open than .NET (In the specification sense).
Each application server has different features, different performance, different target users/enterprises, different price tags, runs in different platforms, require different hardware. Differentiation is why those all application servers exists, one size does not fit all.
One reason is that writing a servlet is as easy as implementing the javax.servlet.Servlet interface in a concrete class. Servlet containers, then, only need to support a fairly simple API in order to call themselves web servers. This makes setting out to develop a servlet container extremely simple because of this limited contract of functionality.
The choices off tools are one of the advantages and disadvantages of Java, look at the available Java Web Developement Frameworks,you could evaluate them endlessly just to decide. in .Net it's pretty much MVC. With servers it's relatively simple. Most go to Tomcat if they need a web server and JBoss if they need a free application server though. The reasons for this have already been said, J2EE is a specification.
What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?
For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?
Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.
Thanks for your help,
Ivan
Without getting into too much details, even though you can write bare-bones Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important.
As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).
Follow Java EE specification as much as possible, while follow server specification least as possible.
If we try to find out what are in common among there Java EE application servers(JBoss, WAS...), answer is Java EE specification which server vendors must follow. If you have 2 solutions on a Java EE problem, you could check which solution comply with Java EE specification better rather than server specification.
From my experience with Jboss and Sun AS, you should just forget about AS-independency.
In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in Java EE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.
In particular, if you look at official Sun Java EE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.
But all above applies only if you use full range of Java EE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.
If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.
Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.
At the moment, I have lot's of Java which does all kind of nifty stuff and I'm happy with it. The code is command line driven which have been great so far, but I recently decided I want to make the functionality available through web-services. Since my is complex and I'm happy with the way it's written , I don't want go through the pain of porting it to other languages. So I set out on a google journey to find out what web servers exist (on a Linux machine, though it's interesting to hear the answer without that limitation).
From what I could find, it seems that there are two viable options: Apache Tomcat and Sun Java Server.
What are the reason to choose one on top of the other? what are the strength of each and what are the weaknesses? Or, perhaps, there is a third one which is much easier, flexible and less cumbersome.
Anyone?
Easy, flexible and not cumbersome, that would be Jetty, but also Simpleweb might be useful. You dont say much about your software so i'm not really sure, but for a command line program, I don't think you need all the JavaEE stuff.
The mainstream servers are these.
I think the Apache Tomcat vs Glassfish (Sun Java Server) discussion is irrelevant for your needs, any would do.
There are many containers for Java web applications, they all have their own strengths and weaknesses. If you're looking for a container to support a business application, you should probably take a look at how they differ and work out which suits your business and IT drivers.
The key thing is that they all support the servlet specification - your webapps can run in any of them - which means you can change your mind easily. Some of them will also support more of the Java Enterprise Edition specs, so may be too heavy for your needs.
If you're just getting started, I'd suggest Tomcat. It's basic, but it's reliable, quick to run and start up, and it's got a really easy web-based webapp deployment interface.
Your question is actually a bit too ambiguous and wide. You can in fact run Java code at any machine you like, regardless of the language you programmed the webbased interface in. You can for example create a PHP based website which interacts with a "backend" Java application (the "command line application" as you call it). The only requirement is to have a JRE at the server machine. Then basically everything as web interface suffices: CGI, PHP, ASP, Python, etcetera, you name it. As long as it has access to the underlying commandline runtime, which is in the PHP example to be done by exec().
But Java, actually Java EE, also provides a web application programming interface: the JSP/Servlet API, the web component of the large Java EE API. This make integration with the "commandline Java application" much more seamless. You can basically just put your application in the classpath and import/access/use it in a Servlet class the real Java way:
YourApplication app = new YourApplication();
Result result = app.doStuff();
// ...
To be able to run JSP/Servlet (JSP is at end actually also a Servlet), you need a concrete implementation of the Servlet API (the whole Java EE is just an abstract specification). Apache Tomcat is good to start with, the other popular alternative being Eclipse Jetty. Those are 'simple' servletcontainers which implements the Servlet API, with Jetty being a more embedded approach of it (you can configure and run it as a "plain vanilla" Java Application). But if you need to support/cover the other aspects of the Java EE API as well, then you need an application server, such as Sun Glassfish or JBoss AS (both which by the way uses Tomcat as the servletcontainer part).
To learn more about JSP/Servlet, I can recommend the Coreservlets.com tutorials.
Apache Tomcat should do good.
The standard concept for running code inside a web server is the "Servlet API" from Sun.
Essentially it provides a few interfaces which the web server uses to invoke your code, and defines how the web server should behave. This allows you to write very generic code that can run in a variety of web containers which implement the Servlet API. See the Wikipedia article for details - http://en.wikipedia.org/wiki/Java_Servlet.
They come in all sizes too, depending on your needs. Some small enough for embedding in your own application, some very big. The servlet API allows you not to care.
For a beginner, the quickest way to get up and running, is to download the full version of Netbeans which includes full support for doing this kind of work, and has a built in servlet container.