for SPDY, we need to implement a PushStrategy and to register it to push resources.
What about HTTP2 support?
I like the idea of nginx which consists to read link header in the HTTP response: https://nghttp2.org/blog/2015/02/10/nghttp2-dot-org-enabled-http2-server-push/
Thanks!
Jetty HTTP/2 comes with full support for HTTP/2 Push, in fact in different flavors. Webtide's website already has Jetty's HTTP/2 Push enabled.
There is a PushCacheFilter, which implements the same algorithm that was implemented in Jetty SPDY's PushStrategy, based on the Referer header.
There is a PushSessionCacheFilter, which implements a more sophisticated approach using a builder to actually push resources.
Both for now use Jetty specific APIs, in an attempt to propose them as standard for the Servlet 4.0 specification, and have them tested in real world examples.
The good thing about this approach is that entirely automated, and it does not require the application support: works out of the box with any old/legacy webapps.
The Jetty team can certainly explore the possibility of using the Link header, but that seem to require support from the application (the application has to add the Link header with the right format), and a proxy layer that impacts performances.
This is tracked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=463457, any contribution there is welcome.
In order to implement your own strategy to push resources, you can write a simple Servlet Filter, and in there use the Jetty specific API (i.e. Dispatcher.push(...) or the PushBuilder APIs) to push your own resources, similarly to what the above referenced filters do.
Related
I have a hypothetical web application which is split up into a microservice architecture like (as an example):
Clients A-C are web applications that serve HTML. Services 1-3 are the backend that handle CRUD and serve JSON. There are other clients (not pictured) that do not access Frontend Service - namely, native clients such as Android and iOS. I'm trying to figure out the best way to serve common frontend content (such as header/footer/css) across all web clients. The best way I can think of doing this is to create a Frontend Service that each web client can access to pull this common information. That way changing the common front end will be reflected in each application immediately without need to update versions, recompile or redeploy.
My question is what is the best way of doing this? I'm using Dropwizard to serve both the web clients and the services. The web clients serve Dropwizard Views (with freemarker templates) via Jetty. Is there a way to compose Dropwizard Views so that I can request a Header and a Footer view from Frontend Service and wrap these around each view returned from the Clients? Or am I going about this completely wrong? I know that Freemarker supports template inheritance but as far as I can tell this means the header/footer would have to live in each client or be pulled in from a common JAR (which would require updating version numbers and recompiling).
If you want to have content synchronized between all the microservices, in your case the header and footer, I'd suggest Zookeeper, it's designed for distributed orchestration and has more of a push model - i.e. you'd update the header in Zookeeper and all of your services would receive that update almost instantly.
I suggest the Curator library as it's much easier to work with than Zookeeper directly, the cache example might be a useful starting point.
You can also use Hazelcast as distributed Map/Cache. It is really easy to use (see code examples), but if you want some enterprise features you have to pay a lot.
How portable or compatible is JBossWS-CXF? My impression is that it is a "hybrid" because of a statement on the JBoss web site that states that it supports "almost all" of the features of CXF. If the goal is to produce services packaged as SAR files that can easily be deployed to application servers other than JBoss, if necessary, then should I stick with vanilla Apache CXF or use JBossWS-CXF?
If you stick with "pure JAX-WS" stuff, then the services should be completely portable to other applications servers. The hybrid nature comes from allowing a lot of the extra CXF features that don't have any equivalence in the JAX-WS spec. For example, if you use CXF's support for WS-Security, then the application would not be directly portable to another app server (unless they also use CXF). You would need to port that part of the code/configuration to whatever configuration is required for WS-Security on that app server.
I am working on a Java EE project where there is a need to incorporate Web Services to transmit and receive data to/from external sources. I am not sure which way to go, Axis2 or JAX-WS.
Any suggestions will be appreciated.
The choice of a web services stack depends on what standards you actually need. Here are some stacks currently available:
The JAX-WS reference implementation is part of Java and provides basic support, including WS-Addressing, but not WS-ReliableMessaging or WS-Security. The big advantage is that you do not get additional dependencies by using the RI.
Another option is Axis2, which also provides support for these standards. As far as I know, the use of Axis2 is declining and personally, I found it rather hard to use (That's basically an opinion, I do not want to start a flame war).
I would suggest to consider a third option: CXF. It is another implementation of a web service stack and supports roughly the same as Axis2. I found it rather easy to set up and use and personally prefer it to Axis2.
One more option is Metro. Metro bundles the JAX-WS reference implementation and the Web Services Interoperability Technologies (WSIT). WSIT provides an implementation for several more standards and is tuned to provide interoperability with WCF.
Here is an article that compares these stacks with a little more detail. My suggestion would be: If you only need basic stuff (no reliable messaging, security, etc.) use the reference implementation. If you need support for additional standards, go for CXF or Metro.
Metro is the way to go! At lest for me :)
please see my comment in a similar question.
It depends on your requirement. What type of implementation you require.Java from its 1.6 version provides API for JAX-WS type of web service creation. But, really it's just for the basic requirement. If you want ws-Security,ws-policy etc. then please go for Axis2. Actually in Axis2 they have made lot of improvement from it's Axis 1.x version. The new STAX implementation is one of them. Apart from that Axis2 has made service creation part lot easier. Even, they support RESTful web services also.
I am pretty new to web programming.I am developing a HTML5 based user interface which is supposed to use a middle ware written in C/C++.How can I do this?
I do not want to use any browser specific feature/library to communicate with the middle ware. Can we do the same at the server side and then send back the information to the browser? If so how can I achieve this communication with the middle ware at the server side?
Thanks in advance for the reply.
Note : I am planning to use Tomcat as the server in loop back.
As suggested above, you could use CGI (e.g., perl scripts) as a middle-man between the Tomcat server and your C++ middleware. What I also think might work well, and am planning on using myself in the near future, is to use boost::asio, and take the example HTTP server and modify it to use your middleware. You could then communicate between the Tomcat server and the C++ server using AJAX with JSON.
There is also something called pion server http://www.pion.org/projects/pion-network-library
It allows you to write the entire server in your own C++, with most of the common tasks abstracted away.
The Wt "web toolkit" library (pronounced "witty") may be of interest. Essentially all web-aspects are taken care of this, so absolutely no middleware. Here is an intro, quoting from the website:
The API is widget-centric and uses well-tested patterns of desktop GUI
development tailored to the web. To the developer, it offers
abstraction of web-specific implementation details, including
client-server protocols, event handling, graphics support, graceful
degradation (or progressive enhancement), and URL handling.
Unlike many page-based frameworks, Wt was designed for creating
stateful applications that are at the same time highly interactive
(leveraging techinques such as WebSockets and Ajax to their fullest)
and accessible (supporting plain HTML browsers), using automatic
graceful degradation or progressive enhancement. Things that are
natural and simple with Wt would require an impractical amount of
effort otherwise: switching widgets using animations, while being
perfectly indexed by search robots with clean URLs, or having a
persistent chat widget open throughout, that even works in legacy
browsers like Microsoft Internet Explorer 6.
It can run with its own web server (based on a Boost component) or be linked against standard web server libraries.
I wrote a short blog post about how to integrate it with another C++ component I wrote (RInside, which permits to embed R inside C++ apps) and by joining the two, I had a simple 'webapp' exporting R functionality to the web.
You can further enhance it via Javascript but that is something I have not looked into in any detail.
We developed a web service which is accessed by various platforms clients, for example it is requested by c++ and Java enabled clients.
I want to use simple, effective encryption Algorithm which is easily decrypted by JAVA - C++ and JAVA script based clients.
Why not just deliver your service over HTTPS?
Why write anything?
The most widely-compatible method of Web Service security that is still actually secure is Transport with Message Credentials. This uses SSL (https) for transport-layer security, which handles the encryption aspect, and passes a username/password in the SOAP header, which handles the authentication side.
It is not as secure as mutual-certificate authentication, which also gives you non-repudiation, but it is good enough for the vast majority of applications.
Several other options exist, but T/MC is usually the easiest to get working across platforms (.NET, Java, C++).
If you need to add javascript into the mix then I'm afraid you may be disappointed, as that is a serious game-changer. Although there do seem to exist various JavaScript SOAP Client implementations, SOAP is a second-class citizen in the JavaScript world, and I don't believe that any existing libraries have proper support for WS-Security or really WS-Anything except for the basic profile.
If you want your web service to be consumable by JavaScript then you want to go for REST instead of SOAP. I know that .NET (WCF) is pretty good at this but I'm not too sure how well Java and C++ fare. I believe that the transport security should be simple enough (it's just SSL), but it's likely that you'll have to implement some custom authentication code to get it working across platforms. Either way, you definitely want to go the SSL route; please do not try to roll your own encryption scheme.
If you already have the service implementation which is Base profile compliant and you want to keep on supporting various platform clients, extend your current service with WS-Security/WS-Trust. This will allow for encrypting/signing the content of the message, without loosing interoperability.
Depending on which toolset you used for your original implementation, the inclusion of WS-Security can be as easy as 'flicking a switch and selecting some options in your configuration file' (WCF/ASMX+WSE).
Since you mention the various platforms client side, I assume this is one of your main requirements.
Hope this helps.
You can simply use HTTPS which is easily implementable in both C++/Java clients (e.g. using the GNUtls library). On the server side, you will only need some small configuration changes.
Apart from the different request code, you have to create a self-signed SSL server certificate and install it on the clients. Of course this is not a good idea if the web service is public, where you need trust (= a real SSL certificate). But if it's only used internally, self-signed certificates are a quite good solution, as long as you keep the private key secret.