we are implementing webservices with Spring & Apache CXF which run on Tomcat 7, the original idea was to write some kind of monitoring solution that checks if the webservices are available and running ok.
But i guess that instead of writing the monitoring software ourselves there should be some tooling that already exists which could help us monitoring the webservices.
Which tooling could help us monitor the webservice availablity? Or what is the best approach to achieve this? Our support staff should be informed if a webservice goes down, and they should be able to act on data that the montoring tools provide.
In the past, I've added an additional API endpoint that simply returns a 200 error code. Hook this URL up to something like pingdom.com and you're good to go.
If you develop your own solution, a good approach would be to develop an external scheduled class that checks weather your services are alive every X minutes. If not, it will send the email you want. This will work even if your tomcat dies.
You can also check the JMX technology:
"The JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks."
Related
Is it correct that Android application which communicates with external database (somewhere on the server), requires web service (e.g. java web service)?
Is that web service an actual back end application which directly communicate with the DB?
Is this service, I am talking about, the same thing what AWS or google cloud offers, or am I messing it up?
Cloud providers can provide you computers and other hardware to run your back end server on and in some cases can provide you some or all of the services you need in your back end, obviously depending on what your app actually needs to do.
For example, AWS provides identify verification services, streaming recording backend services, notifications etc. You still need to do work to integrate your app with them but they do a lot of the heavy lifting for you.
Deciding whether to use the services or just the HW with your own services built on top is an architectural and business decision really.
You may want to balance ease of integration against vendor lock in (i.e. being tied to a single cloud provider to run your back end).
Personally, I like architectures that can be ported between cloud providers - you can still build on non cloud provider 3rd party service building block software if you want.
Having said that, AWS and Google have almost certainly put a lot of effort and thought into making their service building blocks easy to integrate and scalable so you may find their ecosystems work for you.
This is a very beginner question. I have tried to search for advice but am overwhelmed by the amount of information and would like some help with ideas on approaches to server design or what to search for!
What I would like to set up is a backend server that provides search capabilities and business logic and validation across some fairly basic data. It wont get too large.
I would then like to be able to plug in a website as a front end or a mobile app or a facebook app or even a desktop app..
My question is what is the best way for front ends to hook into the backend? I would like to have various user accounts with permission levels so authorisation would be important.
I generally only code as a hobby so whilst technically I have built a spring based website before the exact semantics of the client server relationship weren't clear to me. Now I want to separate the backend so that is is agnostic of how the data is displayed or entered completely and can run on a separate machine.
Thanks,
Rob
There is a ton on options. I had good expirience with apache CXF rest services (logic encapsulated in java beans, spring configuration) and pico web remoting ( more exotic,
but also rest service and plain java objects providing business logic)
if you ar already using spring, I would recommend to stick with CXF - it integtrates seamlesly ( and is spring configured itself )
I'm a long-time client-side (Swing) developer and I operated pretty much by myself in the same job for a long time. Working from home in a vacuum, I was pretty much completely isolated from the community. I recently took a position as a server-side Java guy for a startup, and I'm learning a ton of stuff but I'm the only Java person and am pretty much on my own again. Having never done server-side Java before, so much of this stuff is completely new and I feel like I have no idea what the normal best-practices are, or I don't have an intuitive feel for what tools to use for what jobs. I keep reading and reading various Internet sources (SO is awesome!) trying to bulk up my knowledge, but some things seem hard to search for because they don't have any obvious keywords. Hopefully some of you gurus here can point me in the right direction.
I'm in charge of implementing our backend REST service, which for now supports our website and an iPhone app. We're doing a social media site, eventually with many different clients. Currently the only clients of the service are our own website and our own iPhone app. I'm using Jersey, Spring, Tomcat, and RDS (Amazon's MySQL) on Amazon's EC2 platform. Our media storage is via S3. I've picked up all of these things pretty quickly and so far so good -- things are working fine with the website and the iPhone app. Cool.
Our next step is adding some long-running server-side processing. This processing is basically CPU-intensive stuff that doesn't involve any communication until it's done. I'm trying to figure out what the best way to handle this is. I'm thinking of using Amazon's SQS to queue up jobs in response to the REST events that should trigger them, but I can't figure out how I should handle the dequeuing and processing. I know I need some threads somewhere that take jobs off the SQS queue and process them, and then tell the REST service that the job is done. But where do these threads live?
In a plain "java -jar jobconsumer.jar" process on another EC2 instance that starts a small thread pool. Maybe use Spring to wire up this piece and start it running?
In a webapp deployed in a container like Tomcat on another EC2 instance? I don't really know what benefits I would get from this, but somehow running in a container like this seems more stable? Does this sort of container even really support long-running processing loops, or is it just good at responding to HTTP events?
Now that I write it out like that, I don't really see why I would want to use a container. It just seems like an over-complication. However, the Java community seems so centered on these types of containerized, "managed" environments that to not use a container seems somehow wrong. I feel like maybe I'm not understanding what some of the major benefits of these containers are? I mean, beyond the obvious benefits of the web-facing Servlet and JSP specs. Would any of the functionality of those specs help me out with something like this?
For a regular Java web app, you almost certainly want to be using one of the Servlet containers such as Tomcat - it takes care of accepting connections, parsing and serialising HTTP messages, JSPs, SSL, authentication, etc for you.
For a non-web app, the argument for using Tomcat (or similar) is weaker, but there are a few reasons to still consider it:
straightforward to add JSPs for querying and managing the app or add a web API in future
easy distribution of releases (one .war vs. an unholy mess of jars and config files)
hot deployment (although I've yet to see anyone using this for anything serious)
In terms of long-running processing loops, Servlet containers don't help you out beyond notifying your ServletContextListener when the app starts, so you can kick off any long-running tasks.
It's worth noting that if you're already using Spring, it's relatively easy to switch from a stand-alone app to a container using ContextLoaderListener, so it shouldn't be a problem if you decide later that you need the web stuff.
We recently faced a similar question, as we are hosting a large distributed service on EC2.
In short, we are very happy with Jetty 7 as a container. We use it for our user-facing-www, public-api, and internal-backend-api services. In some cases we use it for non-api services such as a workqueue, simply to expose a bit of status & health info for our monitoring.
The great thing about Jetty (any version) is that it can be configured in ~5 lines of code, with zero external config files etc. It's not a container specifically, but an http server that you can embed.
We use Guice for dependency injection, which also favors config-file-less implementations.
Long lived Java processes are nothing to worry about - you basically bring up your servers / threads / threadpools in your main method and don't call System.exit until you want to shutdown explicitly.
I'm interested in creating a client/server app in java, but not certain which framework to use. Here are simple scenarios to check disk space:
Scenario 1
1. A user would click on a button on a web page console "Get current disk space usage".
2. The servlet would get all machines from a db and ask each one to return their used disk space.
3. Each machine would reply with the used disk space.
Scenario 2
4. Each machine would update a service every 24 hours with its used disk space.
From what I can tell, I need to have a tomcat instance to host a servlet as the console.
From here is where it gets murky for me - and hence this question.
Would I also need
a) a SOAP service for #4?
b) a SOAP "client" running on each machine for #2?
I'm just not sure when to use SOAP services vs. RESTful services, etc.
Any opinions would be appreciated.
Fairly new to java, so apologies for any mis-spoken jargon.
You don't need a SOAP service nor a client. It would be nice, of course, but (if in a hurry) you can use your own format. CSV's, pipes, whatever fits you.
I've found SOAP services are easier to read but they are not the best choice when you expect a lot of data, mostly 'cos of the tags that you have to open and close. JSON is my choice in these situations.
Now, what you're talking about are not frameworks. They are protocols or convention. A framework is more language-dependent, like Struts, Spring, Tapestry, iBatis, etc.
Hope this helps.
SOAP is only relevant in context of an open ended system where service discovery, etc. would be useful. Otherwise, it is a PITA and entirely overkill.
RESTful services -- recommendation: use json -- would more than suffice for your purpose.
Tomcat is not your only option. Jetty is quite excellent as well.
I would suggest lightweight approach, as your use case is fairly limited, I would suggest going with embedded Jetty, Spring MVC and possibly JSON or XML response.
This will simplify deployment as you can wrap Jetty in wrapper application and make it runnable as process or service in either Windows or Linux, plus the footprint on the whole system will be fairly small.
This could change if you plan to extend this application with more feature and more integration point with other services/applications/protocols.
I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?
There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.
Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure
You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.
Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)
I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.
Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.
If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.
Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?
Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.
Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket