|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 42
Messages: 42
Messages: 42
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Caucho Resin adds PHP
Caucho, the company behind the open source application server Resin and the open Web Services protocols Burlap and Hessian, has recently added PHP to its list of supported features. Apparently, the PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php!
The PHP libraries for this implementation are apparently being written entirely in Java, and it sounds relatively simple to expose your own libraries to PHP code.
With Python, PHP, and CFML supported in a Java application server environment, and the jRuby project not so far behind, it's starting to look like Java is the ideal platform for supporting all of the popular web development languages.
|
|
|
Message #194434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
And now this implementation can follow by the ColdFusion way: add filters and custom tags on the next step. So finally we will see J2EE PHP
Marina
Coldbeans
|
|
|
Message #194437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
But won't that (Java specific PHP) take away from the attraction of PHP? One of the biggest reasons people use PHP is because it can run on just Apache (+ mod).
|
|
|
Message #194442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
But won't that (Java specific PHP) take away from the attraction of PHP? One of the biggest reasons people use PHP is because it can run on just Apache (+ mod).
No, it doesn't take away any abstraction. It's just yet another platform on which you php code runs. (6x faster :-) ). Its just like running PHP on top of IIS.
It doesn't mean you cannot run you php code on apache /mod_php any more.
cheers,
Emil
|
|
|
Message #194453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
If you will wrapp and install java modules as PHP libraries then probably it will run on plain apache web server too. But I do not think it is a good idea, it must be very slow to load JVM per web server process or to use some fake server to run java functions.
This stuff just can help to migrate legacy PHP applications or can help to train PHP developers for j2EE, but opposite doe's not make sence.
|
|
|
Message #194456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP Multi-threaded problems
Ok this may be a very stupid question, and if so I'm sorry for posting it, but:
I heard that most .php guys don't use Apache 2.0, because most of the php libs are not thread safe. So my first question is what about all the php libs, can they also be run in Resin's php server, do you just need to download the source for them and compile them in there too. My second question is by bringing libraries over from regular php to java php how does that affect the multithreaded problems that many/most php libraries suffer from?
|
|
|
Message #194458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Are PHP APIs supported?
I think this is great news.
Does it support the PHP APIs or only the PHP language?
Which version of PHP is supported 4, 5?
|
|
|
Message #194459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP Multi-threaded problems
It looks like, you need to wrapp all libraries yourself and write some kind of descriptor to register static JAVA method as PHP function.
|
|
|
Message #194468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
It doesn't mean you cannot run you php code on apache /mod_php any more.cheers It does if you use things that are not available on apache/mod_php.
|
|
|
Message #194470
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
I'm still waiting for the headline "Is Java killing PHP?"...
SCNR, Lars
|
|
|
Message #194474
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP Multi-threaded problems
Ok this may be a very stupid question, and if so I'm sorry for posting it, but:I heard that most .php guys don't use Apache 2.0, because most of the php libs are not thread safe.
This might cause you problems if you run Apache 2 threaded MPM. Most *nix distros offer preforked Apache 2 binaries by default (as in Apache 1.3.x)). Preforked MPM is also the most performant in my opinion in single processor machines and Apache is usually placed in the front (or in farm) and those machines are usually cheap single processor machines.
And saying "most of the php libs" is false. Most of PHP libs are already thread safe. All libs are not, but those modules are usually written by some 3rd party. I have been running mod_php with prefork MPM and worker MPM in apache 2 and both have been very reliable. I just prefer prefork MPM.
My second question is by bringing libraries over from regular php to java php how does that affect the multithreaded problems that many/most php libraries suffer from?
Resin is threaded by default as I know so if PHP is run on same process (as it usually is in threaded environment) badly behaving PHP module might bring the whole resin down. I'm not sure what php modules resin supports in it's PHP implementation.
|
|
|
Message #194477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
I'm still waiting for the headline "Is Java killing PHP?"
;-)
Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications. If you can support 6x as many PHP users on a Java app server as you can on a "native" Apache server, then why not move over to Java? Thanks to Java and the ingenuity of the Caucho team, the savings in hardware, rackspace, electricity and systems management will add up to millions of dollars for large-scale PHP systems.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #194481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP Multi-threaded problems
Resin is threaded by default as I know so if PHP is run on same process (as it usually is in threaded environment) badly behaving PHP module might bring the whole resin down. I'm not sure what php modules resin supports in it's PHP implementation.
Quercus (the php module for resin) does not load php modules.
Quercus simply provides a "native" java implementation for most php functions.
I already found a few bugs but IMHO they are small bugs with easy fixes. I think/hope we'll soon see a standalone release of the php compiler/interpreter.
Perhaps a BSF implementation is not so far (Quercus already provide the mustang's javax.script.ScriptEngineFactory implementation)
|
|
|
Message #194489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
This is very cool. You could have a PHP frontend and a Java backend very easily.
Steve
|
|
|
Message #194496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cool, but benchmarks?
Cool features, kudos to the Resin crew. Where are the benchmarks showing the alleged 6x performance advantage over Apache 2.0? I couldn't find them on the Resin site or the digg.com report or Cameron's blog entry (where others have asked to see substantiation of this huge performance claim...)
|
|
|
Message #194507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cool, but benchmarks?
From what I understand, PHP can't run on Apache 2 yet. It's not multi-threaded capable yet. You *could* use it, but it wouldn't be completely threadsafe.
I may be wrong by now, my info is a few months old.
So odds are they are experiencing a lot of speedup just from having the ability to run inside a multithreaded JVM.
Steve
|
|
|
Message #194511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
It is hard to believe this implementation is 6x faster, but Caucho produces very good software and it is a very good idea to implement PHP for servlet container.
|
|
|
Message #194512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Apparently, the PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php!
This is just another proof that JVM itself (either Sun, IBM or JRockit) IS VERY FAST, and that various layers/abstractions in some (not all) Java APIs are introducing overhead and slowliness!
|
|
|
Message #194515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
I'm still waiting for the headline "Is Java killing PHP?"
;-)
Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications. If you can support 6x as many PHP users on a Java app server as you can on a "native" Apache server, then why not move over to Java? Thanks to Java and the ingenuity of the Caucho team, the savings in hardware, rackspace, electricity and systems management will add up to millions of dollars for large-scale PHP systems.
Actually, Java is "adopting and extending" PHP ;-).
I think this will be a great way for folks to migrate to a Java solution, but I do not think that we'll be seeing this in the wild from generic PHP hosting providers any time soon.
Simply put, while it's great that Resin can run PHP (and Cold Fusion, for that matter), the Apache/PHP process model is a much safer system from a "general public, idiot user accidently DoSing the system" point of view.
But it's about time this happened. I always thought it was a smart move when ColdFusion jumped on the JVM, and I didn't see much of a reason why PHP couldn't have done the same thing.
The nice thing about this is that it will (ideally) let PHP application integrate much more smoothly with Java systems, and will let those who may feel "trapped" by PHP have a way out into the broader world that is Java.
|
|
|
Message #194524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
You could have a PHP frontend and a Java backend very easily.
Sure! And a php developer can use enterprise class Java libraries simply and efficently! And java applications can now integrate classical php web stuff (php forums, php blogging tools).
|
|
|
Message #194526
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
The benchmark was actually only 4x faster, and was done late at night in preparation for JavaPolis, so take it with a grain of salt. (As with all benchmarks.)
The specific test case was the default mediawiki (wikipedia) home page on installation using "ab", the Apache benchmark program. So, it's a real application, not a synthetic benchmark.
As always, benchmark values will vary widely depending on the application used, configuration, machine, etc, etc, etc.
Warnings aside, it's still an interesting first datapoint.
|
|
|
Message #194528
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
The benchmark was actually only 4x faster, and was done late at night in preparation for JavaPolis, so take it with a grain of salt.
Hei Scott,
can you reply to this questions?
1) what language specification did you implement? PHP4 or PHP5?
2) what is the compatibility status? Fully implemented modules, partially implemented, not implemented.
3) Is there any official/community website for quercus? (I've only found the bugtracker at http://bugs.caucho.com/my_view_page.php )
4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct?
|
|
|
Message #194529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does this version of Resin run ONLY on Java 1.5?
OK, so I downloaded the latest Resin to try this out. It refuses to run on Java 1.4.2, and after downloading the source and checking it out, it does appear that the Quercus piece that provides PHP functionality was written using generics.
I have a bit of a bone to pick with this since the docs that come with resin state it should run on Java 1.4 or higher and say nothing about a requirement for Java 1.5. Something else a bit galling is that the examples given on their site, judging from the output that's listed, give them impression that PHP support has been in for a couple of minor versions now; the messages specially mention Resin 3.0.14. That is likewise a non-starter, as trying to drop back to that version yields zilch in the way of the inclusion of Quercus.
So... for those who have tried this, am I just stuck short of moving to Java 1.5?
|
|
|
Message #194538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
1) what language specification did you implement? PHP4 or PHP5?
PHP 5. I don't believe there's an actual language specification, though. :)
2) what is the compatibility status? Fully implemented modules, partially implemented, not implemented.
We can add that to the wiki (wiki.caucho.com). The details would be too long to post here, since there are lots of PHP modules and functions. We're concentrating on finding and implementing the most-used functions first, so the function/module list looks pretty scattershot at the moment.
Because we're trying to identify the most-used functions first, having people add bug reports for functions they need is very valuable.
3) Is there any official/community website for quercus? (I've only found the bugtracker at http://bugs.caucho.com/my_view_page.php )
http://wiki.caucho.com is the best at the moment other than the bug trackers. We'll be adding a bulletin board as soon as we find a good PHP one and make any Quercus fixes to get it working.
4) What is the quercus license? From the source comments I understand it's under the GPL: is it correct?
GPL
|
|
|
Message #194541
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Because we're trying to identify the most-used functions first, having people add bug reports for functions they need is very valuable.
I've submitted bugs found while trying to run drupal (the most used php "cms/framework" around).
|
|
|
Message #194566
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Point is that it's not "killing" anything, it's just broadening the range of choices available for running these applications.
My point exactly. And if we broaden the term "these applications" to mean web applications in general, it is easy to see that tools like Ruby on Rails are not killing Java, but are just adding to the list of available technologies that a web developer can use to do his job.
I, for one, welcome any of our new web development tools that bring fresh ideas. (Call me pro-choice, if you like.) However, it is natural that too many choices will confuse some developers, or even frighten them -- add the FUD that TheServerSide spreads with their reoccuring "Is [technology X] killing Java?" posts and you'll have the liveliest "discussions"... Good for the ad sales revenue, I guess.
Please note: That a new tool is offered does not mean that the tools you use are obsolete now.
Just my two cents, Lars :-)
|
|
|
Message #194569
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
It doesn't mean you cannot run you php code on apache /mod_php any more.cheers It does if you use things that are not available on apache/mod_php.
Hmmmm. I think your image of PHP is way to idealistic Sir. Let's consider this, for example: PHP offers support for calling COM component and also offers IIS specific functions. If you use IIS functions in your PHP code you can forget about running your code on apache. Also, if call COM components from your PHP code it will probably work from mod_php on apache on windoze, but don't dream about running it on linux.
So now considering all this, how doesn this java port take away more "attraction" from PHP?
Regards,
Emil
|
|
|
Message #194570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cool, but benchmarks?
From what I understand, PHP can't run on Apache 2 yet. It's not multi-threaded capable yet.
PHP is, but not all it's 3rd party modules are and I doubt they never will (maybe they are not developed anymore). PHP team does not have any responsibility on modules provided by 3rd parties (and they do no officially support them). More from here: http://www.php.net/manual/en/install.unix.apache2.php.and here: http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2
So the options for Apache2 is to run it with PREFORK MPM (that is not multithreaded MPM and performs better that for eg. worker mpm that is threaded in single processor machines). Or you can run Apache2 threaded and use FastCGI module to execute PHP.
I'm not sure where this 6x performance gain was taken, but I think we need more information to justify this. I do know that bytecode compiled java code is most propably faster than evaluated PHP. Did you use PHP bytecode cache (that is used in all reasonable PHP configurations), eg. PECL/APC, eaccelerator etc?
Roadsend has gone even further than Caucho by compiling PHP to nativecode: http://www.roadsend.com/home/index.php?pageID=compiler.
There is also PHP -> MS .NET Compiler that is also kinda fast: http://www.php-compiler.net/.
You *could* use it, but it wouldn't be completely threadsafe.
I have been running mod_php on Apache 2 on both Worker MPM and Prefork MPM for over two years and I have not had a single crash because of PHP (but officially PHP team is still recommending Prefork MPM on Apache 2 installations that is perfectly fine for me. As I have said threading is not always better than multiple processes (eg. preforking).
So odds are they are experiencing a lot of speedup just from having the ability to run inside a multithreaded JVM.Steve
No, that is not the point. multithreading has nothing to do with this said performance boost. The whole point is that caucho is compiling PHP code to JVM bytecode (native Java code). Byte code is most definately faster to execute (even in slow JVM implementation) than parsing/evaluating PHP scripts on the fly. But as I said PHP has also these so called bytecode caches that compile PHP pages on background to their native bytecodes (eg. eaccelerator, pecl/apc, zend accelerator, etc.). I do not know did caucho use these when they did they tests against mod_php (if not, I do not think that this it's fair to compare the two).
|
|
|
Message #194572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP-Java Interaction
Can Java and PHP be used in the same application, sharing scopes? That is, can PHP code put something in the session that is later retrieved by a Java session.getAttribute() call? Vice versa?
Can PHP be used to simply render a Java-based model?
|
|
|
Message #194582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agree, but don't make a claim you can't back up...
I agree it's a nice feature, and that Caucho makes good software. No complaints at all there. But I hate to see big claims like 6x better performance without any substantiation.
|
|
|
Message #194595
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cool, but benchmarks?
Aapo,
I think you are missing something here. You say:
Roadsend has gone even further than Caucho by compiling PHP to nativecode
.. and ..
The whole point is that caucho is compiling PHP code to JVM bytecode (native Java code). Byte code is most definately faster to execute (even in slow JVM implementation) than parsing/evaluating PHP scripts on the fly. But as I said PHP has also these so called bytecode caches that compile PHP pages on background to their native bytecodes (eg. eaccelerator, pecl/apc, zend accelerator, etc.).
The point is actually that Java byte codes are native code, because all JVMs today that are being used in server environments will dynamically (either JIT or adaptively) compile the byte codes to native machine code. For most applications, "Java byte code" is now as fast as C code built with an optimizing compiler. That means that PHP running on Caucho is not just "being compiled to byte codes", but is actually "being compiled to native machine code", which is pretty quick.
Further, even if a different approach compiled to native code, Java would still likely be significantly faster, because (at this current point in time) JVMs have the best performance of any of the various high level languages that support JIT technology. The two main reasons why this is so is that the major hardware companies (Intel, Sun, IBM) have focused for the past ten years on making it so, and Java byte codes themselves are a decent match for machine code, so there are few major inefficiencies in the translation. (For the same reason, C used to be called "assembly with macros", since its supposedly high-level constructs were already well known to assembly programmers, and most had 1:1 translations to assembly.)
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #194602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
So now considering all this, how doesn this java port take away more "attraction" from PHP?
I didn't say the port did - the java specific could would. And your above (not reposted) statements add to what I said.
I doubt I am idealistic about PHP. I was merely commenting on the idealistic view of others (ie it is easy and is supported everywhere).
|
|
|
Message #194626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cool, but benchmarks?
Aapo,I think you are missing something here. You say:Roadsend has gone even further than Caucho by compiling PHP to nativecode
The point is actually that Java byte codes are native code, because all JVMs today that are being used in server environments will dynamically (either JIT or adaptively) compile the byte codes to native machine code.
I know that, but I still do not consider java bytecode as native code because there is always the JVM. I would propably consider Java bytecode as native code if JVM unloads itself after JITing. But that is not happening. And I said that roadsend has gone further than caucho. Caucho is not compiling anything to native code (JVM might do it... but that depends on JVM). They just turn PHP code to bytecode (or maybe java source and use javac to compile to bytecode).
But you are correct that todays applications run inside jvm are usually comparable to their native counterparts in performance. I have not seen many high end Java games, but on the server side Java seems to work as great as native code.
And thank you Cameron for clarifying the things I had forgotted or which I had given misinformation.
|
|
|
Message #194629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Lol. We need a petshop in php that beats the hell out of .NET implementation! Right !?
Regards,
Horia Muntean
|
|
|
Message #194632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Lol. We need a petshop in php that beats the hell out of .NET implementation! Right !?
Working on it. :)
Seriously, though, keep in mind that PHP is a dynamic language. That's true no matter whether the implementation is interpreted or compiled.
For example, variable references in PHP resemble hashmap lookups, not local variable references. (In addition, PHP has a silly copy-on-assignment semantics for arrays which also affects performance.) That means the underlying performance issues aren't quite as simple as just compiling to bytecodes.
In particular, even though Quercus compiles to Java bytecodes (and therefore to machine code through the magic of the JIT), an equivalent Java program will still be faster than the compiled PHP program. The compiled PHP program is basically doing hashmap lookups for variable references, while the Java program is using machine code local variable references.
|
|
|
Message #194661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
Maybe Fibonacci in java will be faster than in php. What about the layers that ( read Mr. Tate late night ROR application being faster than the java counterpart, which BTW I find hard to belive taken into account all the records BEA and Sun broke lately ) people say hamper the java web apps performance?
Regards,
Horia Muntean
|
|
|
Message #194692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Here comes easy load-balancing and redundance!
one interesting thing that I don't see emphatized enough is that now we can easily obtain load-balancing and redundance, which Resin offers to all hosted apps!
btw: any attempt to obtain failover via TCP session sharing?
|
|
|
Message #194967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PHP 5 and libraries
Resin PHP (we call Quercus) supports PHP 5 and also a growing number of the PHP libraries. We are adding to them daily.
|
|
|
Message #194970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Caucho Resin adds PHP
1) PHP 5
2) Should be fully compatible, but please report any bugs.
The list of fully / partially implemented modules is in quercus/classes/com/META-INF/services/com.caucho.quercus.QuercusModule.
There are more modules to come....
3) I think so far just the bugtracker.
4) GPL
|
|
|
Message #194971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does this version of Resin run ONLY on Java 1.5?
It was only released in 3.0.16. I was writing the wiki page before I knew what release we would actually include it in.
|
|
|
Message #318007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Compatibility
I have also heard that it does in fact only run on Java 1.5. Can anyone else confirm this? I've heard differing viewpoints on this.
John | Skylight Windows
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
