There's a new release of the Eclipse platform available.
The Eclipse Foundation
has released a new version of the Eclipse platform
, Eclipse Galileo
. Technically, they call it a "release train" built on the platform, which means it doesn't change the platform but instead adds a whole bunch of stuff they think people are going to want. The stuff doesn't necessarily work together, but at least it's all grouped into one downloadable thing.
For more info, see "Eclipse Galileo Release Now Available
." Also see "An Eclipse Galileo flyby
" on developerWorks.
The new release contains something for everyone:
- Java: JDT - Java development tools
- Workflow: Java Workflow Tooling
- Ajax: Rich Ajax Platform
- SOA: Swordfish, SOA Tools, and SCA Tools
- Code generation: M2T JET (Java Emitter Templates) - aka JET2 (see The Design Patterns Toolkit)
- Component architecture: Equinox (see Eclipse Equinox)
Check out the full list of projects
. The article says it also includes the Eclipse IDE for Java EE Developers
Technorati Tags: eclipse, galileo, developerworks |
| Digg it | Slashdot it | Post to del.icio.us |
We've updated the Recommended Reading List for JEE and WebSphere Application Server.
I've talked about our Recommended Reading Lists
, compilations of what we think are the best articles for getting started in a topic area. We update them from time to time to add the latest articles.
We have just updated the Java EE (fka J2EE) reading list: "Recommended reading list: Java EE and WebSphere Application Server
." Thanks to ISSW's Sree Ratnasinghe for making the updates. Check out the list, I think you'll find it helpful.
WebSphere has turned 10 years old.
WebSphere Application Server was first released ten years ago. The anniversary was actually a couple of months ago; here's an article on this milestone: "IBM WebSphere at 10
Technorati Tags: websphere, ibm || Digg it | Slashdot it | Post to del.icio.us |
Rational has a new beta version of RAD available for you to try.
The IBM Rational Application Developer for WebSphere v7.5 Open Beta
is one of the Rational software early programs
, similar to the WebSphere Software Early Programs
RAD 7.5 includes support for the newest standards, including Java EE
, JAX-WS 2.0/JAX-B 2.0
, WS-Reliable Messaging
, and SOAP 1.2. You can download the beta for free and try it today.
Technorati Tags: rational application developer, java enterprise edition, enterprise java beans || Digg it | Slashdot it | Post to del.icio.us |
The Feature Pack for EJB 3.0 for WebSphere Application Server V6.1 has reached general availability status.
This means that Feature Pack for EJB 3.0 for WebSphere Application Server V6.1
, the feature pack for adding EJB
3.0 to WAS
6.1, is now production quality. I've talked about the WAS 6.1 Feature Pack for EJB 3
, one of the WebSphere Software Early Programs
that makes new features available in WAS 6.1 so that you don't have to wait for the next version of WAS and upgrade to it. Other feature packs include the WAS 6.1 Feature Pack for SOA
and the WAS Feature Pack for Web 2.0
The feature pack is a full implementation of EJB 3.0, including the Java Persistence API
(JPA) that's replacing entity beans, and is a significant step towards supporting Java Enterprise Edition
5 (Java EE 5), the next version of J2EE. (WAS 6.1 implements J2EE 1.4.)
You can download the feature pack at no cost and install it in WAS 6.1. You can read about how to use the new features in the WAS 6.1 EJB 3.0 InfoCenter
. In "Building EJB 3.0 applications with WebSphere Application Server
," ISSW's own Roland Barcia
discusses the new feature pack, shows an example of developing a simple JPA bean and annotated session bean, and shows how to develop the code using the WAS 6.1 Application Server Toolkit
(AST). You can also develop EJB 3.0 and JPA code for the WAS feature pack using the RAD v7.5 Beta
New and updated wiki pages:
Technorati Tags: websphere application server, java enterprise edition, enterprise java beans || Digg it | Slashdot it | Post to del.icio.us |
I've published a new article, "New to Architecture."
It's New to Architecture
, the introductory article in the New developerWorks Architecture Zone
The JCP has approved
the final draft of JSR #244
: the Java Platform, Enterprise Edition 5 (Java EE 5) Specification.
Java EE is the new name for J2EE
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.
There's been some discussion of how to implement a service in J2EE: use a stateless session bean (SLSB), a plain old Java object (POJO), or a combination thereof.
Awhile back, I discussed How to Implement a Service in J2EE
. (Where I abbreviated "stateless session bean" as "SSB". And the abbreviation for "stateful session bean" would be ...?! I meant to use the abbreviation SLSB (which is not a SFSB). Duh!) Synchronous clients could invoke the service by calling the method in the SLSB's local or remote interface. Asynchronous clients could use JMS messages; an MDB would receive the request, invoke the method in the SLSB's local interface, then return the result in a reply message. For HTTP clients (such as a Web service), the MDB would be a servlet. I go on to say that the object could be a POJO, but making it a SLSB adds the advantages of being an EJB.
Eugene Kuleshov has discussed this further on his blog
on BEA's dev2dev
. In Implementing J2EE-based services for a real world
, Eugene shows a design whereby the service is implemented as a POJO, which can then be invoked by a SLSB or a MDB. He points out that this is more dependency injection
(IoC) friendly. I agree.
My bias is that I use WAS
and I don't use enterprise Java w/o EJBs
frameworks like Spring
(which also supports EJBs for good measure). So my first pass at an implementation is usually to go ahead and put the code in the EJB. Nevertheless, if I see or later discover the need to use code separately without going through an EJB (perhaps because I'm already going through another EJB), I would certainly refactor the code to move the logic into a separate POJO class. Whether that should always be done preemptively, just in case--I rarely (never?) do.
I will say that I believe it's a good practice to pretty much always have an MDB delegate to a SLSB, not directly to a POJO as Eugene shows. This way, synchronous and asynchronous clients will always experience the same QoS, whatever you configure in the SLSB--security, transactions, etc. An MDB or servlet calling the same access point that synchronous clients do--usually a SLSB--is the typical implementation of the Service Activator pattern (EIP
, Core J2EE
So, Eugene makes some good points. His approach and mine are pretty similar, but with a little difference that depends on one's desire to fit into frameworks like Spring. If you're interested in this stuff, check out what Eugene has to say.
Three new authors have been added to WebSphere: Author spotlight
: Joey Bernal
, Steph Parkin
, and me
The Author Spotlight highlights people who have published a lot of articles about WebSphere products
. Each author usually has his or her themes, so it's good to find an author whose themes match your interests. For example, Joey writes about Portal, and Steph writes about how to use tooling like RAD 6
The spotlight on an author is useful in two ways. One, it lists in one place all of his/her articles and other publications, so that you can more easily find what all he/she has written. Two, it lists other publications the author finds helpful, which makes a good reading list of other stuff for you to go check out. For example, both Joey and Steph recommend The Soul of a New Machine
, so that sounds like a good book to go check out.
In my recommended reading list, I've listed the books I think any J2EE developer should have on his bookshelf. Need to learn UML? I've listed a book for that. Use cases? A book for that too. Lots of patterns books. And some books on leadership too, because I'm finding that ability to be as important to a project's success as technical ability.
Happy birthday, not to me, but to my blog.I started my blog
one year ago this week. Since then, I've posted over 250 times; hopefully most of the entries have been interesting to at least someone.
At the time, I planned to use this blog to discuss J2EE issues, and in large part I have. Yet, not too surprisingly in retrospect, the blog has also taken more of a WebSphere bent. This evolution occurred for a couple of reasons. For one, a lot of J2EE documentation already exists, especially on Sun's Java web site
. For another, new news on J2EE has been somewhat sparse; the J2EE 1.4 spec
came out nearly two years ago (Nov 2003), and J2EE 5 (JSR 244
) may not be final before the end of the year.
Meanwhile, the organization I work in, IBM Software Services for WebSphere
, has a mission of teaching current and potential WebSphere customers more about WebSphere products
. So I get exposure to a lot of good information about our products, information IBM is trying to communicate to our customers, but without any perfect approach to get the right information to the right people whenever they need it. So this blog has evolved into an opportunity to help with this effort. Thus I've covered customer relationship topics like Working with IBM Support
, new capabilities like WAS 6 high availability
, new features like the Service Integration Bus
, and new products like WebSphere Extended Deployment
. A very early theme has been What You Should Be Reading
, which has now lead to a whole article, "Where can I learn about WebSphere?
So if you keep up with this blog, hopefully it helps you keep up with new products, what's new in the products, and gives you a better understanding of the products and how to use them. Meanwhile, we'll continue to talk about basic technologies like J2EE and JMS, and technology trends like SOA and ESBs. Thanks for joining.
JBoss and Microsoft are announcing a partnership. Surprising for two companies that seem so different: JBoss -- Small, open source, J2EE; MSFT -- Just the opposite.
The companies plan to cooperate on Web services and identity management. JBoss's app server will work better with Windows and other Microsoft software.
For more info:
Let's just hope JBoss doesn't get embraced and extended
A reader recently asked: Which web sites (if any) do you frequent to keep up with Java goings-on?
Hmm, that's a good question. Here are a couple you might want to check out.
I do a lot of my learning by reading books, so one of my very first blog postings was What You Should Be Reading
. This is a theme that has come up a number of times in my blog, so Google for that
. Likewise, check out a frequent recommendation of mine, the ISSW Recommended Reading List
, which is mostly articles and web sites, not books, so that they're freely and immediately accessible.
The reader proposed one possibility for a good web site to learn about Java: The Server Side
. I tend to find The Server Side to be kind of a super market tabloid of a Java news site; more interested in shocking than educating. There, I've said it, let the hate mail begin. (sigh) When I peruse The Server Side, what I find is lots of announcements for new versions of frameworks I've never heard of, which doesn't make me feel more knowledgeable about how to use Java. To anyone who wants to defend The Server Side: What would be useful is for you to highlight sections of the web site for learning about Java, and thereby prove what a good educational site it is; I'd like to know.
There are other Java web sites which tend to be educational and helpful. My collegue Kyle Brown publishes and comments occasionally
, which seems to actually have informative articles. Along the same lines, jGuru
seems good. A performance-specific site is Java Performance Tuning
; a similar site is Precise Java
. (Also in the Google list of Java performance sites
is one called Nawa Shibari
, but judging from the root page, I'd say it seems to be something very different! Is this where Java performance enthusiasts go when they're not tuning Java?!)OnJava
is O'Reilly's take on things. Javalobby
is kind of the closest thing Java has to a political action committee
. And finally, at the risk of simply endorsing my own employer, there are lots of good articles in the developerWorks
' zones on Java
, WebSphere Application Server
, IBM WebSphere Developer Technical Journal
, Rational Application Developer
(and the older WebSphere Studio zone
), and so on.
That should give you some stuff to browse for a while. Hope you find it helpful.
Aug 23 Update:
Another helpful site is java.net
, run by Sun as a newsie addition to the main Java Technology
This probably isn't any new info, but let's make sure we're on the same page here, especially since I haven't seen this discussed extensively anywhere; it's just assumed. The way you implement a service in J2EE is with a stateless-session bean.
A stateless session bean
(SSB) is a kind of EJB
that manages a user's access to an app's domain model
. As an EJB, an SSB manages overhead issues like sharing of instances, thread reuse, transactions, and security; this lets the SSB developer focus on implementing code for business logic. Because an SSB is stateless, a user only cares about using an instance from a pool of the same type; since all instances are the same, which one a particular user gets makes no difference.
For example, a banking SSB might have methods like
. Each method is stateless, so it needs appropriate arguments like account IDs and payment info.
Services are also considered stateless; all state must be passed in as parameters. Web services are stateless, HTTP itself is a stateless transport.
So in J2EE, it makes sense to implement a service, such as a web service, as an SSB. If the service transport is HTTP, it's easy to add access to an SSB by implementing a service activator (EIP
), which in J2EE for HTTP is a servlet
. If the transport is JMS
, use the service activator pattern again, but this time implement it as an MDB
. A J2EE 1.4 container can expose an SSB as a JAX-RPC web service directly
; the container acts as the servlet.
Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.
Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean
. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.
So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.
I've just discussed
Billy's tips for some J2EE programming model extensions in WAS. There are a couple of other recent items on his blog that are especially good and worth noting.
Those of us that have used JMS a lot have learned: Do not depend on message order!
Just because you write messages out in a certain order doesn't mean they'll be received in the same order, because the messages can
, under ideal circumstances won't
, but can
) get mixed up between points A and B. This is a recurring issue because app developers tend to assume order is preserved, superficial testing confirms that order is preserved, and app integration designs (by plan or assumption) tend to depend on order being preserved. The classic hypothetical example is three messages to create, update, and delete a record: What if delete is received first, then create? What if update is received after delete, or before create? Bottom line: Don't depend on order.
In Total JMS Message ordering
, Billy gives some nice compact examples of why messages get out of order. I'll give another: different paths--network paths, or messaging paths caused my intermediate routers
--between the sender(s) and receiver(s). If the first message takes a sufficiently slower path than the second message, they arrive out of order.
In Don't use ThreadLocal!
, Billy points out (and gets lots of comments) that code running in a J2EE app server shouldn't depend on a Java thread's local variables. The issue is that threads in an app server are shared resources, so you only get one for a short time to do a little work. Then when you're ready to do some more work, you may get a different thread, in which case any values you stored in the last thread are now gone. Or you get the same thread again, but another client may have used that thread since the last time you did and may
have changed the values. So don't depend on them.
A side issue that spawned is: What if code only uses the thread local variables while using a single thread, during a synchronous call? (Which is probably the only way ThreadLocals
should ever be used anyway.) This will work, but Billy points out that this will still fail if Java 2 Security is enabled (as it should be
), because security will block code from messing with threads' internal state. If you've got code or frameworks that don't work correctly when security is turned on, that's not so good.
Sometime, I need to talk about an even more general theme: Don't spawn your own threads (Thread#start()
) in J2EE. It's bad! But that'll have to wait 'til another time.