Develop Reference

Converting desktop application into server + browser application

I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo

If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf

SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.

Middleware & SOA by Example

I am an inexperienced Java developer trying to wrap my head around some fundamental middleware/SOA concepts and technologies, specifically:
Service-Oriented Architecture (SOA)
Message-Oriented Middleware (MOM)
Message Queue
Apache Camel
Mule
EJBs
Endpoints & Routes
Service Bus/ESB
JMS
After looking each of these up online/on Wikipedia, I was able to get (for the most part) decent definitions for each of these. What I am not understanding is how all of these technologies/concepts work together on the backend to provide a 2nd/business tier solution.
Can someone please give an example of an architecture that would use all of these technologies/concepts, and explain what role each of them play in the overall solution? Once I see a working example I'm sure it will help me connect most of the dots.
Edit: Since I added the bounty, I've had several answers that suggest reading books. Although I appreciate all feedback here, I simply can't part ways with 300 reputation points for an answer that, essentially, boils down to "RTM" (especially when I'm flat broke and can't afford the manual!) To reiterate, the bounty and definitive answer will go to someone who can hit all of these bullets in a meaningful, practical example. This does not have to be a middleware compendium!!! Just a paragraph or two that shows how all these can be used together in harmony to produce a Java business-tier solution. Thanks again.

SOA main principles: Build systems as set of services where each service is
Coarse-grained
Interoperable
Loosely coupled
A company offers a lot of business services (coarse-grained) developed over many years and exposed to the users (human or other systems) in some form. There are more chances that each of these features have been designed and developed not keeping the above three principles in mind. Moreover, each of those features might be running on disparate heterogeneous platforms, using different technologies etc.
What if you want to integrate these disparate features thus creating new solutions (For e.g. Amazon store front is a new service composed of their catalog service, shopping cart service etc)?
You have two choices:
Building the new feature from scratch keeping the 3 principles in mind. But it is a very costly endeavor, and one that’s almost never successful.
An effective and less risky alternative is to assemble/compose it from existing, proven (well tested) services.
Option 2 is where ESBs can help with their support for routing, transformation, monitoring etc. Apache Camel, Mule are open-source ESB's. Endpoints & Routes are the terminology used in EIP (Enterprise Integration Patterns) that these ESB's implement. ESB's can take help of MOM's (Message-Oriented-Middleware) when they want to route/integrate services that are running on heterogeneous platforms (For e.g. the catalog service might be running on a mainframe system but the shopping cart is implemented using stateful EJBs running in a Java Application server). Message queue is a concept in MOM that acts a temporary storage of the message between the sender and receiver. This temporary storage provides lot of benefits like asynchronous delivery, guaranteed delivery etc. There are several different MOM vendors like IBM (WebSphere MQ), open-source ActiveMQ etc. We can use JMS to keep your code independent of the vendor.
I tried to relate all the concepts with an example. I also tried to keep it short. Please
ask follow up questions to gain more understanding.
MOM is not a requirement to implement SOA. For e.g. if all of your services are exposed over SOAP via HTTP then you don't need a MOM in this case.

Java classes/example for every tech. might not be possible in single post because what you asked is evolution industry went through in last decade and still evolving. So, what happened over last decade can not be covered in one post. However, its good to understand how it went through this phase and why new technology stack required and what kind of problem it solves.
EJBs
Enterprise Java Beans serverside component architecture. It enables rapid and simplified development of
1) distributed(where multiple application server talks to each other, server components(e.g. service calling other service hosted on different server).
2) transactional - persistance bean (DB TXNs), most important part of any simple/web/distributed application. Easy development e.g configuration base. Write XML which takes care of the transaction e.g. when to commit, when to roll back(on exceptions) etc. JPA Java Persistance APIs provide object relationship maping. Such as your table row is mapped to your java object through the xml configuration.
3) secure - authentication(uid/pwd) and authorization(role based- who is logged in user and what all task he can do?).
This looks good at one point to develope any enterprise application however it has got some disadvantages e.g. its very heavy (all jars included in it.). Classes used as bean should confirm to EJB standards (classes should have implemented certain interface for EJB engine to understand which type of bean it is).
To overcome such scenarioes, there are many alternatives are available in industry for EJBs e.g Hibrnate does same things such as OR mapping, TXN handling same provided by persistance bean in EJB. Spring, light weight framework and simplifies business logic (you can use your already build class which need not to implement any interface, checked exceptions or extends some of the mandatory abstract classes).
Now a days, most of the compnies realy on the light weight frame work such as Spring, Hibernate, IBatis, Axis-2.
Service-Oriented Architecture (SOA)
Service Oriented Architecture is an answer to the platform independence at the enterprise level.
OR
To integrate your application faster, to communicate between different application server.
Just think that you want to implement solution where you are providing option for hotel booking all over the world. Your requirement is to check availability of rooms in those hotels. Now, it means that you need to interact with multiple hotel applications at a time. It's not necessary that every hotel is using same standard or their application(server, programming language) may be deployed on the different application servers. At a same time, its not practical to write different applications which can talk to all different type of the application server. We need some standard based solution which can solve this problem. It's possible through the Web services.
It is possible because web services are sending message in the SOAP(Simple Object Access Protocol), based on the XML. XML is used to interchange data across any language, platform or network protocol.
Web services can be classified SOAP Based and REST.
SOAP based service JAX-RPC and JAX-WS (http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html)
Web services can be developed
contract first - first write WSDL.
code first - first write code.
Now, lets talk how to start for the web services practically.
Simplest web service or hello world(JAXWS) can be written as follows:-
http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/
Message-Oriented Middleware (MOM)
JMS
Message Queue (Point-to-Point)
MOM is required to over come disadvantages of request-response style communication. Server need to be alive when client sends response. Client wait for response till server executes and respond back.
Request response - application will fail if server or client is down.
MOM - Either of the end point is not required to be on time you send the request message for the processing.
MOM is concept and JMS is specification on this concept. Many vendors have implementation of this specification e.g IBM has MQ, OpenJMS open source implementation, EMS from Tibco etc.
JMS specification has majorly two patterns. Pub/sub and ponin-to-point.
Pub/sub is topic, your application want to publish certain information to all the interested parties. e.g. dash board. (Stock application want to notify certain message to all the registered listeners).
Point-to-Point communication is done through message queue.
Business use case- think you have application e.g customer request to the customer care. Other side you have multiple customer care representatives and other side customers sometimes more than customer care representatives, at a time one and only one representative will get the request to be processed and he/she will not get next request until finishes the task. (Same one queue multiple windows and which ever window is free will process the request). You can think of other complexity in this e.g what if one of the node is failed, request not processed and particular type of request needs to be process by particular node. etc.
Produce code:- http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java
Consumer synchronous code:- (POJO classes)
http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java
http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm
Consume asynchronous code:- (Spring by example - reads message from destination till program will not be stopped.)
http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html
Though, its just basic there are many aspects to be covered in this MOM e.g. what's fail-over mechanism, what is selector, durable message, message acknowledgement modes etc...
Service Bus/ESB
Endpoints & Routes
Apache Camel
Mule
Now, lets say you have adopted SOA and MOM long back and you have bunch of services which talks to each others to accomplish enterprise wide task. Imagine to manage logic such as multiple destination whom should be redirected from where will be very cumbersome. Some people call this application logic. Service buses will be used to reduce application logic and focus more on the business logic(functionality provided by app).
In Simple words, consider End point as URL exposed on server. You will use this url/end point to invoke your service.
e.g.
http://localhost:8888/Context/MyService?wsdl
in code:-
String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";
// Add a port to the Service
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
HelloWorld hw = service.getPort(HelloWorld.class);
System.out.println(hw.sayHi("World"));
Routes
When service bus receives particular message, it will route it through no of services/broker destinations such as queue/topics. This path is known as route.
E.g your stock application has got some input by analyst, it will be processed through the application/web component and then result will be published to all the interested/registered members for particular stock update.
Apache Camel and Muel http://camel.apache.org/how-does-camel-compare-to-mule.html
provides solution for the enterprise integration.

Enterprise Integration Patterns can help you understand how everything fits together.
[update:] Your follow-up question on another answer made me realise that you're confused about specific products. That's partly because software in practice tends to map to more than one concept and partly because different companies argue that they provide "everything", when really they don't.
The ESBs are toolkits / libraries that let you connect everything together. They are neither the services themselves, nor the messaging implementations, but the goo that fills the odd little gaps in-between. If you were writing everything from scratch you might not even need one, because what they are best at is fixing the mismatch between a whole pile of different technologies, and if you are starting from scratch you can avoid that mess.
The services are, well, the services. You might use some EJBs when implementing one (I only mention this because for some reason you include them in your question).
The messaging middleware is software that gets messages from A to B. That's extremely useful, but also complex, and everyone and their brother has invented their own. So you need some abstraction that lets you avoid lock-in. That can be an ESB or, if you are all-Java then it can be JMS. But even when you are all-Java with JMS you may still want to use an ESB because they are libraries of all the bits of Java code you would still need to write (random bits of routing logic, message reformatting, etc etc).
Hope that helps. My original answer is more about the abstract patterns that you build with these tools - when you're wiring things together the same problems come up again and again.

Endpoints & Routes: where the information comes from and goes to.
Message Queue is one type of endpoint. The other type is a Message Topic.
An endpoint is a 'logical name for a thing', e.g. PRICE.MSFT, that is used by a publisher or consumer application to get things from or send to. Topics deliver information to everyone subscribed (one-to-one or one-to-many), queues deliver messages to the first one that gets it (usually one-to-one). Forget about Queues, everything can also be done with Topics and topics have several advantages.
Message-Oriented Middleware (MOM): the software infrastructure that delivers information between topics or queus. It is 'message-oriented' not 'packet oriented' as TCP is. So each information blob is delivered in one, hopefully self-describing, message. The implementation of your MOM then gives you an API where you can do things like msg.get("bid")
JMS and AMQP are examples of a MOM specifications.
MOM implementations are the real products that implement these specs:
TIBCO EMS, Websphere MQ, MSMQ, Solace, and many, many others
Apache Camel - very interesting approach on how to configure workflows in this MOM world. But a more advanced concept.
Service-Oriented Architecture (SOA), Service Bus/ESB are just new buzzwords words for what used to be called EAI (Enterprise Application Integration). They are recommendations on how to use 'MOM's and a way to pay high-priced consultants.
What 'ESB' adds to a MOM is the idea of thinking of your publishers as 'services' providing a service. In other words: don't think too much about what one consumer wants right now. There might be 5 consumers in the future and that publisher should provide a service, not 'create information that consumer A wants'. (It'll become clearer once your architecture has grown to 5+ applications). Also you should have some common object model, maybe in XML to make things simple between applications.
Mule - one form of ESB, but its' not exactly main-stream. In 5 years, most middleware action might have been moved to AMQP or something else entirely.
EJBs: Sun's idea of sophisticated Java classes that run in a container. Supposed to make application development easier. But in many cases it made things more complex. A better alternative would be 'Spring' - but EJB's are about something else (not just MOM). Its more about how to develop bigger applications (see IoC pattern).
If you are looking on where to start: I would recommend learning about JMS (all other MOM's are simliar and JMS is the basis of EJB's/ Mule, ...) and, unless you have super-high performance requirements, consider messages to be a TextMessage containing XML. Most tools are available in that area. Or even simpler but less sophisticated, a MapMessage with key/value pairs.

Taking all of your requirements and packaging them into a query, I came across an excellent case study that should meet your needs:
Service Oriented Architecture: An Integration Blueprint
I went ahead and fulltext searched the book using Amazon's "Search Inside This Book" feature. It covers all of the integration cases you've discussed, appears to be thorough, and steps you through the entire design and implementation process.
I'm embarrassed to state I haven't read through this myself, but I highly recommend using the same tools I did to see if it fits your needs before investing in a copy. It seems more thorough, more complete, and more helpful than simply foisting you on a whole lot of incomplete documentation or spooling out content into an answer here.

You mix a lot of different concepts and technologies with different abstraction levels. But all of your concepts have something to do with (enterprise) application integration. I will try to comment your definitions:
Service-Oriented Architecture (SOA)
SOA provides a set of principles and methodologies to integrate existing applications as loosely coupled units. From the Enterprise Integration Patterns (see below): "SOAs blur the line between integration and distributed aplications".
Service Bus/ESB
The ESB is a main concept of SOA to reduce the dependencies within the applications in a SOA. Instead of a lot of dependencies between the applications each application is connected to the ESB.
Message-Oriented Middleware (MOM)
MOM is a infrastructure for sending and receiving messages between distributed systems. This is used to integrate applications. MOM was the golden hammer before the SOA hype came up. Since both are useful, big integration suites provides both ESB and MOM (or use MOM inside their ESB).
Message Queue
A message queue is just a technical detail aspect in MOM architecture. When message sending/receiving is decoupled, message are stored in queues until the recipient is ready.
Apache Camel
When the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions hit the market, some software solutions have been created which provides implementation for the patterns in this book. Apache Camel is one of them. Camel is also a part of Apache ServiceMix which is also an open source ESB. FuseSource and Talend are packaging Apache ServiceMix, Apache Camel and Apache Active MQ (MOM) to bundles with commercial support.
Mule
Mule is also an open source ESB and integration platform.
EJBs
From Wikipedia: Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications. This means EJB is a component within an application and has primary nothing to do with integrating applications.
Endpoints & Routes
When you work with Apache Camel you are designing routes between endpoints, see a tutorial. In short, message are entering/leaving your system via endpoints and are processed in a flow defined by a route.
JMS
JMS or Java Message Service is a Message Oriented Middleware (MOM) with an standardized Java API.

Enterprise Application Integration (EAI) is key to connecting business applications with heterogeneous systems. Over the years, architects of integration solutions have invented their own blend of patterns in a variety of ways. But most of these architectures have similarities, initiating a set of widely accepted standards in architecting integration patterns. Most of these standards are described in the Enterprise Integration Patterns Catalog available at: http://www.eaipatterns.com/toc.html.
WSO2 ESB
WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.

Websockets Server in Java (or PHP)

I could need your experience according server implementations for the currently evolving Websockets in HTML5. We want to use this technology for a project using common webbrowsers on the client site. What we now need is a webserver that feeds our requirements. These are:
written in Java or PHP since these are the languages which currently are used and mastered by all the programmers in the project. Since it seems that there are no promising PHP implementations yet, I tend to concentrate on the Java site.
as fast as possible. We don't expect too heavy usage in production but we need to be able to synch two browsers on independent host in nearly real-time.
easy expandable. We will need to implement our own protocol on top of the websockets so we would like the most possible flexibility.
easy to use, well documented and actively developed. Since we have to come to a first running implementation rather quickly and since I expect some changes in the developing people during the time, it would be great if it's not to hard to get into the server programming.
I already had a look on some servers/frameworks which look promising, e.g. Jetty, Netty and jWebSocket. I also found some older discussions of this topic. However, I would be glad about some current experiences or recommendations of those of you who already have used Java (or PHP) to work with Websockets. Is there some implementation which is especially well-fitting or one that we absolutely shouldn't use?
Edit:
For clarity: When I speak of implementing our own protocol on top of Websockets I mean having some kind of plugin mechanism so that we can use a Websocket to send XML-messages to the server and then use a plugin to interpret them into some server actions as we like. I guess every server implementation also supports this but it would be good if it was not too difficult to write such plugins.

I don't have any experience with PHP so I'll give you my opinion for the Java (and python side).
For Java:
You have your very common and safe choice of Tomcat. It's one of the most actively developed servers, its open source, lots of support/help from its very large community, from what I've read (but not tested) it can be fairly scalable and it also has a very mature console to monitor different metrics for your website.
You also have other choices such as Caucho's Resin, who have a very small yet smart team who actively develop their webserver. Their new heartbeat service allows a good degree of scalability (again from what I've read).
And then you also have Google's appengine which is all about scalability. Their API (for both, the server and client side) has started to focus on realtime web applications so it's a bit easier to for creating high performance web applications without having to worry about the server related optimization that you often have to make with other servers. They have APIs for creating "channels" between the server and client side for very realtime applications. The AppEngine team also has a new MapReduce API for analyzing data quickly/efficiently. For these reasons and the personal opinion that they are pioneering new web technologies/standards, I'm personally been leaning towards AppEngine. It's free if you're keeping cpu/data usuage low but if you need full scale deployment it does start to get pricey so do research. If your project is more for fun/school, its free quotas are enough and all its development tools/APIs are free so it's perfect.
For Python:
I'm more Java than Python, but Python is definitely a great language and very very very easy to learn. And the reason I'm recommending Python for consideration here is because AppEngine also allows developers the choice of Python. The author/creater of the Python language is now on the AppEngine team so, even though the Python and Java APIs are pretty much exactly the same, they sometimes have new/better APIs for Python. For example, I think the datastore API offered with Python is a bit easier and optimized for the Google datastore. Also, since you'd be using python, you can use Django with AppEngine.
The second choice that I've recently become aware of is the tornado web server which was developed by FriendFeed and then bought and used by Facebook. It's also actively developed. But the reason I bring this up is that Tornado's focus, much like AppEngine's, is high web application performance and scalability. I have no experience with it but I've become interested in its technology simply because no one can contest that Facebook requires a very high performance/scalable web server.
Some last thoughts:
In general you'll find that it isn't very difficult to build your own protocol on top of the APIs provided from most web servers (even Asp.NET MVC). But from what I've been able to test around with AppEngine, it really focuses on being flexible on what kind of protocol is build on top of it. To me, its pretty much just feels like a RPC server which which works on top of HTTP. And that becomes even more apparent if you use Python just because of some of the language constructs.

PHP to Java migration

We are occasionally in a position to take over PHP based projects, but as we are a Java-house we are searching for ways to turn a PHP-project (or codebase) into a Java-project.
The approaches we came up to work in a mixed Java/PHP context are :
PHP in frontend and Java in backend with separate front (PHP+JavaScript) and back (Java+SQL) teams
using both technologies in a Java webapp, for example via Quercus with one or multiple teams
migrating everything to Java
We haven't tried any of these approaches as we've been lucky enough to have enough Java-only projects to work on.
Do you see other approaches, or have you tried any of the described approaches?

I've used Quercus. I think that if it supports something like Drupal then it's probably fairly mature. If your PHP app works out of the box, then it offers you a very gradual upgrade path to Java since you can write your own plugins in Java and expose them to the PHP layer, such as using a JDBC back-end.
How easy it is all depends on how well separated the layers are in the PHP application. For example, if the view layer is well separated, you might be able to replace both controller and model logic with a Spring MVC application that uses a 'QuercusView' for the view - you may be able to re-use a lot of the PHP view logic.
You should also consider how you can make a survey of the PHP code - maybe a script that extracts all the function calls, imports etc. so you can quickly test the Quercus support for them.
Sorry, I haven't used the PHP-Java bridge, but I think the Quercus library is pretty mature these days, so that would be my first choice for a staged migration.

My experiences with Querces are not so good. Maybe it has improved, but when I tried it something like two years ago (a long time, I know) it was far from complete and did not support all functions yet. Also, if your application is using some extensions (e.g. from PECL) you will experience difficulties getting this up and running under Querces.
We're currently in the process of migrating a web application from PHP to Java. We're designing a SOA and we'll probably replace some data access objects in the PHP application with a version that talks to internal webservices. Currently we're using Thrift as protocol for our internal webservices, a framework that also has a client available for PHP. We expect this to increase flexibility during migration (allowing us to do step-by-step migration, rather than all-at-once)

PHP/Java Bridge may be of your interest:
The PHP/Java Bridge is an
implementation of a streaming,
XML-based network protocol, which can
be used to connect a native script
engine, for example PHP, Scheme or
Python, with a Java virtual machine.
It is up to 50 times faster than local
RPC via SOAP, requires less resources
on the web-server side. It is faster
and more reliable than direct
communication via the Java Native
Interface, and it requires no
additional components to invoke Java
procedures from PHP or PHP procedures
from Java.

NUMITON may be useful for you:
http://java.dzone.com/announcements/automated-translations-php-jav
The shortest route from PHP to Java
Numiton offers an automated alternative to migrating PHP codebase. This way,
established applications can benefit from the advantages offered by Java in its
enterprise-level capacity.
Some of the risks inherent to any software migration are avoided by using an automated
translation tool. Our PHPtoJava product performs variable type inference,
objectualization and other operations in a uniform manner, the resulting appearance and
behavior being identical to what the users already know.
Of course, the human factor still plays an important role in the post-translation
phases: application fine-tuning and functional testing. The speed and accuracy of the
entire process surpass however those of a manual translation.
One of the applications we have migrated this way is the well-known forum engine
phpBB. The translation result, nBB2, powers our own forum and was recently donated to the
open-source community as a SourceForge project.

PHP in frontend and Java in backend
with separate front (PHP+JavaScript)
and back (Java+SQL) teams
This is technically feasible using SOAP.
using both technologies in a Java
webapp, for example via Quercus with
one or multiple teams
I have no idea about this
migrating everything to Java
This is better option, but it will take time depending on the size & complexity of your project.

I do not have any experience running PHP inside a JVM, but I am betting that IBM does. :)
You might consider Project Zero.
http://www.projectzero.org/php/
Seems similar to Querces or that other thing someone linked. The only other thing that you didn't mention that I can think of is to refactor the PHP code because I'm assuming that its an older codebase written in a PHP 4 manner.

I know this is 2 years old question but i still want to contribute. We are migrating from full java portal to php+java. We have 14 million users. This design doesn't need web services because we use java as json provider for php and js. We will see the result soon...
PHP in frontend and Java in backend with separate front
(PHP+JavaScript) and back (Java+SQL) teams

Benefits of an enterprise service bus

Where can I find some information on the uses and benefits of an enterprise service bus (ESB)?
I am looking for information about:
the kinds of problems and ESB helps to solve
the alternatives to an ESB - and the tradeoffs in selecting between them
what you need to do as a developer to build ESB-compatible systems
I'm looking for a finer level of detail than just Wikipedia or online marketing brochures from vendors. Ideally, some example code would help to clarify what's involved in taking advantage of an ESB. Information from a .NET or Java perspective would be the most useful.
Thanks.

I'd suggest To ESB or not to ESB to start with, written by the creator of Mule.

ESB's are a good way to implement Enterprise Integration Patterns.
Kinds of problems that an ESB helps to solve
You have a number of protocols you'd like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).
Alternatives to an ESB
The alternatives really depend on the problem that you're trying to solve.
To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a 'bus', a client directly calls a server.
To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.
What you need to do as a developer to build ESB-compatible systems
This will depend on the ESB you select, although given that most of the good ones are designed to call out into all sorts of protocols as well as host POJOs, there isn't much you should need to do build ESB compatible systems. It is worth trying to make your code asynchronous.
For examples, Apache Camel probably has the most succinct configuration, here's a tutorial.

Three key advantages:
A bus provides a way for end points to connect to each other without having to directly talk to each other. It simplifies the communications for the end points as they only have to conform to a standard communication interface, the bus. (This is with any technical bus, not just ESBs)
An ESB provides a single place to get some key end point metrics: frequency, availability, and performance.
An ESB tends to provide more than one communication interface. However, a developer only needs to choose the easiest one to get and receive the data from the bus.
However, make sure those will provide business value for your situation. Having an ESB is adding yet another complexity to your enterprise. Ideally you shouldn't choose this based on a few applications, but the entire organization. There should be only one production ESB cluster for the organization.
Alternatives:
Just connect things to each other directly especially if the communication protocols are the same. This is good for simple application clusters and does not require too much thinking. However, as your number of applications grow, maintaining the interconnections becomes difficult.
Another alternative is an MQ implementation. This will provide you with a way of pushing data around without having complex interconnections, but then you are forced to use only one communication channel. Fortunately for Java, they have the JMS standard.
Practicality:
I have stated the possible alternatives. They may seem lousy at first, but it is not to say you cannot start that way. I personally write things to talk to the remote directly without going through an ESB to make sure it works without worrying too much about integration issues.
If you don't have an ESB, I suggest you try Mule for development and WebSphere ESB for test and production. I tend to use two products that supposedly follow standards to make sure we keep the vendors honest and to make sure your developers are conforming to standards preventing inadvertent vendor lock-in.
In the end, just answer the following question: is the time adding the bit of complexity to simplify other complexities your enterprise worth the cost in the long run?

In addition to the sites that were already mentioned. You should read this article on "Don't use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB's available. Not exactly an answer to your question, more of making a point to ask yourself "Do I need an ESB"?

There is a decent 3-part series over at IBM regarding ESB that's pretty concept oriented and vendor agnostic (for the most part). I have found lots of good stuff on ESB by poking around IBM's site. There is also some decent info and videos and stuff over at the BizTalk site.

Check out this Hanselminutes podcast. It answers a few questions that you should really ask yourself before implementing a service bus.

An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.
In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogenous front-end users and information consumers what middleware is really supposed to do: hide complexity, simplify access, allow developers to use generic, canonical forms of query, access and interaction, handling the complex details in the background. The key to ESB's appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by business requirements, not as governed by available technology.
http://searchsoa.techtarget.com/definition/enterprise-service-bus
WSO2 Enterprise Service Bus(Product)
WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.
WSO2 ESB is developed on top of the revolutionary WSO2 Carbon platform, an OSGi-based framework that provides seamless modularity to your SOA via componentization. It includes many features and optional components (add-ons) you can install in the ESB, and you can easily remove features not required in your environment, thereby allowing you to fully customize and tailor WSO2 ESB to meet your exact SOA needs.
Architecture
Application infrastructure on the enterprises may be inherently complex, comprising hundreds of applications with completely different semantics. Some of these applications are custom built, some are acquired from third parties, and some can be a combination of both and can be operating in different system environments.
Integration among these heterogeneous applications is vital to the enterprise. Different services may be using different data formats and communication protocols. Physical locations of services can change arbitrarily. All these constraints mean your applications are still tightly coupled together. An ESB can be used to loosen these couplings between different services and service consumers.
WSO2 ESB is a full-fledged, enterprise-ready ESB. It is built on the Apache Synapse project, which is built using the Apache Axis2 project. All the components are built as OSGi bundles.

Take a look at my presentation "Spoilt for Choice - How to choose the right ESB".
I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.

there is zero reason to use an ESB. Don't do it. Needless complexity. Why go through an intermediary when you can go direct? The ESB folks will tell you point to point is bad, yet somehow point to point to and from the ESB is good.

The first question you need to ask yourself is why do you need an ESB?
ESB is usually used in Event SOA distributed architectures, which seem to be a hot buzzword nowadays. Before you jump into ESB let me remind you of Martin's Fowler First Law of distributing Systems:
http://martinfowler.com/bliki/FirstLaw.html
"My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA).
The relevant chapter is available online."
When you're build a new system, the most important aspect is that it is future proof, that means easy scalability and maintainability. If you build your system around the concept of loosed services with static defined contract distributed in a networked environment, you can "hide" the architecture you want for that particular service, because the interfaces are still there.
ESB is close related to asyn messaging systems, so before you start jumping into that kind of implementation, know that an architecture does not have to be homogeneous, that is all services be implemented the same way, don´t start the biggest mistake which is distributing your system from the start, you should only distribute as you need to scale, no before hand. What you need to make sure though, is that your services should be able to be easily distributed should the need arise, without breaking any contracts which would mean, changes to clients of that service.
As for the benefits of ESB, they are the same as SOA, ESB adds the context of asyn messages (events) operations.

First let me explain SOA. It it about building an architecture as a set of reusable software modules exposed as “Services” with well defined interfaces. The services facilitate loose coupling and abstracts its implementation details from the clients.
SOA might end-up messy if each component called on services directly. Therefore it has following common issues.
How do you find which services are used & which are not?
How do you find the clients using a particular service?
How do you roll out updates to a service or expose new versions to existing services without disruption?
How do you support backwards compatibility for older clients invoking older service interfaces
How do you perform logging, auditing, security enforcement etc across all services for internal / external traffic?
The ESB is the solution to above issues. ESB…
Helps brings in order
Can strictly enforce corporate policies
e.g. Security, throttling, auditing etc applied consistently
Virtualizes service endpoints
Facilitate versioning, flexible updates, HA / Load Balancing etc.
Perform routing, mediation, transformation, etc
Some sample use cases can be found here. Note that they are from AdroitLogic's developer site and strictly coupled with UltraESB, AdroitLogic's ESB.