I understand this is a long shot but, would there happen to be a clojure library for responding to kerberos over http (aka spnego) requests?
I'm currently looking into using spring-security framework for this but thought i'd ask about a more clojure friendly approach just in case.
There's nothing special involved to integrate a clojure app with Spring Security. However, you are bound by its implementation as a servlet filter, so you cannot easily use it under a generic http library. Under a j2ee container, it is a good choice.
Related
A client talks to Django, and django uses node.js to do some javascript related work to give back the client a http response.
I wonder how I should set up the link(?) between the django and node.js.
Simply, I could use python's requests library and talk http, but is this best I can do?
If I were to build the communication link in c++, I would create non-block socket with Send/Recv Thread and use mutex(or similar) between the django view code and the send/recv thread.
I guess that's what is called asynchronous io in node.js world.
Is there a similar thing in python so that I could use on django side to talk to another server?
I heard many big companies use Thrift, would it fit here?
I also see gevent might be relevant keyword here, but not sure.
I am not sure if my answer is still relevant, but I'll give it a try.
IMHO, the best solution for you would be to have a RESTful API for your Django app. This has several advantages:
it provides a lot of decoupling between your Django app and your Node.js one, so in case you ever want to reuse any of them or to replace one of them, it will be easy
it allows you to design an API for each of them and to hide the rest of your implementation (your Django app should not care how Node.js does its job, but only the response that it provides)
there are many great frameworks out there that can help you quickly build your APIs (at leat for Django there is Django REST framework)
If you don't want to build a RESTful API, python's request library is probably the best and easiest way.
Good luck.
I have recently inherited a non-finished web app written in Clojure, based on compojure and hiccup basically. It's a bad attempt to model some sort of MVC with OO style not in the FP style as seen here . So I bet to re-start the project almost from the scratch reusing the useful parts. I consider these alternatives:
The least breaking alternative would be Compojure+Enlive+jquery-pjax
Using a clojure web framework like Pedestal Any experiences about this?
The initial idea was to implement a RESTful API serving JSON so for the more elaborated solution I have Backbone+react.js in my mind for the front-end and Liberator for the back-end but it's likely to take longer to develop than a traditional server app.
Thoughts and alternatives taking into account that an Ajax experience is required please, thanks a lot!
I'm not sure what is the relation between RESTful API and responsive in your post. However ...
You have multiple options here: Pedestal, Liberator and Caribou.
If all what you need is a RESTful API, then I think Liberator is your best bet and it is not going to take longer time as you mentioned. I don't know how you got that impression.
Pedestal shines if you want to develop Single-Page applications but the framework in general requires a good time to grasp and understand how it is works.
Have a look at Caribou also. It is easy to use and feel familiar.
But again, it is your choice.
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.
We're looking at developing a Web Service to function as a basis for a browser display/gui for a networked security prototype written in C++. My experience with web services has been limited to Java. I prefer Web Services in Java because it's on the "beaten path".
One sure was to do this would be to simply code a Java client which invokes the web service, and call it as a command line with parameters from the C++ code.
It's not ideal, since generally speaking an API is preferable, but in this case it would work and be a pretty safe solution.
A resource which does handles web service development in C++ is called gSOAP, at this url: http://gsoap2.sourceforge.net
Any thought on which is a better approach? Has anyone used gSOAP, and if so, what did you think?
I'd done things with gSOAP, it's not awful. I'm increasingly opposed to the RPC model for web services, though; it forces you into a lot of connection and session state that adds complexity. A REST interface is simpler and more robust.
To me is Axis C++.
For RPC style, have a look at Thrift,
I found it quite better ( faster, clearer, a lot of languages implementations) than soap.
My colleague ended up using a combination of Axis2 / java (for the service) and gsoap for the client. He created the wsdl from the Java service by generating it from a C++ header (using c2wsdl (?) or something like that. He said it was better than using a Java interface because that generated two sets of wsdl, for seperate versions of soap.
Then he used wsdl2java to generate the webservice and a test web client. Once we got that working, he used gsoap to create the web client (in C++), and it worked fine.
thanks for all the answers! I ended using a combination of them.
I had very good experience with gsoap - very simple, performance is good.
If it is acceptable to run only on Windows, there is a brand-new API for that purpose: WWSAPI
Instead of calling the java client from the command line, you can create a java virtual machine inside your C app, instantiate the class and call any methods. This is what the java.exe app does and I think the source code is included in the jdk.
Depends on how low level you want to go. You might checkout yield.
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.