|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 13
Messages: 13
Messages: 13
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ask TSS: if GWT's open source, where's the source?
A reader asked if TSS could advocate the release of GWT's test cases to Google (as requested in this bug report.) TSS won't, but the request raises an interesting point: what sort of thing should be released in a toolkit in order for the toolkit to really be useful?
GWT isn't open source (see the terms and conditions), so there's no real burden on Google's part to open up the compiler and its test cases, but there's little doubt that it would be very useful for developers planning on extending or fixing certain problems in the compiler or runtime libraries. In this case, the reader pointed out that the tests would apply to the portions of GWT that have been open sourced, so there'd be nothing needing more visibility from a licensing perspective.
GWT's purpose is fairly unique, but its situation might not be. So the question stands: what would you like to see in a release like this?
|
|
|
Message #222880
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Keep the code, open the process
GWT is probably the best ajax framework for java developers.
Major problem (even bigger than the need to Drag&Drop) is that it is not scalable for enterprise applications.
Why?
A single entry point must be controlled by google.
Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding.
Some projects try to solve it. Most notably GWanTed or G4Jsf.
They do fine job but got a major limitation:
If they can extract GWT to the complex widget writing level, putting 10 such GWT widgets on a page will cause the bring the entired GWT library compiled to JS 10 times to the browser.
I think google should not limit GWT's developers to work with GWT only but open itself to JSF/JSP/Whatever integration. JSF/GWT looks like the best of two worlds.
(@see: check Atlas/Script# integration)
I think google should open the process how the complier is working in order to help such frameworks. This is the future. GWT cannot control the web by itself.
Such knowledge could give a chance for the duplicated js code problem.
Cheers,
Lior
|
|
|
Message #222884
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
"Major problem is that it is not scalable for enterprise applications."
I think you will find that nearly all Ajax frameworks have the potential to overload a back end. It is extremely important that application designers and developers continuously test the client-to-server and server-to-backend (jdbc, jms, jca) execution patterns when introducing or modifying aspects of the Ajax framework and runtime configuration. A team must carefully deliberate over the ease of use (and coolness) of Ajax introductions in light of resulting resource (threads, connections) consumption patterns. Improvements in the effectiveness of performance and capacity modeling is extremely important with such rollouts.
I recently wrote a blog entry that touches on this on a small scale.
http://blog.jinspired.com/?p=30
I hope over the next few days and weeks to explore this in greater detail as well as expanding the scope of the analysis to include resource transaction analysis patterns (hint: transaction chopping).
William Louth
JXInsight Product Architect
JInspired
"Java EE tuning, testing, tracing, and monitoring with JXInsight"
http://www.jinspired.com
|
|
|
Message #222885
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Huh?
A single entry point must be controlled by [GWT?].
Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding.
I don't, frankly, see this as a drawback. I still don't think the whole JSF model is a good one for applications from the get go. Anything that attempts to change the nature of the underlying platform is doomed to complexity problems, and I am not sure stacking more on top of it (Seam) is the way to go. It seems to me at a fundamental level, GWT encourages much better software practices than any of the other methodologies out there -- and I won't call GWT a framework, but I expect to see frameworks evolve from it.
And seriously, what does this have to do with scalability? It might be a process issue in terms of moving from legacy/divergent systems, but those are standard issues anyway with any technology. I find GWT's development model and distribution methods superior to any of the other current systems anyway.
More to the point, I think open sourcing the compiler -- or at least some more of the individual pieces would be good. I have found myself already wanting to manipulate the type oracle for some custom serialization behavior and opening up the core would allow people to extend the portions of the Java API implemented. I have classes now that mirror the java.beans.*PropertyChange* classes, but being able to add those to the compile environment would be great.
|
|
|
Message #222893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
A team must carefully deliberate over the...
JUNInspired noise.
You wascal you!
|
|
|
Message #222894
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java2Script
Check Java2Script:
http://j2s.sourceforge.net/
It's Eclipse Public License 1.0 based.
Java2Script (J2S) Pacemaker provides an Eclipse Java to JavaScript compiler plugin and an implementation of JavaScript version of Eclipse Standard Widget Toolkit (SWT) with other common utilities, such as java.lang.* and java.util.*. You can convert your SWT-base Rich Client Platform (RCP) into Rich Internet Application (RIA) by Java2Script Pacemaker.
|
|
|
Message #222895
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
A single entry point must be controlled by google.
Eh, that's why it is not scalable? You are talking about the entry point classes, right?
I fail to see why you couldn't deploy your client application on multiple backends and let a load balancer send client requests to each entry point. That would scale just fine.
GWT (like most client-side AJAX frameworks) can scale much better than most server-controlled technologies for the simple reason that you can store state on the client. Which gets rid of the entire clustering state problem, the server affinity problem, etc. You just have to figure out a good way to keep the security checks sane.
|
|
|
Message #222896
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
"Major problem is that it is not scalable for enterprise applications."
I think you will find that nearly all Ajax frameworks have the potential to overload a back end.
I've found Ajax to do quite the opposite in most cases: the back-end is under less load, due to the fact that "micro-requests" mean that it only needs to process what will actually be updated, rather than process a whole page.
Obviously, it probably depends on your usage scenario: something like populating a textfield with dropdown values based on the entry text might do more damage than good in terms of server load.
|
|
|
Message #222900
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
I've found Ajax to do quite the opposite in most cases: the back-end is under less load, due to the fact that "micro-requests" mean that it only needs to process what will actually be updated, rather than process a whole page.
Under certain circumstances (or implementation) this could be the case that is why I qualified my statement with "potential" and stated the importance of improved performance and capacity modeling. With Ajax a development team clearly needs visibility into the implications of a particular interaction style as earlier as is possible especially when the costs both in terms of network latency (chop versus batch) and resource consumption (thread and connection pool capacities) can greatly impact all.
Regards,
William
|
|
|
Message #222901
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
Of course AJAX is better than normal HTTP/server-side generation overhead if you have competent programmers.
Come on, if a bunch of people don't like a technique because it threatens their sacred cows/careers, you don't assume it's going to be competently programmed, you assume the worst case.
Somewhere in the raw discrimination is a point though: Javascript is a terrible language to program in, and lends itself towards poor implementation.
I have no idea what this single point of entry is that they are referring to. I don't see what would stop clustering using the usual distribution workloads. GWT seems to eliminate the necessity of server-side sessions (still looking into this), which increases scalability and reduces/eliminates most of the web tier, and would simplify clustering and failover (no sessions to clone).
|
|
|
Message #222904
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Huh?
It seems to me at a fundamental level, GWT encourages much better software practices than any of the other methodologies out there ....
Hmm, I do not think so.
I think that the best scenario is when all the UI aspects are handled by client, client calls server for data mostly, and client code is auto or on-demand updatable.
Therefore I consider Java Web Start based applications to be the most sane technology available today.
- If JWS really supported Applets then it would be even closer to ideal;
- and if JNLP allowed specifying trusted artifact repositories to avoid duplicate downloads of common stuff then it would be perfect solution;
|
|
|
Message #222907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep the code, open the process
Hi Carl,
Whether Ajax gets widespread adoption is of little concern to me today as all of the client side development I do today is Swing based.
I am just more aware of the potential issues with the "blind" adoption of a particular rich client platform by less experienced enterprise development teams. Last year I was involved in a performance investigation at one of the biggest software management companies in the world were a single execution of a particular use case within a Swing application had managed to generate more than 20,000 remote calls and resource transactions at a beta customer site all because the ill conceived workflow-like programming model used in this application managed to completely hide the nature of the distributed processing from the junior developer who was tasked with wiring up views and event handlers.
regards,
William
|
|
|
Message #222932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Huh?
A single entry point must be controlled by [GWT?].
Google is best for the low level, but it doesn't let other technologies do the higher level modeling / coding.
I don't, frankly, see this as a drawback. I still don't think the whole JSF model is a good one for applications from the get go. Anything that attempts to change the nature of the underlying platform is doomed to complexity problems, and I am not sure stacking more on top of it (Seam) is the way to go.
JSF and seam exist for a reason, the html action -> form -> action metaphor is inherently broken by design once it comes to user interfaces.
The status quo since the early 70s is, that vt200 terminal like interaction does not scale it simply does not work once user interfaces become more complex. You need componentization, an event system and if things should not get out of hand encapsulation on component level via oo, to handle complex user interfaces, also those uis should be stateful.
What we had with the early 90s was that suddenly all the working design patterns were thrown overboard and the broken terminal / vt220 methodology was revived and to the works in a less working way than it used to be thanks to missing control elements and a sane form handling and now we have to deal with abstraction frameworks to hide and cover the deficits.
Yes JSF and seam should be unnecessary, but please fix the broken html form standards then we can talk about it!
The main problem i see is, that two generations of developers have now been grown up which have to inherently unlearn the bad design principles and practices which html enforced onto them!
|
|
|
| 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)
|
|
