|
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
|
 |
Rule Engines and Declarative Programming Come to Java
N. Alex Rupp has started a new column, Ruling Out, on rule engine technology. In this first introductory article he discusses why we have rules engines, the standards behind them, developing with them, and a declarative programming example.
Ruling Out: Rule Engines and Declarative Programming Come to Java
There seems to be a lot more movement in the rules engine world on the Java space, which is great to see
|
|
|
Message #135027
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
good introduction to rule engines
the article provides a good introduction to rule engine technology. for me, one of the best examples of how "imperative" programming fails to scale well is the classic chess game example. If a person had to code a chess game procedurally, the game would be very easy to beat. Once you figure out which paths in the logic tree the game doesn't understand, beating it is trivial. Although AI has gotten a bad reputation from the 80's, the technology is mature and used in numerous financial and insurance systems. A real world example would be changing SEC regulations. Many companies cannot handle the rapid changes in SEC regulations, because their rule engines were designed to process rules procedurally. Rule engines like JESS, iLog JRules, Blaze Advisor and Drools take advantage of RETE algorithm to make rule evaluation efficient and flexible.
|
|
|
Message #135042
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JESS is also very good, and JSR-94 is not a silver bullet
I have used JESS in the past, and was really happy with it. I started out implementing with JSR-94, but found it to be limiting, and honestly questioned its value. It removed me too much from the power of the underlying JESS rules engine. I felt it dumbed down my API too much, so I used the native rule API instead.
(About JESS... The author of the software has a great book that will get you started. JESS is not free for commercial use. I have not had a chance to try out drools, but am looking forward to it.)
The goal of JSR-94 is the ability to plug rules engines. But the reality is if you change rules engines, 90% of your effort will be in recoding your rule base. Changing the interface to you application is the least of your concerns. So there really is not much advantage there.
I would highly recommend people try a rules engine, if just to learn the interesting logic they use. JSR-94 is fine, but done be afraid to chuck it as I did. Results matter, not standards. ;)
|
|
|
Message #135059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
history of JSR-94
If I remember correctly, the JSR was originally initiated by BEA and the RuleML group. It stalled for over a year when the lead at BEA left and someone else took the lead on JSR-94. I also remember that BEA used to use iLog JRules.
When JSR-94 first started up, there was a proposal to include a standard rule markup, but it was rejected. There was also a suggestion to standardize on Rete engines, but no agree could be reached. Therefore, the current JSR-94 looks pretty useless and borrows heavily from EJB concepts. In my mind, there needs to be a light weight rule api that describes the process of loading the necessary objects, facts and rulebases. The administration of the rule engine can remain separate and should. Regardless of the rule engine, there are common operations which are needed. Loading object definitions, loading base data, creating modules/components, loading rules and executing rules.
in my mind, it is feasible to define a generic rule deployment API that is more useful than the current spec, but still lets each company implement it their way.
|
|
|
Message #135062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Engines and Declarative Programming Come to Java
Has anybody used Mandarax in production?
http://mandarax.sourceforge.net/
It's been around a while, and looked pretty good when I looked at it briefly about a year ago, so I'm interested in any comments from people who've actually used it for a real app.
Regards,
Colin
|
|
|
Message #135066
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How does Prolog fit into this?
I was just curious how the Prolog language fits into this. Perhaps using standard rule APIs in the JSR (if they exist) you can plug in a Prolog compiler and write all your logic in prolog with some extra methods to get some data from the existing object data structures?
There may be a few prolog programmers still out there than can do all the expert system development for the problem domain and separate them from the actual java development itself.
Assuming Prolog processing is fast as they say RETE is.
|
|
|
Message #135068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How does Prolog fit into this?
Prolog (a language) is based on backward chaining while Rete (an algorithm) is based on forward chaining concept. This means that Rete will tell you which rules fired given the facts while Prolog will tell which facts were required to fire a given rule.
Jess - a Rete implementation - provides a backward chaining facility but its not as fast as its normal execution (forward chaining).
|
|
|
Message #135083
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR-94 found to be limiting
I don't know that this is any fault of JSR-94 itself. I found the spec to be rather sensible. The challenge in this space is similar to what you find in lots of the JSRs. The more complex the problem becomes, the more varied the products that offer them, the more "irrelevant" a standard becomes - even a very good standard.
JSR-94 is no EJB, it is a sensible spec.
JSR-94 a good job at sending Java objects in and out of the rule working memory. I drew from this model to create my own wrapper around JESS, using a HiveMind service to create a rule session.
Its a real judgement call. I have found that the power of the native apis is much greater, and the benefit of "pluggablity" with JSR-94 is dubious. I don't know that it is a fault of the spec itself, as much as the weakness of a having a spec for a complex problem. It is not an easy task.
Ben
|
|
|
Message #135109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
history of JSR-94
Peter,
Disclaimer: these comments are mine and are not approved by BEA or any of the other JCP members.
I used to be a staff engineer and later a program manager for BEA, but left BEA in 2003. While employeed as a staff engineer, I authored and submitted the JSR-94 proposal to the JCP and I was the original spec lead for the JSR-94 EG. As such, any stalling or lack of progress during the initial months of the JSR effort was my fault.
Here are some facts and some opinions related to the items that you mentioned:
0. In an early version of BEA's Portal product, BEA embedded ILog's JRules engine. I was the person who wrote most of the embedding code. I advocated for JRules over alternative rule engine embedding solutions, as did my boss prior to the embedding effort. I advocated for JRules largely due to the high quality of JRules, the unique usefulness of JRules' embedding APIs and most importantly, the incredibly good support that I received from the JRules engineers and the JRules product manager during my evaluation of the rule engine alternatives.
1. For reasons that it is not my privilege to discuss, after shipping a version of the Portal product with JRules embedded, BEA decided to replace JRules with its own, homegrown rule engine in the next version of the portal product. For the most part, Daniel Selman and Jason Howes built that rule engine. Anyway, at the same time that BEA decided to build and embed its own rule engine, BEA also decided that it would be best to enable customers to embed rule engines of their choosing.
2. I concluded that the best way to enable customers to embed rule engines was to standardize a rule engine plug-in model, a rule engine usage model and a rule engine language. Of course, I wasn't the only person that had reached such a conclusion. I was new to the rule engine domain and there were genuine rule engine experts who had thought of the standardization idea long before I had. For example, the RuleML group that you mentioned had given consideration to the idea long before I had.
3. I convinced my bosses (sometimes, lots of bosses get involved in a JSR decision) that BEA should submit a rule engine JSR. So, on behalf of BEA, I submitted JSR-94 for approval. This was BEA's first-ever JSR submission. And JSR-94 was my first-ever JSR submission. I mention this not to brag, but to give me an opportunity to point out that I was a JCP novice, and that by being a novice, I was not the best possible lead for the JSR-94 EG. However, as I learned, sometimes the strength of the lead is not as important as the strength of the lead's sponsoring employer.
4. I learned a bit about the JCP during the discussions that lead to the approval vote for JSR-94. Among the things that I learned was that some powerful JCP members had widely divergent visions of the JCP. In particular, I learned that some powerful JCP members did not believe that the JCP should be used as a basis for innovating, but should instead be used merely as a basis for capturing mature technologies in specifications. I mention this because originally I had proposed in the JSR to create and standardize the rule engine language that you mentioned. During the pre-approval discussions, more than one powerful JCP member made it clear that they would vote against the JSR not only because they thought that the *Java* Community Process was an inappropriate forum for creating *languages*, but also because they believed that the JCP should only be used to harvest mature technologies, not create new ones. In order to gain the approval votes of those members, I removed the rule language from the scope of the JSR. At the time, I was upset about the vision of those JCP members. But over time, I've thought about their vision a lot, and have actually come to the conclusion that I agree with them. In other words, I believe that they were right and that I was wrong about the scope and best use of the JCP.
5. The EJB-ness of JSR-94, at least initially, was due to a few factors. Other members of the expert group might have different opinions, but I believe that the EJB-ness of the initial JSR-94 thinking was due in part to technical considerations, and was also due to business considerations. EJB-oriented vendors were heavily represented in the original expert group membership and I'm sure that you can guess how such orientation might influence the thinking of an expert group. I should add, however, that at least one member protested that the rule engine API should be a lightweight API that could be used outside of the context of a J2EE appserver, which seems to be consistent with your opinion.
6. The question of how rule base loading should be supported or not supported was, in my opinion, the biggest initial source of disagreement among the expert group members. I can't speak for the other members, but I can say that I totally agree with you that JSR-94 should have said more about rule base loading. When I had embedded JRules in the early Portal product, I implemented an on-demand model for loading rule bases that I borrowed from the JSP on-demand loading model. I advocated for a similar model within the expert group, as well as even more aggressive loading models (e.g. file-based rules embedded within J2EE apps and rules embedded within in-flight document messages). However, as I learned during the initial JSR-94 effort, most traditional rule engine folks thought of rule bases as distinct, stand-alone databases that were loaded and un-loaded without regard to J2EE application lifetimes. In other words, some of the other JSR-94 EG members seemed to think that my ideas were naive or just plain wacked. Perhaps they were. As I said, I was new to the rule engine domain and so lacked the years of experience that some of the other EG members had. But, I was never very comfortable with the model of rulebases as a sort of stand-alone brain. That model always reminded me of that episode of Star Trek where Spock's brain is removed from his body and placed in a glowing orb ;-). Comedy aside, I had already learned the usefulness of on-demand loading from my embedding efforts, and I didn't want to reduce the functionality of the BEA Portal product simply to support another EG member's view of how rulebases should or should not be loaded. Such reduction-in-functionality issues are probably typical for EG members attempting to standardize features of shipping products. Anyway, I forfeited the right to advocate for loading/un-loading functionality in JSR-94 because...
7. Shortly after initiating the JSR-94 effort, I changed jobs within BEA and was no longer working on rule engine stuff as part of my day job. As a result, I neglected to pay sufficient attention to the JSR-94 effort. For several months, the JSR-94 effort languished and I'm reasonably sure that some of the EG members concluded that the JSR-94 effort was a waste of time as it was not going to go anywhere as long as I was the spec lead. If so, they were justified in their thinking as I really did let the EG down. Fortunately, Daniel Selman eventually bailed me out and took over leadership of the EG to get things back on track. However, during the time that JSR-94 was languishing we lost some of the interest and participation of some of the EG members. Who knows, JSR-94 might have been different if it had not been allowed to languish for those early months.
8. Daniel Selman can provide you with a lot more information about the "why" and "why nots" of the JSR-94 spec that finally shipped than I can. I recommend that you ask him any detailed history questions that you might have.
Doug Dew
|
|
|
Message #135116
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My experience with declarative programming
I agree that this article is a really good introduction to
I was trying to apply the declarative approach to one problem in the knowledge representation area, and the problem I ran into was unsuitable semantics of today's frameworks. At first sight the semantics of rule systems seems straightforward, but in reality it is not, especially when you start to consider negation and concepts such as overriding default behavior or priorities. Many theoretical approaches have been described, but not all are simple and intuitive enough, and very few are actually implemented. My hope is also that using a declarative approach for my problem could actually improve the performance of the solution (which is now handled imperatively), and that's even harder to satisfy, given the reputation of declarative implementations, which are often much slower than imperative languages. I ended up implementing my own rule engine, but I am not really satisfied with it. So I am still looking for suitable semantics of the framework and efficient implementation algorithms.
|
|
|
Message #135141
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Defining rules in XML file
Just an ide . I may be easy to define rules in a XML file. Rule engine can read XML file and the act accordingly .
|
|
|
Message #135142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaSpaces is a perfect platform to run rule engines
For people familiar with Rule Engines, Rule engines sually come as libraries or components, I had the chance to implement rule engine systems on top of JavaSpaces as the run-time and container for the rule engine, as well as communication, subscription and delivery platform. The rule engine I implemented is XML based, using XPath queries and XPath based subscription. The result is realy good in terms of performance, scalability and flexibility.
I will be more than happy to provide the XML rule engine sample and information to people interested in this.
Avi
|
|
|
Message #135143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaSpaces is a perfect platform to run rule engines
Avi, Sound very interesting. Could you email me on dselman [at] javarules.org with the details -- or write a little article and post it on www.javarules.org?
Thanks,
Dan
|
|
|
Message #135166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Engines and Declarative Programming Come to Java - Do they
I am by no means an expert on rule engines, but I have seen them used in powerful ways, in particular in financial applications. However, in "vanilla" Java development, I'd be a bit more careful about using them. First of all, you are very likely to be tied in with a particular vendor/supplier of your rule engine quite quickly.
Because such tools usually depend on some basic libraries, say for logging, persistance etc. you will very easily get some serious version dependencies into your code - as is of course the case with any "large" third party library, so not much of a surprise here. Then of course rule engines will usually require the design of a domain specific language. On its own this is of course not bad at all - in fact it is one of the nice things of declarative programming - but again I believe in keeping the number of languages as low as I possibly can in any system. Then rule engines have sort of a "problem", that is people, a lot of people, especially those doing occasional maintenance do not really understand how they work or in other words, can't guess the outcome of a certain set of rules. And finally I am not really convinced of rule engines that I have seen delivered as part of various ecommerce products.
The basic demonstration of showing the "gold campaign content" to the "gold customer" is nice, but is this something that can be easily generalized to any business case? I rather doubt it. But maybe it is just because the right "domain specific language" has not yet been defined.
For example there are some excellent examples where I like rule engines, in particular where they augment something, that people are somewhat used to do with rules. For example advanced access control is something that I can readily endorse. So maybe it is just that may way of thinking has not opened up enough to appreciate the principle in other areas as well...
|
|
|
Message #135198
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
good insight
thanks for providing more details into the history of JSR-94. Since I am not a member of JCP, please excuse the inaccuracies of my earlier post. I'm definitely biased, but even if someone wants to plug a procedural rule engine into a servlet or ejb container, the same deployment concepts should apply.
I'm optimistic the rule engine API can improve and make developing/deploying rule technologies consistent. It may not be easy, but it can be easier and consistent.
|
|
|
Message #135396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaSpaces is a perfect platform to run rule engines
I would be very interested in receiving a sample of your XML-based rules engine. If possible, please email to: dshah@sloan.mit.edu. Thanks.
|
|
|
Message #135444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No pattern for rule language programming
I once spent three or four months on Rule language programming. My job was well done. The disappointment was that my ruleset never reached the goal of well maintainence and extension as we declared. I could sense the power of rule language, but don't how to manipulate the power.
|
|
|
Message #135478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Language Standardization
Is anyone aware of any efforts to standardize on a rule definition language through JCP?
Maybe we need a separate JSR for that.
Unless there is an accepted standardization of the rule language with the ability to use a rule engine vendor of choice (and with the ability to swap one vendor's engine out and replace with another easily), you are not going to see wide-spread adoption of rules technologies in enterprise applications.
Vijay
|
|
|
Message #135480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JESS
I wonder if anyone who has experience with the new JSR-96, or older 94 spec has used JESS? http://herzberg.ca.sandia.gov/jess/It is essentially a java wrapper CLIPS.http://www.ghg.net/clips/CLIPS.htmlI used this briefly at a bio-informatics company, but it experienced limited production time. I agree with the person whom posted that it seems very powerful, but difficult to manage. a slight correction. JESS is not a wrapper for C CLIPS. it is a pure Java implementation and is on par with iLog JRules and Blaze. the next release will include a rule IDE plugin for eclipse. some people don't like LISP syntax, but I am not bothered by it. managing rulebases is an old problem and most people tend to go with a rule database of some sort.
|
|
|
Message #135488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Language Standardization
Vijay,
Please see item #4 of my earlier post about the "history of JSR-94."
I agree with you that a standard rule language is a prerequisite for widespread adoption of rule engines. However, I don't believe that there's much of chance that anybody would be able to get JCP approval for a JSR that includes a non-Java-based rule language within the JSR's scope.
Although I haven't given much consideration to this idea, perhaps there's some way to leverage the new features of the Java language to express rules. For example, perhaps annotations could be used to indicate that a method is a rule. Perhaps annotations could also be used to express the declarative conditions of the "If" portion of the rule. Then, the method body could be used to express the imperative actions of the "Then" portion of the rule. That probably sounds like a hack (it is), and until thirty seconds ago, I hadn't given the idea any thought at all. So, if you say that the idea sucks, you certainly won't hurt my feelings. The reason that I mention such an idea is to point out that if your goal is to include a rule language within the scope of a JSR, then you're probably going to have to do some sort of a Java-based hack. That's just the nature of the *Java* Community Process.
Good luck!
Doug Dew
|
|
|
Message #135542
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A practical approach - XPath and Java
For the rules I use XPath, it is very easy, intuitive and standard, For the actions, I use plain Java or JMS destinations that activate MDB's on J2EE servers.
|
|
|
Message #135560
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
history of JSR-94
Doug,
Thanks for the background info. A few points:
One of the ideas we have is to establish a strong meta-data api (similiar in concept to that provided by JDBC). This would allow products such as Portal Servers to embed different rule engines with a simple adapter. Of course, a standard rule language with standard semantics would also have to exist for this vision to be achieved.
A rules engine sitting outside of a J2EE app server does make alot of sense. Also, a calling client application should not care if the application is within a J2EE server or a Spring container or its own JVM. However, I am not sure how much lighter it would be.
Within the JSR community we did learn lessons from EJBQL etc. about inventing new languages. But, for this JSR to meet its goals, a standard language with standard semantics is needed. You cannot have portable rules without this.
Regards,
Manoj.
|
|
|
Message #135563
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
history of JSR-94
Doug,Thanks for the background info. A few points:One of the ideas we have is to establish a strong meta-data api (similiar in concept to that provided by JDBC). This would allow products such as Portal Servers to embed different rule engines with a simple adapter. Of course, a standard rule language with standard semantics would also have to exist for this vision to be achieved.A rules engine sitting outside of a J2EE app server does make alot of sense. Also, a calling client application should not care if the application is within a J2EE server or a Spring container or its own JVM. However, I am not sure how much lighter it would be.Within the JSR community we did learn lessons from EJBQL etc. about inventing new languages. But, for this JSR to meet its goals, a standard language with standard semantics is needed. You cannot have portable rules without this.Regards,Manoj. I would agree 100% a standard markup language is needed. Hopefully either the W3C can come to an agreement or one of the other standard bodies like OMG or Oasis can tackle the challenge. Whether the JCP should be the place for it isn't totally clear in my mind. I would hope it would include other platforms and be inclusive.
|
|
|
Message #135617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Language Standardization
Doug,
I see your point about not being able to get "JCP approval for a JSR that includes a non-Java-based rule language". Maybe a different body/process needs to come up with the specification. This could just be a group of interested developers and vendors without any relation to JCP and JSRs.
I can envision a "Java-like" rule language that uses Java syntax as far as possible with some other non-Java extensions. This would basically be a new language that looks a lot like Java (and therefore easy to learn for most users).
If anyone is interested in bouncing some ideas around this concept, ping me at vijay@mindspring.com
Vijay
|
|
|
Message #135928
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rule Language Standardization
In my (personal) opinion the root problem is not that there is not a standard rule language, it is the lack of a standard execution semantic for rule engines.
Once a standard execution semantic is defined, any number of rule languages can be easily created. We can create XML-based languages for interchange, Java-like languages for programmers, natural-language like formats for business people etc. etc.
The enabling technology required for all language standardization is a "virtual machine specification" for rule engines. This would be the foundation upon which standard languages would sit and would ensure that an "if xxx then yyy" on one engine would execute the same way on another engine. This is the point of a standard language in my view.
This is obviously a very ambitious goal but without such an effort I cannot see how else we can tackle this hard problem. Java has the JVM specification (and indeed multiple languages run on the JVM), .NET has the ECMA/ISO-standards, C/C++ has ANSI etc (500+ pages for C).
|
|
|
Message #207863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JavaSpaces is a perfect platform to run rule engines
Can you send me information on your XML based rules engine to austin@poeticdata.com. Thanks.
|
|
|
Message #227592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSR-94 is simply a beta standard in my opinion
I agree, for example Rulesharp has a back door that is far much better then jsr-94. One line of code, can't beat that.
Also I think rulesharp is better because jess , jrules , blaze , haley , etc are not that easy to use and integrate and do much more then just rules overlapping with other coding.
check it out for yourself at: www.rulesharp.com
randy
|
|
|
Message #235817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JavaSpaces is a perfect platform to run rule engines
I am currently interested to try out your rules engine. Could you please send me the rules engine implementation to abhilashk.cse@gmail.com.
|
|
|
Message #240556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JavaSpaces is a perfect platform to run rule engines
Avi,
I would be very interested in checking out your XML rule engine code. The concept could be very helpful on a project I'm currently working on. Could you please send to rizzo.m@comcast.net ?
Thanks!
|
|
|
| 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)
|
|
