I'd like to use Websockets with a Spring MVC-powered web app. I've read o jWebsockets and bristleback, but I am wondering if that is the best way to integrate. I am sure someone has done this before and has some tips what works and what does not...
Thanx!
since Springframework 4.0 M1 Websocket are supported, see http://blog.springsource.org/2013/05/22/spring-framework-4-0-m1-websocket-support/
Edit - 08 january 2014: Springframework 4.0 released and supports websocket, have fun.
Here is an update on 4.0 M2, see http://blog.springsource.org/2013/07/24/spring-framework-4-0-m2-websocket-messaging-architectures/
Spring MVC will offer you no help here - it supports HTTP traffic using the Servlet and Portlet APIs only. Websockets, I believe, are not HTTP-based.
Spring has plans to implement the WebSocket servlets offered by many popular application servers. The main problem is that, as each server comes out with it's own webscocket implementation, they all vary greatly. The Atmosphere Framework is available, and supports cross server, cross browser implementations.
There are some blog posts available, like combining atmosphere websockets and comet with Spring MVC
I would suggest you research the framework before deciding it's right for you. They have a github src repo with demo's and documentation available as well.
It seems that support is planned, https://jira.springsource.org/browse/SPR-9356 (but they'll need to work around the lack of Servlet API support)
Related
Which version of Spring Boot will (or does) officially support Servlet 4 spec? Where can one see the new features that come with it documented?
Thank you.
Spring Framework 5 supports the Servlet 4 spec (see SPR-12674).
Not a lot of new features related to that, really. You can now inject a PushBuilder as a controller method argument if it is available (HTTP/2 enabled, supported by the client, etc).
Note that you need to use a Servlet 4 based container to use those features (see SPR-15593), or you'll need to fall back on container specific APIs which have been available for quite a while now.
Spring Framework does the job here, so there isn't anything special scheduled for now in Spring Boot 2.0; don't hesitate to open enhancement requests on the dedicated issue tracker if you've got ideas.
I'm looking at enterprise JavaFX, and how to integrate JavaFX with server-side code. In the last few weeks I've done a certain amount of research in DataFX and Open Dolphin, and downloaded some videos, as well as looking at a couple of other frameworks. For example I've looked at the video on DataFX at:
https://www.youtube.com/watch?v=EN4fo6x0DcQ
However, although this video and others I've looked at explain how to set up a client application that connects with a server, I've found very little information on how to put together some server-side code that the client can connect to. Sure, one could use JAX-RS, but why re-invent the wheel? In the first instance I would like to put together some really simple server-side code that some test client-side code can connect to using DataFX or one of the other frameworks. The aim eventually is to get a client using JavaFX to communicate with a server.
My second question is that of the various frameworks available, is DataFX the best to use for a simple application?
I have experience with a Glassfish server hosting a JSF application, and it may be useful to have such a server hosting a JSF application communicating with a browser as well as communicating with a client JavaFX, as that way I can test out that the communication with the JavaFX application.
The latter is a bit of an aside, and my main questions are where can I get information on server-side programming for this, and the best frameworks to use?
Many thanks in advance.
If you are able to manage yourself the client-server communication you can pick any JavaFX Application Framework listed there:
https://github.com/mhrimaz/AwesomeJavaFX
Any of them allows to separate UI code from communication code.
As I'm author of JRebirth, I can advice you to create some RemoteService (extends Service and providing JAX-RS facilities or whatever) to perform this job.
If you search an all-in-one library managing client AND server side, DataFX + OpenDolphin is probably the most advanced one.
I'm the author of DataFX & Dolphin Platform (https://github.com/canoo/dolphin-platform). Both are valid frameworks that fill fit to your needs. Maybe a combination of both - Dolphin Platform as remoting layer between client and server and DataFX to define the routing and mvc based views on the client.
Some days ago I copied all the DataFX sources to GitHub (https://github.com/guigarage/DataFX) and currently trying to create a new version based on the modules that are maintained by me. Maybe I will extract the MVC related stuff and create a new framework based in it, we will see. What I currently can say is that I plan to work on it the next month next to the Dolphin Platform since I think a combination of both will be a good fit.
I would use this combination today to create applications but yeah, I'm the main developer of both frameworks so the choice is quite easy for me ;)
As you mentioned JSF I think that Dolphin Platform is a perfect match for you since one idea of the framework is to have a modern successor for JSF that can be used to create desktop & web based applications but provide managed controllers on the server. We provide a cool maven based jumpstart (Maven archetype) that will give you a quick introduction and a runnable client / server application with a desktop and web client in 2 minutes: https://canoo.github.io/dolphin-platform/#_dolphin_platform_jumpstart
I'm selecting a framework for restful service. Restlet looks promising. However, I'd like to pick something that's mainstream enough that it won't go out of support/development too soon. I know restlet has been around for quite some years. However, I'd like to know if it's popular enough. My questions are,
Any big name companies using it?
Is the default http server good enough for production?
thanks
The Restlet Framework has been available since 2005 when it was the first RESTful web framework for Java. It has support for the JAX-RS API, but its own Restlet API is both client and server-side since day one, much more comprehensive and extensible. We are free to innovate based on our community feed-back, without having to go through lengthy JCP standardization processes.
Also, we just published the 'Restlet in Action' book last September along with its version 2.1. Our internal connector is fully asynchronous and based on NIO and we are constantly stabilizing it even though it isn't ready for heavy productions yet (use the Jetty connector or a Java EE container with no change to your Restlet application).
Its consistent support for Java SE/EE, OSGi, Android, GAE and GWT with dedicated editions is unique. A port to JS (Node.js + AJAX) is also under way. We have also started work on version 2.2 with the first milestone being released (with full Java 6 support, OAuth 2.0 extension based on the final spec, etc.).
In term of references, we have many large companies using it including LinkedIn (see their GLU open source project), IBM, NVidia, ForgeRock, NASA, Sonatype, Apache Camel, Mule ESB, etc. Google has been using it internally as well. See some quotes here:
http://restlet.com/discover/quotes
In January, we'll launch a new community web site as well as APISpark, an all-in-one platform to create, host, manage and use web APIs, directly based on Restlet Framework (PaaS), so the project is active and has an exciting future!
Best regards,
Jerome Louvel
PS: I'm the Restlet Framework creator and lead developer.
The most mainstream you can get is Jersey. It is the official implementation of rest in java. Restlet came out before Jersey. But then Jersey surpassed them (in my humble opinion). I have used both Jersey and Restlet on serious projects. They are both good. However, you will find more support, more books, and more examples on Jersey.
Is this about Java? In that case, JAX-RS is the awesome new API for doing this. The best book for this is Restful Java with JAX-RS. My favorite implementation of it is Jersey, but there are others with their own unique features. All JAX-RS implementations are compatible if you don't use their distinctive features (which are minor anyway). The book explains the core API, the REST philosophy, and also some of the features unique to the different implementations. It is an excellent book. I love the introduction, where the author relates how he was used to traditional remote procedure call (like SOAP, WCF, and ordinary OO semantics) but then saw the light of the REST principles as being simpler and more elegant.
I use Tomcat as the HTTP server (servlet container). It is lightweight and is what Amazon Beanstalk uses (you can just upload your application, the WAR file, to it and it just works). You can also use GlassFish which supports many more JavaEE features, or use Apache for static pages and other things, and forward the REST requests to Tomcat/GlassFish.
The annoying thing about JAX-RS is that it's so powerful and easy that you're tempted to write ideologically-sound REST services. Unfortunately, javascript can't use many of the REST features (setting Accept header, calling anything but GET/POST, etc.) But it's not a big deal.
Jersey also has a fantastic client-side Java API that mirrors JAX-RS and reuses the same annotated classes, if your clients will be Java.
From the article
The Servlet API was released in 1998 and its core design hasn't
significantly changed since that time. It is one of the most
successful Java EE APIs, but it suffers from several design flaws and
limitations. For example, the mapping between the URI patterns and the
handlers is limited and centralized in one configuration file. Also,
it gives control of the socket streams directly to the application
developer, preventing some IO optimizations by the Servlet containers
like the full usage of NIO features. Finally it does not support HTTP
features like caching, content negotiation and content compression
very well, causing too much pain to developers and preventing them to
focus on their application specific code.
Another major concern was the lack of a modern HTTP client API in the
Java EE stack. The JDK's HttpURLConnection class is hard to use and
leaves too much HTTP features unsupported like expressing client
preferences for content negotiation.
Frequently, people were relying on third-party HTTP client APIs to
workaround those limitations. Again, NIO can't be supported with
HttpURLConnection.
In 2005, I saw an opportunity to go beyond all those limitations, and
to design a fresh API in the light of the REST principles. For the
first time, we have an API that unifies client-side and server-side
Web applications, an API that fully supports NIO and an API that lets
the developer programmatically control its container, connectors and
deployed applications without having to constantly rely on XML
descriptors.
How can we consume any web services in Lotus Notes 6.5. I have seen reference to Soap Connect API. Is it the only way to do it..?
Any example will be a great help..
Thanks..
There is no out of the box solution for LotusScript and WS Consumers in R6. You would need to create your own system to shape the SOAP request, send it to the server and parse the SOAP response.
You are not going to get the benefits from using Web Services in this fashion. The whole point is that you should not have to do this.
If you use the Java route you can use Apache Axis libraries to add consuming functionality.
http://axis.apache.org/axis/
Here is a very old developerworks article on it:
http://www.ibm.com/developerworks/lotus/library/domino-webservices/
Ultimately though I'd recommend to upgrade to a later version that does support WS consumers in LotusScript. Although be aware that LS suffers in WS due to limitations of the programming language.
What I did in R6 is creating Web based agents using LotusScript which behaved like Web Services. It performed rather good for services that weren't called by too many users at the same time (as far as I remeber...)-
This presentation / sample might be helpful for you:
http://www.slideshare.net/billbuchan/jmp206-lotus-domino-web-services-jumpstart#btnNext
Full files from Bill's presentation including sample are available for download here:
http://www.hadsl.com/HADSL.nsf/Documents/Lotusphere+2008+-+JMP206+-+Web+Services+Bootcamp!OpenDocument
Another helpful link (if you want to use SOAP/Java):
http://www.ibm.com/developerworks/lotus/tutorials/lswsdom65/lswsdom65-pdf.pdf
If you are on Windows, you can use a COM object in LotusScript to call the webservice.
A good one that I used myself is PocketSOAP: http://www.pocketsoap.com/ . It has a lot of features, like support for https, using SOAP headers and sending attachments.
Many of PocketSOAPs features are unavailable or difficult to achieve even in a native R8 web service consumer, so this is an option for higher versions than Lotus Notes 6.5, too.
Right now a lot of my applications use GWT-RPC for retrieving POJO's from a GWT RemoteService which in turn calls a Web Service (SOAP) to get the data. I am evaluating Flex and didn't really see anything truly analogous to this simple architecture. Anything I may have missed?
AMF is Adobe's compact binary message format for use in Flash / Flex applications. BlazeDS is the open source reference implementation for Java, using essentially nothing more than a simple "message broker" servlet to handle requests. This is similar to how services are exposed in GWT, although Blaze uses a single servlet, not multiple as in GWT.
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
BlazeDS, particularly with Spring Integration.
Does this help you? I'm not too familiar with GWT-RPC, but is the AMF protocol what you're looking for?
As others have mentioned, the main choice here is BlazeDS, which is Adobe's open-sores server product for exposing flex-native server RPC and messaging. BlazeDS on its own is a bit clunky, and if you use Spring on the server, there is a slick integration available between Spring and Blaze.
Another, 3rd-party alternative is GraniteDS, which does much the same thing as Blaze, but is Spring-friendly out of the box, and does quite a lot more than Blaze (e.g. runtime compilation and generation of SWF files from the webapp). I haven't tried Granite, but it looks pretty good.