|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 32
Messages: 32
Messages: 32
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Simple 4.0 - Java HTTP Engine
The Simple HTTP engine and framework has released version 4.0. Simple is an asynchronous HTTP engine capable of scaling to large loads with a limited number of servicing threads. It employs NIO at the transport layer which ensures it is both responsive and resource efficient. It also has a fully comprehensive API that provides as much convenience to the developer than the Java Servlet API.
- High performance HTTP kernel
Simple has consistently outperformed popular commercial and open source Java HTTP servers. Current benchmarks comparing it against recent versions of Jetty and AsyncWeb show it has signifigantly higher throughput, and scales much better under increasing load. Benchmark Results.
- Asynchronous processing throughout
From the outset the goal of the project has been to provide a truly asynchronous HTTP engine. The service model provided allows request completion to be driven using an internal, transparent, monitoring system. This allows Simple to vastly outperform current Servlet Engines, which require request completion to be driven by the servicing thread, particularly in high latency scenarios where transactions require distributed services.
- Embeddable framework
Simple is provided as a framework, and as such can be embedded in to any existing application in several lines of code. It integrates seamlessly with environments supporting the Spring framework.
- Small Footprint
Despite being highly scalable, Simple has a very small memory footprint. Recent benchmarks show its memory footprint to be almost half that of other lightweight NIO servers, such as Jetty and AsyncWeb.
- Fully Self Contained
It has no external dependancies. Other than a Java 5 SDK or above there are no additional libraries required. This keeps the footprint small and ensures there are no compatibility issues when integrating it in to existing applications.
- Open Source
Released under the LGPL and so can be fully integrated or adapted for both commercial and open source projects.
|
|
|
Message #266384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
Is it an HTTP server only or Servlet container as well? Is it standard-compliant?
I'm just not sure how to interpret the "It also has a fully comprehensive API that provides as much convenience to the developer than the Java Servlet API."
|
|
|
Message #266385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
Hi,
Should have made that clearer, no, Simple is not a Servlet Container, and does not support the Servlet API. For two reasons.
1) The Servlet API is inherently synchronous, an so does not support the concept of true asynchronous events
2) There is already a wide variety of Servlet Containers out there
This project originally started out as a Servlet Container some time ago, however I am not a fan of the API or the service model it advocates. Servlet Engines do not scale well in multi-tier environments where the servicing thread is blocked waiting for a resource to become available or some event to complete. Also, I don't see JSR 315 really making much of an improvement to this. This does however mean there is a little more leg work involved in getting existing Java web frameworks to work with it. However, I intend to adapt several according to suitability to the asynchronous event based service model.
|
|
|
Message #266387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
I am happy to know that we can now run servers in a jiffy. Apart from the fact that it doesnt support Servlet specs, I would like to know if it lends itself to some kind of unit testing/integration testing (The documentation doesnt tell about any).
To be more precise, I want to know what is the developers motive to write a Java based HTTP Engine when we have so many HTTP engines? Is it Unit Testing? Profiling?
|
|
|
Message #266389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
The primary motivation is to provide a HTTP server capable of asynchronous transaction processing. Services implemented around the Servlet API can not scale beyond a certain threshold when service completion is dependant on an asynchronous event. This can be anything from a database transaction to a messaging event. With Simple it is possible to scale to many times (hundreds of times is quite feasable) a many concurrent clients in such an scenario with very little resource overhead.
However, if you want to embed it to use for unit testing this is possible also, take a look at the following unit test, which tests several thousand requests simulating approx two hundred concurrent clients. I use it to test some of the API features of Simple.
PostTest.java
|
|
|
Message #266394
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
quite intersting
A long time ago I was looking to get a .NET app to talk to a Java application, but I had to keep it very lightweight. Another item was I wanted to communicate via a Web Service. A web service really only requires SOAP, however I couldn't find a good small HTTP only engine in Java to service my SOAP interfaces. Of course I could of used any of the servlet containers, but they were too bulky for my task at hand.
This seems quite handy, and if my need to get a .NET app talking to Java in a standards compliant model (Web Services) with the smallest possible footprint, this may be the avenue I'm looking for.
|
|
|
Message #266402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
I am not familiar witht he feature set of xLightweb, so can't really make a good comparison.
I have broken out the Reactor API in to a separate package, this provides simpler access to asynchronous IO than the lower level Java NIO packages. However the vast majority of work done in Simple is directly related to HTTP processing, from state machines to accumulate the request entity to asynchronous events to parallize transaction execution. If your interested you can grab them from.
Reactor Source
Reactor Javadoc
However, you may find it easier to use a more comprehensive API such as Apache MINA for non-HTTP services.
|
|
|
Message #266407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Asynch HTTP overhyped
1) HTTP is a synchronous protocol, not asynch messaging. In most Web apps, adding asynch HTTP will hurt performance and degrade application maintainability.
2) Really, its only COMET-like apps that scale better with asynch HTTP as you have a client blocking on a socket receive for new posted messages. The majority of apps don't need COMET messaging.
4) Asynchronous IO to conserve threading really belongs in the VM. Take a look at Erlang for example. I know JRockit used to support N/M green to kernel threads. No reason this can't be improved on.
5) Many of the Erlang vs. Apache benchmarks were done on old Linux kernels where threads were really expensive.
6) OS's will improve on how many threads they can handle.
7) With multi-core, 64-bit machines, falling memory prices, conserving threads not the biggest deal.
So, with that all said, do you *really* want to complicate your application design with something that will generally have no affect on the performance of your app?
THAT BEING SAID...
I do intend to look at Simple 4.0 as I want to add an embeddable COMET abstraction to RESTEasy. I wasn't too impressed with the code quality of Grizzly when a looked at it 6+ months ago (maybe it has changed a lot?). Also, what advantages would Simple 4.0 have over embedding something like Jetty?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
|
Message #266412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Asynch HTTP overhyped
Hi,
I agree with most of what you have said, in my experience for low loads, thread per requst will probably give you best performance. However, I believe for scenarios where the HTTP server must collaborate with other distributed services Simple will without question provide vast performance gains under high load, and I believe it will make your application both simpler to develop and produce a more elegant result. The only fundamental difference between the Servlet API and that provided by Simple is that you must close the response output stream. Thats it. You can work with it and implement services as you would implement a HttpServlet.
For example, if my HTTP service had to send a request to an out of process Web Service. I do not need to wait for the round trip time of this request to complete. I can simply queue the request for a callback and release the servers servicing thread, then when the Web Service responds I can emit a suitable response to the connected client. So as the client sees it its synchronous HTTP, but internally you can treat the Request and Response as truly independant objects/events. They are not tied to any service model or thread.
With regards to why you would choose it over Jetty, I believe it has advantages in performance, scalabality, and simplicity (see the performance comparison link above). Take a look at the tutorial, it really is very easy to get up and running with it. No web.xml or configuration files to write, you can simple assemble your own HTTP server in a couple of minutes without any dependancies.
|
|
|
Message #266415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Asynch HTTP overhyped
Hello Bill,
I agree with you that there have been huge improvements in implementations of threading the last couple of years. Both at OS and CPU level.
However, CPUs still like doing one small thing very well. Something that fits in their cache. They don't like context switching, synchronization, and moving data to their brothers due to threading. I use brothers here, since in my experience women are much better multitaskers than men are.
For example, if you have to serve 10K requests per second, then you waist a lot of time with context switching using a thread per request model. I don't even know if modern JVMs and OSs support this number of threads. I can remember that Apache had an upper bound below 1K threads, but I don't know if this is still true.
Hence, in general you should minimize the number of threads per CPU/core in order to maximize throughput. Unfortunately this often conflicts with the minimization of latency. And that's where threads come into play...
In other words: it very much depends on the requirements you have and you'll often have to find the right balance.
Grizzly, for example, just uses a couple of threads to accept connections and read the first block of data received. However, it then continues with a thread per request model to read the rest of the data.
Regarding complexity: I can absolutely imagine that it's hard for people to get into Java NIO or asynchronous communication. Therefore it's great that frameworks like Simple, Grizzly, MINA, xSocket, etc exist, since they shield their users from the nitty-gritty details.
For an interesting read on the subject, see the influential thesis of Matt Welsh: An Architecture for Highly Concurrent, Well-Conditioned Internet Services, also know as Staged Event Driven Architecture (SEDA). Matt was also involved in the design of Java NIO.
Regards,
Hans de Boer
|
|
|
Message #266416
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Compliancy
Hello Niall,
Could you please tell me whether Simple is fully HTTP 1.0 and/or 1.1 compliant?
Thanks,
Hans de Boer
|
|
|
Message #266420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Compliancy
Hi,
Yes its fully HTTP/1.1 compliant. One exception is "Expect: 100-continue". Which is not yet supported. It was supported in previous versions however I have found it is very rarely requird. I hope to add it in the next version.
By default it supports all multipart types out of the box as it were. Even recursive multipart lists as used in protocols like MM7 and SOAP with attachments for example.
Niall
|
|
|
Message #266421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Compliancy
Also, just to mention it also supports HTTP/1.0, it works well with both. As required when HTTP/1.1 compliant.
|
|
|
Message #266424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Asynch HTTP overhyped
Regarding complexity: I can absolutely imagine that it's hard for people to get into Java NIO or asynchronous communication. Therefore it's great that frameworks like Simple, Grizzly, MINA, xSocket, etc exist, since they shield their users from the nitty-gritty details.
What I'm saying is that unless you are implementing a message queue, asynchronous coding should not be bleeding into your application codebase.
--
Bill Burke
JBoss, a division of Red Hat
bill.burkecentral.com
|
|
|
Message #266452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Asynch HTTP overhyped
Hello Bill,
Asynchronous communication or event handling implies that you don't block to wait for an event such as a response. Instead you, for example, specify a callback/completion handler that is automatically triggered when the response is received.
This is also very common in other areas, such as GUI frameworks. Imagine that you would have to create a thread for every single GUI element on your screen (buttons, menu items, text boxes, etc) in order to capture events like mouse clicks and typing.
You could even say that in general server side web applications are based on an asynchronous model, since web applications often request the user for a response. For example, when a form is sent to the user, the application doesn't wait for the user to respond. Instead, the form contains an URL to which the form information is sent when the user presses submit. The server uses this URL to dispatch the form submission to the appropriate piece of application logic, such as a servlet. This can very well be seen as a callback mechanism used to implement asynchronous communication.
Hence, asynchronous communication and event handling is all around us. Fortunately many frameworks hide the complexities from us.
Regards,
Hans de Boer
|
|
|
Message #266567
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jetty is doing the same job already
Well its actually not doing the same job, what is proposed in the new Servlet API is quite different to how it has been implemented in Simple. Jetty attempts to wedge in asynchronous functionality to an API which has been historically synchronous. Handling asynchronous events in Simple is completely transparent, you can choose to do it any way you want. Also, on performance comparisons I have performed Simple has about half the memory footprint, scales much better under load and has higher throughput. See the following.
Performance Comparison
|
|
|
Message #266573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
Nial,
Do you plan to build some sort of "adapters" for supporting servlet API then? Or perhaps some popular web frameworks?
I wonder what is your vision of typical use of Simple. What tasks does it fit into better than servlet container does? Do you see it as a complementary server or replacement for servlet container in an typical N-tier application?
Thanks.
|
|
|
Message #266576
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Integration into Tomcat ???
Hi Niall,
is it possible to integrate your Simple into Tomcat as internal HTTP Engine?
I find your concept of ASYNC or NON-blocking while the Threads invoking backend-services so cool.
On Tomcat man can configure the max number of Threads with Thread-Pooling. But they when they receive HTTP request, they invoke backend-services -> they are blocked. So man hat many Threads but they dont really work continuos all.
|
|
|
Message #266588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SEDA stages?
I'm interested in implementing SEDA like processing with Simple. Can you let me know the timing of network interactions with respect to Container.handle being called? ie is Container.handle called before or after the request is fully read from the network. Because if the request is fully read before Container.handle is called then the data must be buffered in memory, which must be handled carefully. But if its streamed in from the network it will be blocking and i'll need to put that into its own stage.
Similarly with the response, is data written to the network as it is written to the response outputStream, or does Simple buffer the data and then transmit it once its complete?
Looks great, by the way.
Thanks,
Brad
|
|
|
Message #266600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Simple vs. Jetty
We used previous version of Simple for our application with velocity templates in web pages.
Recently, I rewrite the application to use Jetty6 with Wicket web framework. The main problem was documentation and community. Simple community is not an active one and also, there are few documents for developing.
Also, I made some primitive benchmarks to compare Simple versus Jetty. I used JMeter and Yourkit on my development PC with 1GB RAM and Windows XP OS.
In high request rate, Simple response was better.
About the thread creation, Jetty in first requests created about 256 threads but Simple just create 50 threads.
The overall throughput of Simple was 30 request/per sec
and for Jetty it was 27 request/per sec.
Anyway, development with Simple is hard. Simple may be good for some custom, specific purpose applications without support of AJAX, session management, security issues and so.
|
|
|
Message #266601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SEDA stages?
Hi,
The Simple and SEDA architectures are comparable, in that there is an event driven approach taken to the stages involved in processing requests. In Simple there are several stages, differing depending on the type of connection. For SSL there is an extra stage for SSL handshakes and SSL termination. Simple is non-blocking throughout regardless of how the data is streamed to the server. Bytes are accumulated as they arrive and each pipeline has a state machine and transport cursor, which enable it to compose a header wihout blocking the collection threads.
Basically it is broken in to two main chambers, the collection chamber collects bytes that form the request header and body, once its been collected its forwarded to the dispatch chamber where the request can be executed. When delivery is complete (not-necessarily when execution has complete) the transport is handed back to the collection chamber so the next request can be collected. This architecture also allows for parallel request processing, which I don't believe SEDA has. Parallel request processing is performed by monitoring the output, when the output has been fully written (according to HTTP semantics) by the service the pipeline is handed back for collection, however the associated service my still be executing, it knows nothing of the pipeline handover and this parallelism can improve performance greatly for pipelined requests.
|
|
|
Message #266603
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple vs. Jetty
Hi,
Not being a Servlet Container makes it difficult to leverage the wide array of existing web frameworks. However I intend to remedy this, and Wicket is currently top of my list. Also, previously the tutorial has been pretty poor and this can pose problems for developers that just want to get up and running. I have currently been adding to the tutorial and plan to add additional sections on how it can bee used as a standalone server and with Spring. Hopefully this will make things much easier to get up and running. Also session management should be much improved in 4.0 as should security.
|
|
|
Message #267303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - Java HTTP Engine
Hi Niall,
Can you publish the configuration settings you used for each of the servers in the comparison?
thanks,
Jan
|
|
|
Message #267346
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Simple 4.0 - also supporting for HTTP Client?
Does Simple 4.0 also support an HTTP-Client? Or is it only a HTTP-Server?
I'm interested in using Simple 4.0 as an async HTTP-Server, but also need an async http-client (to access web-services out-there in the internet)
|
|
|
Message #267371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: Simple 4.0 vs Jetty
Nial,
can you make your benchmark setup for Jetty available?
I fear you may be comparing apples with oranges, as the default setup for Jetty will have a lot of servlet baggage that it sets up for each request (contexts, classloaders,
security and session checks). These are all optional in Jetty and it can be simply stripped back to an async HTTP core plus handler.
If you just want to server a single static file, then Jetty also has a non-servlet handler for that that will flush the file asynchronously using NIO gather writes.
Also, it would be very iteresting to see a comparison of dynamic content generation. Static content is easy, as you can delegate most of the IO work to the JVM/OS.
Finally, what hardware/OS was used for your benchmark. For static content, Jetty makes use of file mapped buffers, which tend to be better implemented on unixes.
|
|
|
Message #267555
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: re: Simple 4.0 vs Jetty
Hi,
Here I am attempting to measure first byte sent to last byte received for an HTTP transaction over an established TCP connection, pipelining a fixed number of requests over each one. I have used a static file to measure the containers performance as it will typically provide best execution times, this is important as it avoids the scenario where the service execution times affect the benchmark. For example, lets say I wanted to measure the performance of Apache, measuring it using a perl based CGI script would not provide an accurate reflection of the servers performance. As the time taken to execute the script would contribute signifigantly to the overall result.
With regard to comparing the performance of each servers ability to deliver dynamic content, this is exactly what I have done. My goal was to measure the performance of Jetty through the Servlet API, as this is how it will be used. Dynamic content is a sequence of bytes, like a static file, however a static file when served through the Servlet API does not contribute as much computational latency to the test. So I am measuring the servers performance, rather than the logic surrounding composition of the dynamic response.
To create a level playing field where I am comparing like for like, I have disabled Jettys file mapping capabilities, as they are not available through the Servlet API. However Simple gained no advantage by using these features either, I measured its performance sending the file contents through a conventional output stream. So I believe this was a fair representation of each servers performance.
If you would like to suggest a configuration to use the test then I will be happy to use it, I am releasing a minor version of the server shortly and will be performing the some performance tests then.
|
|
|
Message #267556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - also supporting for HTTP Client?
Hi,
The code is already there to implement an asynchronous HTTP client, it would not really differ too much from how the core server operates. However, instead of reading the HTTP request line you would be reading the HTTP status line.
The ReplyConsumer provided within the test code can be used to read a HTTP response asynchronously.
|
|
|
Message #308040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Simple 4.0 - also supporting for HTTP Client?
Does anyone have some sample code showing how an HTTP client request could be coded using Simple?
|
|
|
Message #309187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
simple
<br>import org.simpleframework.http.core.Container;<br>import org.simpleframework.transport.connect.Connection;<br>import org.simpleframework.transport.connect.SocketConnection;<br>import org.simpleframework.transport.*;<br>import org.simpleframework.util.thread.*;<br>import org.simpleframework.http.Response;<br>import org.simpleframework.http.Request;<br>import java.net.InetSocketAddress;<br>import java.net.SocketAddress;<br>import java.io.PrintStream;<br>import java.util.*;<br>import java.text.*;<br><br>public class MiniServer implements Container {<br> Scheduler queue;<br><br> public static class Task implements Runnable {<br> <br> private final Response response;<br> private final Request request;<br> <br> public Task(Request request, Response response) {<br> this.response = response;<br> this.request = request;<br> }<br><br> public void run() {<br> long time = System.currentTimeMillis();<br> String tstamp = dFormat("yyyy-MM-dd hh:mm:ss aaa");<br> PrintStream body;<br> try {<br> body = response.getPrintStream();<br> response.set("Content-Type", "text/html");<br> response.set("Server", "MiniServer/1.0");<br> response.setDate("Date", time);<br> response.setDate("Last-Modified", time);<br> body.println("<h2>Hello World - " + tstamp + "</h2>");<br> body.close();<br> } catch (Exception e) {<br> e.printStackTrace();<br> } <br> } <br> } <br><br> public MiniServer(Scheduler q) {<br> this.queue = q;<br> }<br><br> public void handle(Request request, Response response) {<br> Task task = new Task(request, response); <br> this.queue.execute(task);<br> }<br><br> public static String dFormat (String format) {<br> TimeZone tz = TimeZone.getDefault();<br> Date today = new Date();<br> long offset = tz.getOffset(today.getTime());<br> if (offset < 0)<br> offset = offset * -1; <br> SimpleDateFormat formatter = new SimpleDateFormat(format);<br> String datenewformat = formatter.format(new Date(today.getTime() + offset));<br> return datenewformat;<br> }<br><br> public static void main(String[] list) throws Exception {<br> Scheduler queue = new Scheduler(16);<br> Container container = new MiniServer(queue);<br> Connection connection = new SocketConnection(container);<br> SocketAddress address = new InetSocketAddress(8080);<br><br> connection.connect(address);<br> }<br>}<br>
|
|
|
Message #310273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: simple
Thanks for the code, but I wanted to know how to implement a client, not a server. Niall said "The code is already there to implement an asynchronous HTTP client" and I was asking about that since it wasn't obvious.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
