in my project we are using an JavaEE(CDI,Hibernate)-Backend deployed on a WildFly-Server with an AngularJS-Frontend.
Is there any simple way to push messages from within a war-file to a Javascript-Client?
Thanks.
As you've mentioned JavaEE: Websockets are part of EE specification since version 7 - check https://docs.oracle.com/javaee/7/tutorial/websocket.htm.
The Websocket part of the spec is a bit rudimental, for example you have to implement things like topics, broadcasts or reconnect mechanisms by yourself (at least I couldn't find these functions in the specification). In case you need such functionalities it might make sense to take a look at socket.io (https://socket.io/) which can easily be integrated into Angular (https://tutorialedge.net/typescript/angular/angular-socket-io-tutorial/).
If polling (which is also implemented as a fallback in socket.io) is also an option, it's up to you what you prefer (and how complex the content should be). The EE specification is full of technologies with powerful abilities to return content: Servlets, JSF, JSP, JAX-RS, JAX-WS.
Just for clarification: Pushing or polling information with these solutions does only work when the clients have openend your web app in browser (even in background). If you also want to push information when they are not visiting your app you have to check solutions like Web Push Notifications from Google (https://developers.google.com/web/fundamentals/push-notifications/).
Hope this helps.
Related
I have an enterprise Java web application deployed in tomcat.
I am looking for ways to integrate a HTML & JS UI with the mid tier java code. So far, from looking around I have read that there are two ways to do this which fit my requirements :
1) DWR - Direct web remoting
2) Use REST web services.
I am not sure which approach to use.
Edit: What is the advantage of using DWR over a rest WS design?
Is there a better approach available? Some people asked me to have a look at GWT, but I am not sure if these are scalable.
Edit 2: I will most likely be using dojo for the UI development(Works well with REST/DWR??), and I want to keep the java code chages minimal. I understand that by using web services, I would have to write an additional WS client layer on top of the existing java code.
Also, the usual enterprise needs, performance, scalability, etc.
Ok so you're building a web client frontend to your java backend, there are a few ways to go about this:
You want to use java standards as much as possible, preferably living in the java EE world: JSF. You will need some knowledge of HTML, XML and perhaps even javascript (though limited). Personally I have had a pretty buggy experience with JSF+richfaces to the extent that I don't use it anymore.
You are very well acquainted with java desktop application development but don't know much about javascript: vaadin: it allows you to write plain java using desktop application terminology which will be compiled to javascript. Currently I am working on a big vaadin project and it is very nice to be working with pure java in eclipse, the downside is however that you are far removed from the actual frontend, so tweaking can be tricky. Additionally everything is stored in sessions (afaik) and scales poorly.
You are primarily a frontend person with unrivaled javascript skills: use a REST interface in java and a pure js/html/css frontend. Personally I think this is the cleanest design and I have designed a few of my own applications like this. The downside is that managing large javascript projects tends to be hard because...well...javascript sucks. The upside is that this will always be the fastest most lightweight option available to you.
Ideologically I would definitely suggest the last approach but this can be hard for large projects. If you have the hardware to throw at it, vaadin is a nice option. My JSF 2 experience was a bit disappointing due to the bugs in (necessary) third party libraries like richfaces.
PS: I have never heard of DWR but the last stable release seems 2 years old and all it seems to do is expose java code as javascript methods which can be better handled with a REST interface.
Open interface standards like REST and SOAP make it easy to build code to consume these services if you are using frameworks to build a REST Client and a SOAP client code respectively. But the point is that you need to have this client code to make calls to these services.
DWR on the other hand, generates this client code. Your java classes are ready to be called (like you would do in Java).
I'm a newcomer to JSF and am still trying to follow examples to learn the basics of how it works, and that has now lead me to begin exploring ICEFaces.
I love the concept behind GWT that you can just write in pure Java and have it compile down to JS and HTML, but I have also heard that ICEFaces offers a lot of things that GWT doesn't.
That led me to start thinking: is there a way to combine the two in a project, and get the best of both worlds? Is it possible to get the AJAX-centricity, rich UIs and underlying capabilities of JSF, but then use GWT to handle all the client-side code generation?
I looked at something called ICEPush which may very well do just this, but without fully understanding the roles both technologies play in MVC web apps I wanted to take a moment and see what the SO community thought of such a hybrid solution.
Having said that, I was wondering if someone could break down - in quasi laymans terms - the intentional difference between these two frameworks, and to give argumentation as to why they can be - or shouldn't be - combined inside the same project.
Essentially I'm looking for an AJAX-friendly, rich UI Java webapp framework that is open source, has an active dev community, and comes loaded decent/good documentation.
Also, not that beggars can be choosers, but I'd appreciate it if answerers don't solicit other solutions besides ICEFaces or GWT. I'm very well aware that these are not the only two webapp frameworks out there, and this question isn't going to convince me to start using either of them; I'm simply interested if their strengths can be combined, or not.
Thanks in advance.
JSF in general makes heavy usage of javascript. JSF or bette the JSF frameworks provide lots of components. The Javascript is generated on the fly.
GWT compiles the Javascript upfront. It provides some components as well. GWT is doing AJAX calls to its interfaces.
I'm not aware of any bridge that allows you to integrate JSF with GWT. So there is no interface and those technologies don't work together.
Both come with good documentation and have an active community.
ICEpush can be used directly with GWT; you can find out more about the integration here:
http://www.icepush.org/product/icepush-GWT.html
ICEpush provides a simple API to "push" notifications to the browser. Essentially, users (or browser windows) are organized into groups. When something interesting happens (such as a new photo uploaded to a photo sharing application) you can invoke a push on the group users.
In the case of the ICEpush GWT integration, you receive a callback into your "Java" code and can respond to the notification (such as, display the new photo). A GWT application can potentially run offline, but that does introduce the risk of application code being subject to offline attack.
In the case of ICEfaces, the ICEpush integration is abstracted away: rather than a "push" to a group, you "render" a group. With ICEfaces you request that all relevant pages be rendered on the server and any necessary page updates are sent to the browser. This makes it particularly easy to add Ajax Push features to an ICEfaces application.
So, the choice is really whether you want to use JSF or GWT. With JSF you have a standard server-side framework that emphasizes pages built from declarative markup. It is the natural successor to JSP application development. With GWT you have a procedural client/server distributed framework that emphasizes events and pages that are built from "Java" objects. It is the natural successor to AWT/Swing on the web. Both are very popular, so it's more a question of the technique you prefer.
I come from a .Net background and recently x-training to java.
I wanted to develop an Android application that required simple functionality to communicate with a server. For example, functionality such as post a username/score to a website (or service), or request information such as top 10 scores.
What type of communications should I focus on? What is the common technology to use? Does Java have the equivalent of WCF? Or does it have some sort of simple web service? Can web services be secured with authentication?
Ive heard other references to xml-rpc. Should this be something I should look into?
Depends on what your server is running. I usually just use URLs to fetch and/or send data and then parse the response with whatever is suited (such as org.json for JSON or org.w3c.dom for XML or HTML).
Java has the equivalent of WCF in the fact that you can develop Web Services with Java and use frameworks to develop such services to benefit from different features. The format which you send messages to these web services I think is what you are asking as such you literally can use any format you want (Dependent on support of such format by the service). You will find libraries for many of the well known formats like SOAP (KSOAP2), REST (JSON,XML) etc... Since the transport of these can be over HTTP, and you get a library in android to develop such services over HTTP you have quite a choice.
For Reference:
http://ksoap2.sourceforge.net/
https://metro.dev.java.net/
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Hope this helps,
Andrew
Without knowing all of your requirements but assuming it's gaming-related, you might be better served trying one of the Android gaming APIs rather than trying to roll-your-own networking solution. Scoreloop and OpenFeint, the two I am currently considering for my own Android game, both offer Android APIs that make it fairly straight-forward for posting and retrieving high-scores, in addition to other game-related features such as challenges and social network integration.
The advantage of this option is that you don't have to worry about how the phone talks to the server nor do you have to host the server itself - they have already solved those problems for you - and they're free which makes it great for us indie developers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create simple server having low load. The goal is to give a few javascript clients access to some functionality implemented in Java through WebSockets. I seek for best library to use for that - it should be simple, robust etc. Now I consider 3 alternatives
- jWebSocket
- jetty
- netty
What is the best? Or may be something else?
Thanks in advance
I'd go with proven Java servlet servers: Jetty or Resin. The have both been extended to handle WebSockets:
Jetty WebSockets
Resin WebSockets
My personal choice would be Jetty, as it's very simple to use and I've been using it as embedded server in several projects.
There are also some new kids on the block like Atmosphere and jWebSocket, but for servers I prefer to go with a proven solution. Jetty and Resin are also generic Servlet servers, so you can go with one product for all your serving needs.
jWebSocket now includes the Jetty 8.0 engine including SSL and includes many nice-to-haves on top of it. It provides cross-browser and cross-platform compatible clients even more mobile apps e.g. under Android, Symbian and BlackBerry. The server can easily be extended with plug-in and already includes lots of them (e.g. for Authentication/Autorization, JDBC, SMTP, XMPP/Jabber, RPC, Twitter, Filesharing, Chat etc.). Just check it out... http://jwebsocket.org. Looking forward to your feedback.
Regards
Alex
The PlayFramework! is the other very good option.
FYI, Atmosphere run on top of Resin, GlassFish and Jetty. Atmosphere free you from being stuck with one server by giving you Websocket portability amongst Websocket server. It also offer a client library that can be select the best transport in case websocket isn't supported by the browser. So you can't compare Atmosphere with Jetty or Rsin
Take a look at Atmosphere. Here is an article about websocket and atmosphere.
While I value the implementations of JWebsockets and Autobahn a lot, I prefer Atmosphere.
Ramp-Up::
Ramp-Up time is low. Francois Arcand puts a lot of effort into testing and examples, helping everyone to achived quick wins. (And I have no clue why he's able to respond so quickly to any architectural questions I rise. Impressive.)
Maintenance Perspective::
To me, maintainability is fundamental, if a software goes beyond major release version 1.0.0. The project is maintained at a top Maven-POM level with a properly constructed hierarchy. It prevents library incompatability. Libraries are reference at the correct level. That is well done.
Technical/Functional Perspective::
It offers a Java SE client library (wasync) that can either do native websocket communication (onMessage) or build on Jersey REST annotations (#Path). Subsequently this makes it as simple as it gets with the benefit of maintaining an open connection for subscriptions and the popular remote procedure calls (RPC) paradigm. It is a common attempt to merge those two paradigms. See also http://wamp.ws/, which heads for the same approach. Also, the library offers to establish QoS properties like robustness (e.g. in case a client disconnects) and reliability (caching undelivered messages). That is great for professional software to harness.
Maybe you should try Bristleback Server? Using Bristleback, you may choose from several WebSockets engines, like Jetty, Netty and Tomcat. You can have standalone server as well as web application that uses WebSockets (Jetty and Tomcat 7). Bristleback uses Spring Framework. If you have worked with web frameworks like Struts, Stripes or Play!, it will be very easy for you to start. Of course, Bristleback has its own JavaScript client library for even easier development.
Full disclosure: I am one of the co-creators of Bristleback Server.
I would also add vert.x to the list. It can server Websockets and SockJS (websocket emulation when the browser doesn't support them).
Update:
Undertow http://undertow.io also supports websockets.
Follow my blog. I'll be ready for release sometime in the not too far off future. Light-weight has been emphasized through the whole thing - but it's also fast. I don't know yet how well it will ramp up to higher loads. But I've been running the demo for a while now with relatively low load and what I have has been working well. (I'll test heavier loads later and make sure that it can be ramped up.)
http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html
If you are looking for infrastructure around message management, user grouping ("rooms"), and data synchronization ("shared variables"), you might want to consider Union Platform:
http://www.unionplatform.com
[Full disclosure: I am one of the co-creators of Union]
Why don't you just write your application on an open standard like JMS, and let the clients sit on the JMS bus as message clients?
The whole point of websockets is to bring any native TCP protocol directly to the client instead of converting it from your back end to http request/response.
Your back end services would talk to a JMS broker like ActiveMQ, and your clients speak AMQP in the browser via a Javascript API that looks just like the JMS API in Java. All you need for that is a websocket gateway, for example Kaazing has such a gateway, all it does is route your JMS TCP traffic out to the web clients over websockets. They also provide fan-out so that you don't overload your JMS bus, i.e. you just use a handful of connections to the broker to offload a million browser client connections.
The bottom line is that you don't need to tie yourself to any specific platform. Stick with standards, that way you have 100% freedom to swap out components as your environment changes.
I am in a situation where I would like to implement Ajax Push in a Java based web app to update things like counts of item in stock on the web page as they change without any interaction from the user. I understand that the technology needed to do this is called Ajax Push. I also have some experience with JSF 2.0, and this is preferred but not required.
First we need a demo showing this in about a couple of weeks, but if the demo is accepted we will have sufficient time to do it right.
I've looked around and found that apparently Icefaces do this very well, and I will look into it. I would just like to hear if there happens to exist others which might even be better for us to use?
Please, no "these are the top three hits from Google" answers. I'd like to hear opinions based on experiences.
You can now use Ajax Push outside of ICEfaces. Checkout http://www.icepush.org/. There are client adapters for JSP, Spring MVC, Wicket, GWT, jQuery, prototype, and Grails.
We have tried both Icefaces (in JSF 1.2 mode) and Atmosphere/Comet with Primefaces.
Icefaces push worked brilliantly out of the box.
We couldn't get Atmosphere to work (in Primefaces), but this could be because we tried it with the latest (0.6) version, and Primefaces doesn't support it yet - so now we are waiting for an updated version (it is promised that it will be the next big feature after p:dataTable has been rewritten). In our case the push was not a critical element in the demo and we could easily use polling instead of a real push solution.
Icepush was very easy to get up and running, while Atmosphere is not very well documented (IMHO), and requires a bunch of jars and configurations. It is not for beginners for sure.
So, if ajax:push is a key part of your demo I'd suggest that you stay with JSF 1.2 and Icefaces. At least until the demo is done and the customer is happy - you can still take you time with the Atmosphere configuration after that ;-)
I don't know if it is better since I don't do IceFaces, but PrimeFaces has a <p:push> component as well. It makes use of Atmosphere under the hoods to be as much as possible appserver-independent, which is in turn already pretty awesome. It abstracts all the appserver-specific details away. Also see this article about Servlet 3.0 vs. Atmosphere:
Atmosphere always auto-detected the best asynchronous API when you deploy your application. It always try first to look up the 3.0 Async API. If it fails, it will try to find WebServer's native API like Grizzly Comet (GlassFish), CometProcessor (Tomcat), Continuation (Jetty), HttpEventServlet (JBossWeb), AsyncServlet (WebLogic), Google App Engine (Google). Finally, it will fallback to use a blocking I/O Thread to emulate support for asynchronous events.
How to get it all to work is in detail explained in chapter 6 of PrimeFaces User Guide (PDF) in flavor of a chat application as it is presented in the <p:push> showcase page.
I think ICEfaces is the best solution for AJAX PUSH, they pioneered it, and in my opinion they have the best implementation.
Primefaces looks promising but the push functionality doesnt work with their latest release. With Icefaces 2 beta, push works OOTB.
There is an independent atmosphere framework based push implementation for jsf 2.2 named Ext JSF Push. It is fully integrated into JSF and can push to a single client, push render directly to a group of clients or push rendering events to a group of clients:
<e:push id="some-channel" direct="true">
<h:outputText id="text" value="#{pushTest.value}"/>
</e:push>
A rendering event inside the push tag can be triggered either by traditional render attribute or by code call. Rendering is transparently broadcast to all connected clients (http://www.intersult.com/wiki/page/JSF%20Ext%20Push).
ICEfaces is definitely your best best for the short-term demo requirements, as well as your longer-term "doing it right" goals.
To begin with, ICEfaces provides the most natural model for developing push applications. You think in simple terms of server-side triggers causing state changes in your application. ICEfaces and JSF do the rest, affecting seamless rendering of the new state. No messy push tag markup where you have to declare precisely how the presentation changes with each push event. If you know JSF, adding push to an application is dead simple with ICEfaces. Get your basic JSF application working first, and then add the necessary push logic to your server-side code. No other changes required.
Longer-term you should know that ICEfaces provides all the deployment technology you will need for enterprise-strength deployments. Enterprise Push Server is central to this as it provides complete push connection management in clustered environments (see: EPS). ICEfaces Ajax Push is operating in a wide spectrum of production environments in many Fortune 500 enterprises, so you can rest assured it will scale to your demands. Additionally, professional customer support is available. These are all be key characteristics that will help you sell the substance behind your demo.
Nothing else in the marketplace compares, and look forward to ICEfaces 2.0 which is JSF 2.0 compliant, and brings next-generation Ajax Push capabilities. Its available in Beta now.