So what is Ajax? How do you use it with Java and J2EE? developerWorks has an introduction, and there's a lot more going on.
The next question (for us) is:When is Ajax going to be built into Java?
The simple question may be "never" since Ajax at its heart is just servlets running little services that produce bits of XML data. However, having said that, it'd probably be handy to have some sort of Struts
Looks like some people are already getting a start. Sun has some Ajax Java Blueprints
that include a discussion, "Using JavaServer Faces Technology with AJAX
." Direct Web Remoting
(DWR) is a framework for "easy Ajax for Java." Apache Cocoon
can render Ajax Forms
. Apache MyFaces
has an Ajax DataTable
feature. There's an article, "Ajax using XMLHttpRequest and Struts
." The AjaxTags taglib
is a JSP taglib for Ajax functionality, and an apparently unrelated Sourceforge AjaxTags project
. AJAX-JSF Framework
aims to render any JSF
GUI using Ajax. So far, no one seems to be working on tooling.
WebSphere Process Server
introduces a new component model for modeling services in an SOA
, the Service Component Architecture
SCA is not (yet) part of J2EE; it is a custom extension which is currently only available in WPS. SCA is a way of modeling a service interface, the separation between the two parts of an SOA application
. The service interface specifies what the provider (SOA-SP) has to implement and what the coordinator (SOA-SC) can invoke. By modeling the SOA-SPs as each being an implementation of a service interface, and by modeling the SOA-SCs as each being a client that invokes a service interface, a designer can more easily develop a high level design of his SOA composite app, focusing on the services involved and deferring the implementation decisions until later.
An SCA service interface is a fell-fledged interface, ultimately realized as a WSDL document or as a Java interface.
The service provider implementations in an SCA
are called service components
. A service component implementation
can be a:
Because they are all service components, initially you just model it as a service component to be used by service clients; later, you decide how to implement it. Perhaps it starts out as a human task, but later you automate it as a Java object or business process. Through it all, the service component interface stays the same.
The parameters passed into a service component operation and the result value passed out are modeled as service data objects
s). SCA and SDOs enable a service and its data to be modeled in an implementation-independent way, one which may later be implemented using a variety of technologies, the main choices currently being either a Web services provider or a Java class.
Here are several resources where you can learn more about SCA:
has just published an article, "Java? It's So Nineties
." It asks: "Can it possibly be that Java--once the hippest of hip software--has become a legacy technology?"
The article talks about competition to Java from LAMP
, and AJAX
. It points out that popular sites like Google and Yahoo don't use much Java.This information may be correct, but it's also missing (a lot of) the point. The question is whether you need business logic in your Web site, or whether your Web site just shows users your database.
The article talks about tasks that don't require much business logic. Google just displays search results, e-mail, and map images. Yahoo is the poster child for portals, aggregating existing info and integrating it on the glass. They both use read-only data that can be highly replicated; users can configure the display. Those tasks require minimal programming logic, so PHP scripting and a simple SQL database be all you need (plus a Web server and OS). Even then, huge sites like Google and Yahoo must be doing much more than just using PHP.
But a lot of sites need more than scripting. Do your users need to: Find airline tickets? Trade stocks? Does your implementation need to: Integrate with EIS
s? Enforce security? Coordinate multiple users updating the same data concurrently? Good luck with PHP scripts. You're gonna need J2EE or .NET for that. I can tell you that this is what WebSphere
) customers are doing.
This is an old argument. I remember in the early '90s when Smalltalk
would compete with tools like PowerBuilder
. PB would let you CRUD
your data, but not much more. Smalltalk would give you business logic. Which was better? Depends on what you need. If you just need to CRUD your data, PB was easier. For more sophisticated apps, Smalltalk was more sophisticated and capable.
So LAMP may well work if you want open-source everything and just want to display (and CRUD?) your database. But for full-blown applications hosted on the Web, LAMP won't cut it. AJAX is a cool display technology (see Ajax and Java
), but it's only a display; you still need a server behind it running something (LAMP, Java, .NET, etc.). .NET is on the same level as J2EE, and c# is very Java-like, so then that comparison is the old Microsoft-only vs. semi-open-standards and write once, run everywhere argument.
The article seems to miss a lot of emerging trends. It fails to distinguish between Java and J2EE (aka Java EE
), comparing Java to .NET. It doesn't discuss the biggest trend in IT today, SOA
; much less IBM's new SOA programming model, SCA
. It seems like Java and J2EE have grown a lot since Peter Yared was an exec at Sun.
So yeah, Java may not be the technology of choice for displaying your database. But hopefully your Web apps are doing a lot more than that.
I've talked about how IBM Powers the Xbox 360
. Now there's a paper about it on developerWorks.
|The article has the rather cryptic title "Just like being there: Papers from the Fall Processor Forum 2005: Application-customized CPU design." The abstract is more descriptive.|
This Fall Processor Forum paper explores the customized IBM PowerPC processor designed for the Microsoft XBox 360, designed and optimized for high-volume production, low cost, and quality -- with an array of testing and debug features to reduce system time-to-market. It boasts three 3.2GHz high-frequency PowerPC processor cores, and it's like no chip you've ever met before. Read why.
I gotta say, these CPU details are a little low level for the work I usually do, but interesting nonetheless.
This article too has been Slashdotted
. (The Slashdotters seem to be real on top of developerWorks articles lately.)
Newsweek is running an article, "Google: Ten Golden Rules
." It focuses on the care and feeding of knowledge workers.
Getting the most out of knowledge workers will be the key to business success for the next quarter century. Here's how we do it at Google.
The golden rules are:
- Hire by committee
- Cater to their every need
- Pack them in
- Make coordination easy
- Eat your own dog food
- Encourage creativity
- Strive to reach consensus
- Don't be evil
- Data drive decisions
- Communicate effectively
Check out the article; I think it's real good stuff.
For more Google posts, see Google users wealthier, more Net savvy
, Google Video of the Day
, and especially Google Base
(which links to more posts). For some discussion on IBM's values, see IBM Values
, IBM Customers Are Clients
, and Collaborative Influence
The December 12th issue of Fortune magazine
is titled "How to Become a Great Leader."
|The cover article, "The Education of Andy Grove," is excerpts from a forthcoming book. Some of the episodes described are interesting, like deciding not to license the 386 to other chipmakers ("The Reality Shifter") and deciding not to scrap the CICS design for RISC (the first episode in the article); but most of the episodes are a bit tedious and short on insight. I hear Grove's autobiographical books (High Output Management and Only the Paranoid Survive) are really good; the forthcoming The American: The Life and Times of Andy Grove doesn't look nearly as good, judging by the Fortune article. Likewise, "10 Top Leaders Tell Their Secrets" isn't real helpful for us J2EE developer types.|
However, two other articles interview Fred Brooks and discuss insights from Peter Drucker. Those are good (IMHO), so I'll discuss them next.Dec 22 Update
: My colleague Dave Artus has added a good comment (disagreeing with me, no less!), so please click on that link.[Read More
IBM's SDKs for Java 5 are now available for AIX, Linux, and z/OS.
Previously the Java 5 SDKs were beta releases
. As usual, the SDKs are available from the IBM Java Developer Kits
section of the developerWorks Java zone
. You can download SDKs for AIX
(32-bit and 64-bit), Linux
(6 different flavors), and z/OS
(31- and 64-bit; yes, 31-bit!). We do not seem to have a Java 5 SDK for Windows, just JRE 1.4.2
for PCs from IBM/Lenovo.
The AIX overview
page also has some more info about the SPEC JBB2005 performance benchmarks, related to the SPECjAppServer2004 benchmarks
I discussed recently.
Norman Richards describes How JEE was Saved
Norman (a JBoss guy, BTW) contends that Hibernate and Spring helped bring needed improvements to JEE (see Java SE 6 and Java EE 5
). Now that EJB 3.0 is pretty much final
, and incorporates the best parts of Hibernate and Spring, Norman contends that their necessity has passed and their importance will wane. (For some history, see Persisting Domain Objects
and Unnamed Persistence Specification
I agree with him that standards are good, that having these features built into EJB and JEE will provide a consistent foundation for using these features.
Norman also points out an interesting purpose that these alternative/extension frameworks may serve: Not so much a basis for long term (many years) software development, but a temporary fix that shows how the standards can and should be improved. Once the standards are improved thusly, the frameworks are no longer needed and should go away. For example, Struts was the basis for JSF; once you have JSF, do you still need Struts? Probably not.
Ultimately, I still contend that IBM clients
who have spent money on products like WebSphere Application Server and Rational Application Developer are better off sticking with the related J(2)EE programming model as much as possible, so as to maximize their use of standards and of IBM support.
Fortune magazine has published some excerpts from Peter Drucker.
The article is Advice From the Master
. It's listed online as part of Fortune's "How to Become a Great Leader" issue
(but it doesn't seem to be in the printed magazine).
Drucker's take is that executives should look for collegues with specific strengths, not generalists that tend to be mediocare. I think that applys to technical people as well, that good teams tend to have people with different strengths; as long as the people work together well (and that's a big if), the team's total talent is greater than the sum of its member's talent.
I would take this one step further. It's easy to attend a meeting of whatever development team you happen to be part of, look around the table at your teammates and think "He's good. That guy's terrible. She's good. She's not." and so on. It's tempting to look at people that way, but not very helpful. Good managers I've worked for try to figure out what each team member is good at, then see how to apply those abilities to benifit the project. That way, everyone contributes. Given, sometimes you have a team member with little talent or a lousy attitude, who consistantly contributes little to any project. That's a person who needs to re-evaluate their career choice, before their employeer does it for them. But most people have something good to contribiute; good managers look for slots that fit their talents and preferences. This works better than trying to force fit staff members into slots that fit the project better than the people staffing the project.
So look around the table and think about what each team member is good at. And think about what you're good at. Then think about how you can work with them to put what you're good at together with what they're good at. I think you'll find you'll wind up with a team capable of producing much more than you could yourself, even if everybody isn't good at everything.
Fortune magazine has published an interview with Frederick Brooks.
The interview is "Quoted Often, Followed Rarely
" in Fortune's "How to Become a Great Leader" issue
is the author of the seminal book The Mythical Man-Month
. "The book detailed Brooks' experience managing IBM's bet-the-company System/360 computers and OS/360 software ..." Thirty years later, Brooks discusses the book, whether its advice is being followed, and why the same mistakes keep getting made over again.
Brooks reflects on how some people consider his book the "bible of software engineering." He agrees in this regard: "everybody quotes it, some people read it, and a few people go by it."
I've published a new article, featured as the Top Story in the developerWorks SOA and Web Services zone
, titled "Streamline SOA development using service mocks
Simplify SOA development -- especially if your project involves multiple teams -- and raise SOA application quality with use cases and mock objects.
This article explains an approach to let separate development teams developing the two parts of an SOA application
work independently--one team developing service providers and another developing coordinators that consume those services--and to develop these parts concurrently.
What do you think? Does this approach make sense? Is this what you do on your projects? Is it what you'll do now?
The Service Component Architecture
(SCA) specification from IBM has now been endorsed by several leading industry companies: BEA, IONA, Oracle, Sybase, and others. A couple of significant companies missing from the list: Sun Microsystems and Microsoft.
From the Oracle press release
BEA Systems, IBM Corporation, IONA Technologies, Oracle, SAP AG, Siebel Systems, Sybase, Xcalia and Zend Technologies today announced an effort to develop specifications and resulting collaborative technologies that simplify how organizations create and implement applications in a Service Oriented Architecture. ... The SOA Programming Model specifications include the Service Component Architecture (SCA) to simplify the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats.
The specs are available on developerWorks at Specifications: Service Component Architecture (SCA) and Service Data Objects (SDO)
Agreement amongst these companies is significant because it means SCA and SDO won't be proprietary IBM-only technologies. Previously, only IBM and BEA supported SDO (see the CommonJ Specification
), and only IBM supported SCA. Now, not only are these other companies agreeing to support SCA, all are now agreeing to support SDO as well (all but BEA, which already had agreed but is reaffirming its support). Support by all these vendors means that developers will be able to design and implement SCA components and clients using Java, then deploy that code into any compliant application server, not just IBM's WebSphere Process Server
. Also, services will be interoperable: An SCA client could be deployed in a BEA product and use an SCA component deployed in an IBM product. So developers can take advantage of SCA and SDO without fear of vendor lock-in, and will have freedom to choose the best vendor's product for the job.
There is already a JSR for SDOs: JSR 235: Service Data Objects
. There is no JSR for SCA yet, but I imagine these companies intend to start one. Why formalize a spec as a JSR? Once a JSR is approved, it can then be added to J2EE.
The lack of endorsement by Sun will probably make it harder for the JSR(s) to get traction, but the JCP
is supposed to support adoption of new Java features even if they're not supported by Sun. The lack of endorsement by Microsoft is significant too. If Microsoft would add SCA and SDO support to .NET, then SCA clients and components implemented in .NET would be interoperable with those implemented in J2EE (or at least J2EE app servers with SCA extensions).
At some point down the road, it may be possible to combine SCA with MDA
. Then you could design your SCA components and clients, then tag each with the implementation technology of choice and each connection with the invocation protocol
of choice, then use MDA to generate the parts. You could tag one as .NET for example and generate its code, then change your mind; just retag it as J2EE and regenerate. Wouldn't that all be amazing?!
Here's press coverage of the announcement:
(Disclaimer: Forward looking statements, may not all come true, don't bet the farm quite yet, etc.
Rational has a Pattern Solutions
web site, from which you can download tools to generate implementations of common software patterns. It includes new patterns by IBM for SOA and ESB.
The tools are packaged as Reusable Asset Specifications (RAS)
(an OMG standard for what are basically executable templates) for Rational Software Architect (RSA)
. For more info about RAS, check out Bill's RSA mentoring
Here are some developerWorks articles with more information:
Here are some related resources that may be helpful:
The Motley Fool
discusses corporations using blogging in "IBM in the Blogosphere
The article quotes Brian Doyle, director of Corporate Affairs for IBM. "We're really interested in blogs and podcasts for a number of reasons: As an employer of 329,000 people worldwide, we want IBMers to familiarize themselves with these tools. ... [A]ny time we come across a powerful new way for our global workforce to communicate and exchange information, we're going to go beyond tacit endorsement and actively work to give our employees access to this technology." Speaking for myself, I've "met" (via e-mail and instant messenger) a number of IBMers who have read my blog and contacted me, so it is helping us communicate at least a little bit better.
I also like this quote from the article: "The company is more than just approving -- it's actually enabling employees to, say, blog." Hey, my ears are burning
! Actually, it's mostly talking about the facilities we have for creating blogs and wikis internally, stuff which the public outside of IBM can't see. It's cool that the article is discussing blogging, but a little disappointing that it fails to distinguish between strictly internal communication and external communication from IBM to our customers, which I've found can benefit us internally as well.
The December 2005 issue of IBM WebSphere Developer Technical Journal
is now available.
We've got articles on: