It's been more than two years since someone asked "Which SOAP XML object serialization library for Java would you recommend?" and assuming a lot of things changed since then, I believe that's enough of a good reason to revamp the topic.
So in lieu of implementing SOA in Java that will be as interoperable as possible with the .NET Framework (or any other enterprise platform for that matter), in a first analysis I'm considering going with Apache Tuscany but I was wondering if there's any reason I should not? Any feedback will be definitely appreciated.
Actually, the first consideration I'd make is "do I really need SOAP/XMl?".
In particular:
WSDL is not nearly as cross-platform as is suggested; it is very easy to get cases that don't work well (there was one here on SO re PayPal earlier this week)
XML is human readable... But as a result is relatively slow and bloated
There are other ways of sharing a definition - for example, we all manage just fine with an API document that says "this API returns JSON in this shape {...}". WSDL mainly seems to help drag-and-drop developers; of which I am not one.
As such, I suggest looking at simpler (think: YAGNI) protocols. For payload, I'm a big fan of protobuf, which deliberately is a simpler schema and therefore allows for much less uncertainty over what can/can't be handled by different implementations, while still covering every sane use-case. It is also very efficient or both CPU/bandwidth. Very portable, and has a schema definition language (.proto) for defining the data, but MUCH simpler than WSDL. Shock horror! It isn't human readable... Well, there are tools for that :) why impose the failings of us week and slow flesh-based units on our APIs?
We use the metro framework and so far it has proven to be highly interoperable with WCF including complex message level security using mutual certificate authentication and username token. In our case WCF is server and Java is client.
Related
Suppose I have a remote JAX-RS JSON API from a server running Tomcat. I want to access this API from a C/C++ client. Are there any tools available to make life easier for the C/C++ client, e.g. code generators? Or does anybody have a suggestion for an alternative?
I have never heard of such a tool. More to the point, I suspect that such a tool (a C / C++ generator for JSON) is impractical.
There are a number of reasons why. Some of the most significant ones are:
A key problem is that JSON doesn't have schemas. This means that an API generator would have to resort to looking at example messages and try to infer what fields to expect and what their types are. This can be difficult and even theoretically impossible in some cases.
In languages like Java and C#, there are straight-forward "right ways" to generate object APIs; e.g. the JavaBeans conventions. In C++ and especially C, the conventions are not there, and there are complicating issues like container protocols and memory management to deal with.
In languages like Java and C# are runtime type-safe, and have various language level mechanisms are provided that allow you to use dynamic programming to deal with the JSON's schema-less nature. For example, in Java you have reflection, proxy classes, dynamic code generation and dynamic code loading, all of which can help in dealing with JSON. In C and C++, these mechanisms are generally unavailable.
In short, if you are using C or C++, JSON libraries are as good as it will get.
FOLLOWUP
As a comment points out, this may be feasible to implement in the context of a specific JAX-RS-based server implementation. You'd need to get hold of the internal metadata, apply the JSON mapping to it, and generate C / C++ APIs from that. The problems are:
The generator implementation would be platform specific.
The C / C++ based client would not be able to cope with changes to the effective schema without regeneration of the APIs and corresponding client code changes. (By contrast, a JSON library-based solution can in theory be coded to deal with unexpected new attributes, etc)
You still have the container / memory management problem to deal with.
What you need is your choice of library for sending and receiving http requests, and a json parser. Nothing is going to generate code to make it easier for you because the idea of such an API is that it spits out JSON. The point of JSON is to go across language and transport barriers in a consistent way. A bit like XML, but simpler.
This question might interest you: what's the best json parser? JSON Spirit Looks like a particularly good article.
Now, as you're using REST, all you need is to communicate to the right urls. Done.
The final thing you want to decide is what libary to use for network communication. Boost would be many people's recommendation, I'm sure.
I have a startup considering building a Java backend and a Rails frontend. The Java backend will take care of creating a caching layer for the database and offer other additional services. The Rails frontend will mostly be for creating the webapp and monitoring tools.
What startups/companies out there are using this kind of setup? What are some gotchas in terms of development speed, deployment, scalability, and integration?
(What would be helpful for me is personal experience or informal case studies. I'd like to de-priorities answers addressing alternatives like Grails or JRuby unless it turns out to be a big part of the equation)
Thanks!
I've never done any rails development but here are my thoughts. Why not just use Grails? I've done a fair amount of Grails development and it works well for rapid prototyping. It also offers all the power of Java, Spring, and Hibernate. Instead of dealing with communication between two different technologies you could take advantage of the fact that Grails uses Spring and Hibernate under the covers to deal with caching as well as any other requirements these technologies support. If you have Java developers Grails should not be to hard to pick up. The grails plugin story is decent. All of them are stored in a central place and are easy to obtain but quality differs depending on the plugin author. You also have to remember that since Grails uses Groovy which is syntactically similar to Java and runs on the JVM it is very easy to use existing java code including the multitude of available Java libraries. I don't know this for certain but I assume there are a lot more libraries out there for use with Java and there for with Grails then are available for the Ruby language and Rails. I can't make a resource usage call for you but my question would be how many people do you have with experience designing Rails systems that use Java on the back end with all the gotchas that will go along with that? You may find that you have no one who is proficient at debugging when something goes wrong in communication between the two technologies.
I have used similar pair for one of my projects, but instead of RoR I used Python. I don't think there's large difference.
In general, there's nothing specific in this kind of programming. Two most important things you must care about:
good modularity;
well thought-out protocol between RoR and Java.
First is about exact functionality decomposition between parts of the system. We've got some troubles because of not understanding what part of a job must be done by Java, and what part by Python. In general, you must tie together all functions that are close to each other, and thing that are far must be connected in a very few places. I guess you know rules of good modularity, but in case of composing different languages this must be thought-out much more carefully. You can also be interested in creating several distinct Java services (e.g. one for database caching and another one for all the rest) to be able freely combine them or even use in other projects later.
Second is about communication between your parts. I can see two ways to communicate: through database and through pure network protocol. The former need some network communication anyway, so we used pure network protocol, without any other way to connect parts.
We had experimented a lot with SOAP, but it gave hundreds of errors: this protocol is quite ok to connect services written in one language (i.d. Java to Java), but terrible for connecting services in different languages - automatic tools for generating WSDLs gave different results for Java and Python, and manual creating of scheme was hard and labor-intensive.
So we used to REST. It uses all the features of HTTP protocol such as all four main HTTP methods (POST, GET, PUT, DELETE), error codes and many other things, so it covers almost everything you may want. The only restriction with REST is that it can't hold state, so you may need to implement your own sessions mechanism.
If you're not very comfortable with REST and seek some real example, see Facebook Graph API and for implementing REST services in Java you can use Restlets.
Perhaps I'm stating the obvious here, but the biggest gotcha here is the actual fact you're combining two technologies. Not only will development be slower - Rails and all Java frameworks are expecting to have a full Ruby/Java application - but for the other issues you mention (deployment, scalability, integration), the existing tools and solutions will not work, or at least not very well.
If you have a compelling reason to combine the two, go ahead but expect to spend more time on these issues than with a single technology solution. If you don't, pick either Rails or Java.
I would strongly urge you to consider having the frontend and backend in the same JVM for performance reasons.
For Rails, JRuby can run Rails, and you can have it in a Java EE container providing fast communication between components.
Having multiple architechtures which do not run in the same process requires you to do network based communication which takes much, much longer than just passing a reference to an object (I do not expect you to want to use shared memory).
Twitter.com is supposedly using a Java backend, and Rails for their web interface. Here are some resources:
http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/
http://blog.adsdevshop.com/2008/05/02/twitter-is-not-abandoning-rails/
http://twitter.com/#!/ev/status/801530348
More specifically, they use Scala on the backend (which compiles to Java byte code):
http://www.artima.com/scalazine/articles/twitter_on_scala.html
I don't think there is anything wrong with this approach. However, you will be supporting two different platforms/VMs. I have seen this kind of situtation result in a sort of fracturing of expertise within an organization. And you end up paying to a lot to have two sets of expertise in house.
If the problem of segmenting expertise concerns you, I would suggest running JRuby of Rails. It is very mature now - and runs better than Rails on Ruby 1.8.x.
We have used Ruby on Rails for front-end and Core-Java SOAP Api for backend. It worked very well.
The main issue is not with performance but with the people. It is very difficult to hire expert people in Ruby on Rails for everything, instead you hire few or you can easily mould to just learn Rails UI.
As startup point of view, it is best strategy. So many believe ROR is best for startups... but very few knew it because in most of MNC's we use Java, so there is pressure to learn Rails and Code, or hire very few ROR developers. So instead you can use ROR for frontend (only few people do that, or it is easy to learn) and use experienced Java developers for DB updates and business logic.
Currently, the XACML specification defines a protocol for request / response but leaves it up to interpretation as to how it can be integrated into an enterprise application. I believe that the value of XACML won't be realized unless there is the creation of a new open source project that attempts to develop/standardize around a set of common APIs.
For those who are familiar with XACML, I would love to understand their first reactions to creation of such a project, whether they would be willing to contribute and what they believe an XACML API would look like?
Maybe I don't understand the question, but doesn't the SAML profile for XACML do what you want? It defines SOAP formats for authzDecisionQuery and response records, which should be all you need for the WSDL.
I built one of these around Sun's interpreter for DOD/DISA (its on forge.mil), and a much faster version (not relesed yet) around a fully compiled implementation that directly transforms XACML into Java code. The main goal was readability, not speed, but its about ten times as fast.
IMO XACML works but is absolutely terrible as a language for people to look at. I'm more interested in finding a problem-specific language for expressing XACML's semantics so that people can understand them. Java beats XACML for this hands down, but Java's pretty clumsy as a domain-specific language. Perhaps Groovy?
PS: As our first shot at this we tried Attempto Controlled English (ACE). We quickly dropped that idea when we found ACE has nothing viable for expressing deeply nested conditionals (no parentheses or braces). And I'm not sure English was the right idea for this anyway, inspite of strong NSA interest in english-based policy languages.
Doesn't Sun's XACML Implementation give you a solid API?
http://sunxacml.sourceforge.net/
(The development is back on track and the site should be updated soon. Hava a look at the sunxacml-devl mailing list.
sunxacml is not actively maintained.
The last update on the page/implementation is from year 2006.
An actively maintained open source XACML implementation is the HERAS-AF XACML Core.
SAML profile for XACML and WS-XACML specifications are attempts to standardize the communication between XACML PEP and PDP. WSO2 Identity Server is an open source project and will adding this support by early next year..
Thanks...
WS-XACML is long dead unfortunately. SAML profile of XACML is today the only standardized approach but that's more about the communication than the ease of use of APIs.
At Axiomatics we did develop a simple SDK but it remains our fairly vendor-specific.
I know that there is a strong initiative called OpenAZ pushed forward by Oracle and Nextlabs. They are aiming at defining simpler APIs for PEPs. That is probably what you would want to look at.
Links:
Axiomatics simple SDK demo: http://www.youtube.com/watch?v=Z_2M775uFxo
OpenAZ: http://openliberty.org/wiki/index.php/OpenAz_Main_Page
James, I would seriously look at OpenAZ. There is a call every other week on Thursdays which you are welcome to attend.
I want to move a legacy Java web application (J2EE) to a scripting language - any scripting language - in order to improve programming efficiency.
What is the easiest way to do this? Are there any automated tools that can convert the bulk of the business logic?
Here's what you have to do.
First, be sure you can walk before you run. Build something simple, possibly tangentially related to your main project.
DO NOT build a piece of the final project and hope it will "evolve" into the final project. This never works out well. Why? You'll make dumb mistakes. But you can't delete or rework them because you're supposed to evolve that mistake into the final project.
Next, pick a a framework. What? Second? Yes. Second. Until you actually do something with some scripting languages and frameworks, you have no real useful concept of what you're doing. Once you've built something, you now have an informed opinion.
"Wait," you say. "To do step 1 I had to pick a framework." True. Step 1, however, contains decisions you're allowed to revoke. Pick the wrong framework for step 1 has no long-term bad effects. It was just learning.
Third, with your strategic framework, and some experience, break down your existing site into pieces you can build with your new framework. Prioritize those pieces from most important to least important.
DO NOT plan the entire conversion as one massive project. It never works. It makes a big job more complex than necessary.
We'll use Django as the example framework. You'll have templates, view functions, model definitions, URL mapping and other details.
For each build, do the following:
Convert your existing model to a Django model. This won't ever fit your legacy SQL. You'll have to rethink your model, fix old mistakes, correct old bugs that you've always wanted to correct.
Write unit tests.
Build a conversion utility to export old data and import into the new model.
Build Django admin pages to touch and feel the new data.
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
Plan your URL's and view functions. Sometimes, these view functions will leverage legacy action classes. Don't "convert". Rewrite from scratch. Use your new language and framework.
The only thing that's worth preserving is the data and the operational concept. Don't try to preserve or convert the code. It's misleading. You might convert unittests from JUnit to Python unittest.
I gave this advice a few months ago. I had to do some coaching and review during the processing. The revised site is up and running. No conversion from the old technology; they did the suggested rewrite from scratch. Developer happy. Site works well.
If you already have a large amount of business logic implemented in Java, then I see two possibilities for you.
The first is to use a high level language that runs within the JVM and has a web framework, such as Groovy/Grails or JRuby and Rails. This allows you to directly leverage all of the business logic you've implemented in Java without having to re-architect the entire site. You should be able to take advantage of the framework's improved productivity with respect to the web development and still leverage your existing business logic.
An alternative approach is to turn your business logic layer into a set of services available over a standard RPC mechanisim - REST, SOAP, XML-RPC or some other simple XML (YAML or JSON) over HTTP protocol (see also DWR) so that the front end can make these RPC calls to your business logic.
The first approach, using a high level language on the JVM is probably less re-architecture than the second.
If your goal is a complete migration off of Java, then either of these approaches allow you to do so in smaller steps - you may find that this kind of hybrid is better than whole sale deprecation - the JVM has a lot of libraries and integrates well into a lot of other systems.
Using an automated tool to "port" the web application will almost certainly guarantee that future programming efficiency will be minimised -- not improved.
A good scripting language can help programming efficiency when used by good programmers who understand good coding practices in that language. Automated tools are usually not designed to output code that is elegent or well-written, only code that works.
You'll only get an improvement in programming efficiency after you've put in the effort to re-implement the web app -- which, due to the time required for the reimplementation, may or may not result in an improvement overall.
A lot of the recommendations being given here are assuming you -- and just you -- are doing a full rewrite of the application. This is probably not the case, and it changes the answer quite a bit
If you've already got J2EE kicking around, the correct answer is Grails. It simply is: you probably already have Hibernate and Spring kicking around, and you're going to want the ability to flip back and forth between your old code and your new with a minimum amount of pain. That's exactly Groovy's forte, and it is even smoother than JRuby in this regards.
Also, if you've already got a J2EE app kicking around, you've already got Java developers kicking around. In that case, learning Groovy is like falling off a ladder -- literally. With the exception of anonymous inner classes, Groovy is a pure superset of Java, which means that you can write Java code, call it Groovy, and be done with it. As you become increasingly comfortable with the nicities of Groovy, you can integrate them into your Java-ish Groovy code. Before too long, you'll be writing very Groovy code, and not even really have realized the transition.
I have a java back-end that needs to expose services to clients running in the following environments :
J2ME
Windows Mobile
iPhone
I am looking for the best tool for each platform.
I do not search a technology that works everywhere.
I need something "light" adapted to low speed internet access.
Right now I am using SOAP. It is verbose and not easy to parse on the mobile. The problem is that I have not seen any real alternative.
Is there a format that works "out of the box" with one of these platforms ?
I would rather not use a bloated library that will increase tremendously the download time of the application.
Everybody seems to agree on JSON. Does anyone has implemented a solution based on JSON running with Objective-C, J2ME, Windows Mobile ?
Note : so far the best solution seems to be Hessian. It works well on Windows Mobile and Objective-C/iPhone . The big problem is J2ME. The J2ME implementation of Hessian has serious limitations. It does not support complex objects. I had written another question about it.
If you have any ideas, there are very welcome.
JSON is fairly compact, and supported by most frameworks. You can transfer data over HTTP using standard REST techniques.
There are JSON libraries for Java, Objective C, and many other languages (scroll down). You should have no problem finding framework support on the server side, because JSON is used for web applications.
Older alternatives include plain XML and XML-RPC (like SOAP, but much simpler, and with libraries for most languages).
Hessian. http://hessian.caucho.com. Implementations in multiple languages (including ObjC), super light weight, and doesn't require reliance on dom/xml parsers for translation from wire to object models. Once we found Hessian, we forgot we ever knew XML.
REST + XML or JSON would be a good alternative. It is making big strides in the RIA world and the beauty of it is in it's simplicity. It is very easy to use without needing any special tooling. SOAP has it's strong points, but it works best in an environment with strong tooling support for it. I'm guessing from your question that's not the case.
Seconding JSON. I ported the Stringtree JSON reader to J2ME. It's a single class JSON reader that compiles into a 5KB class file, and directly maps the JSON structure into native CLDC types like Hashtable and Vector. Now I can use the same server for both my desktop browser AJAX frontend and my J2ME client.
How about plain old XML (somewhat unfortunately referred to as POX)?
Another very useful option would be JSON. There are libraries for every single programming language out there.
Possibly, since you are working in an environment that is constrained in terms of both computing and networking resources, and with a statically typed language, Google’s protocol buffers would be preferrable for you. (Just disregard the RPC crud in there; RPC is an attractive nuisance, not a useful technology.)
The problem with your question is that you haven’t provided a whole lot of context about what kind of data this is and what your use cases are, so it’s hard to speak in anything but very vague generalities.