Let's say I have many web services (REST or normal HTTP request) and I want to define in which order they should be called. I want the order to be easily configured (through XML files) and return error responses in case they are called in the wrong way.
When I say tools I mean some framework in Java. The framework should have good documentation with examples.
I don't want only a name but I would like pros/cons - why should I choose one or another.
EDIT: I forgot to mention it has to be an OpenSource (or any free licence for unlimited usage). And the application will probably run on GoogleAppEngine or Tomcat.
If you want to orchestrate long running processes then what you need is a BPEL engine.. if not you can go for an Enterprise Service Bus..
WSO2 ESB is an open source Enterprise Service Bus and WSO2 BPS is a business process server built on top of Apache ODE.
eBAY using WSO2 ESB to process 1 Billion messages per day.
Disclaimer: I am an architect from WSO2.
You need a Service Bus.
Bea's Aqualogic was a good one.
Pros: integrated with weblogic, support XQuery for message manipulation. Has persistency queues. Flows are defined within it's user interface.
Cons: not so easy to use. Costly.
Regards,
M.
PS: On the pros I would add Bea's good support, but since now they're Oracle I doubt that quality will be high as in the past
EDIT: ops, OpenSource solution needed. So this answer was actually wrong. Sorry.
I am wondering how "WSO2 ESB" or "WSO2 BPS" will address the issues presented in the original question.
The more I look into that project the more it looks to me it is BPEL driven which will probably not play good with "REST/normal http".
I believe Apache Camel should be a good start point.
Related
Our frontend is simple Jetty (might be replaced with Tomcat later on) server. Through servlets, we are providing a public HTTP API (more or less RESTful) to expose our product functionality.
In the backend, we have a Java process which does several kind of maintenance tasks. While the backend process usually does it own tasks when it's time, now and then, the frontend needs to wake-up the backend to execute a certain task in the background.
Which (N)IO library would be ideal for this task? I found Netty, Grizzly, kryonet and plain RMI. For now, I am inclined to say Netty, it seems simple to use and it is probably very reliable.
Does any of you have experience in this kind of setups? What would your choice be?
thanks!
Try to translate this document which answer to your question.
http://blog.xebia.fr/2011/11/09/java-nio-et-framework-web-haute-performance/
This society, as french famous Java EE experts, did a lot of poc of NIO servers in the context of a french challenge sponsored by VmWare (USI2011). It was about building a simple quizz app that can handle a load of 1 million connected users.
They won that challenge with great results.
Their implementation was Netty + Gemfire and they only replaced the CachedThreadPool by a MemoryAwareThreadPool.
Netty seems to offer great performances, and is well documented.
They also considered Deft, inspired by Tornado (python/facebook) but it's still a bit immature for them
Edit: here's the translated link provided in the comments
My preference is Netty. It's simple yet flexible. Very fast and the community around Netty is awesome.
The company I work for is currently evaluating CoralReactor. It is a commercial software but it has the easiest API I have ever seen for Java NIO. My personal opinion is that Netty makes things too complicated, especially if you want to go garbage-free and single-threaded, which are a requirement for many companies from the finance, advertisement and game industry.
I would decouple them by using JMS, just have some (set of) control queues your backend sits there listening on and you're done. No need to write a custom nio api here.
One sample provider is hornetq. This can be run as an in process jms broker as well, it uses Netty under the covers.
I created a command line interface on a small java application I created for personal use.
For the moment the cli is resided in the same project as the original application but I'm planning to extract it into it's own project, effectively building 2 separate executable jars enabling me to start the cli as needed and query the other running program for information.
I'm trying to figure out the easiest and most lightweight solution to call a remote service, on the same machine.
I looked at spring remoting but many of the provided solutions such as HttpInvoker, Hessian/Burlap, JAX RPC web services are based on HTTP or SOAP and therefore not suited for the job.
JMS also seems like overkill.
This leaves me with RMI, which looks rather heavyweight, and possibly JMX?
Suggestions?
JMX would use RMI underneath for remote access. JMX is meant for exposing admin apis (monitoring / management) - not intended as a general purpose remoting api.
RMI with the spring remoting support is fairly lightweight from a development point of view. Even runtime it is the option that adds least overhead compared to the other options you have listed.
Also with spring remoting support you can easily switch over to a different option if required later.
Take a look at this artcile, that compares / benchmarks performance of the above options.
I'd say it depends very much on where the project/functionality is heading. JMX is easy enough to set up, and you can make use of existing clients/guis to query and set parameters - this may save you a lot of work. It may also allow you system to integrate with monitoring tools out there.
If, on the other hand, the functionality has little to do with managment/monitoring, and more along the lines of pumping data in and out, one option may be Apache MINA. I've used it in the past with great results. But you'll effectively be creating your own protocol ! I doubt that MINA will end up being "less heavyweight" than simple RMI though.
In an app for personal use, I'd go with JMX because it should be the path of least resistance. I've had great experiences with this in the past. You'll be able to get it up and running in minutes, and you won't have to think about what message format to move data in (as long as your beans are Serializable, that is).
Put an interface in front of the remote call, so that later you can drop in another implementation later if JMX turns out to be inadequate.
Starting a new project an e-commerce, that basically consists of two, main separated projects: a core application and a web client.
Core app would act as a service provider, the back-end for the web client (or other clients), exposing all its functionality in REST-ful web service/JSON.
Web client would act as a front-end and a service consumer for the core app.
Both project are mainly based on: Spring, Apache CXF, Maven, and either Tomcat or Jetty.
Git as VCS. CouchDB as the DB. Also a distributed caching system like Memcached.
The principle is to design the project (both core and web) in a way to be scalable and distributable on several nodes on the internet.
Perhaps the subject is too big and complex to discuss in one topic; the idea is to put the main headlines that would assist on making the right decisions before going on with the implementation.
The questions:
Based on the technology stack above, what could possibly be missing or worth adding?
Any books, materials or case studies recommendation that touch on the subject?
On the server side, you should structure your URLs and application state in such a way that they can either be generated statically and served via a web server like apache, or dynamically generated and served by the app server. Static content generation can be a pretty effective, reasonably straightforward way to improve performance. Having your API points to be implementation agnostic is generally a good practice anyways.
High Performance Websites has some great stuff. Also, check out Squid for HTTP caching.
Take a look at CQRS principles. Even though great scalability is only side effect of applying CQRS, it ideally fits for cloud computing which main goal is to provide elastic scalability. Here is a awesome video from Greg Young's class.
PS. Despite most of materials are based on .NET stack, these principles are cross-platform.
#Ellead:Go through Tomcat clustering (session replication) :http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Just take care of singleton objects in spring (keep in mind singleton is per JVM)
You did not mentioned performance and load testing - you should measure performance of your application and scalability too:
How is a single node coping wih high load ?
What performance gainyou get by adding a single node ?
Do no expect or guess anything and start as soon as possible - that alone will save you fortune.
For REST-based solution look at Apache httpd and mod_jk for load-balancing.
Read about Server push here.
I want to push data to client from my web application in real time.
I was looking at TCP sockets as one of the options.
For HTTP I found a variety of frameworks for Java, PHP, Python and others over here.
However I don't know whether any of these support Push.
What options and frameworks would you
suggest for implementing Server push?
What language would you advocate for implementing the same and why?
I'm using Orbited right now, it's great!
If you are doing chat or subscription type stuff use stompservice and orbited.
If you are doing 1 to 1 client mapping use TCPSocket.
I can give you some code examples if you want.
How about Orbited, it's very good and being used by Echowaves
Comet is the protocol you want. What Comet implementation is best, is a harder call.
If you're OK with Java (or, I guess, Jython), or .NET (where IronPython's a possibility), I suspect (not having extensively tried them all!-) that stream hub must be a major contender. It'a typical "freemium" product -- you can get a free ("as in free beer";-) version, or you can try the pricey Web Edition, or the even-pricier Enterprise Edition; feature comparison is here (e.g., free edition: no https, no more than 10 concurrent users, no .NET).
Ok, I'm using ASP.NET with PokeIn comet ajax library on my project. Also, I tried Atmosphere under JAVA.. My last choice was PokeIn.. Because, only server push support is not solving the problems. You will need some kind of client to server object serialization and object life time management. PokeIn covered all these needs for me.
What about Ajax Push Engine?
I'm personally biased, but I like WebSync, for IIS/.NET. It integrates with IIS, so no other server software necessary, just a dll to add to your project.
I believe xmpp implementation is one which is being use by a lot of big companies but the common thing is to use a comet server as well.
a lot of implementation in python for thoses you can google around.
Have you tried StreamHub Push Server?
I have a bunch of Java code which was written using the Hibernate framework, originally destined to have a front end written using JSPs. However, the requirements for the front end have changed, and we've decided that a desktop client (which will be written in .NET) is a better match for our users.
I don't really want to waste the code that's already been written - can anybody suggest a good set of tools for writing a document-based web services interface that we will be able to access from .NET?
Thanks,
Jim
If you truly want a document based service interface (rather than an RPC style web service architecture), your best bet is going to be creating a SOAP based web service interface.
A quick glance at the Java site shows that the Metro stack might help a bit:
Java Web Services at a Glance
We're developing an application with the exact architecture you describe for a finance application. We reviewed several different options, and have finally landed on using compressed CSV over HTTP.
CSV was chosen since the vast majority of data was going to be displayed in a grid on the front end, we had very large result sets >250k rows on a regular basis, and it compresses really really well.
We also looked at using:
ICE, but declined on that due to licensing costs and the need to reinvent so much.
Google's protocol buffers via servlets, but declined on that due to lack of C# support (as of last fall).
Compressed XML using WOX, but declined on that due to lock-in to a small thesis project for support and XML being too verbose.
The industry supports a couple of different options as well:
SOAP, but that has its own well documented issues.
IIOP, J-Integra has a product called Espresso which will allow you to do RMI from a front end.
I'd personally use some lightweight RPC protocol, be it XML-RPC or a homegrown one. SOAP, IMO, is way too fat and is not as interoperable as it's supposed to be. The simpler the better.
We have a quite large application using a Java RMI server and IIOP.NET for interoperability. We have used IIOP.NET with the Sun RMI and the Bea Weblogic (now Oracle) without major issues.