www.flickr.com
|
Tuesday, July 05, 2005
JavaOne 2005: JEE 5.0 and a philosophical discussion of SOA
This year's JavaOne appeared to be a bit smaller than in years past. The pavilion was about 1/2 of the size it was a few years ago. That said there was still a mix of old and new around JavaOne this year.
The usual cast of characters, Cameron Purdy, Bob Lee, and the JBoss guys were found on the floor and at the various evening festivities. Other folks like Hani and Cedric weren't around because they had to "work". pfft! There were also new folks there like Salesforce, Google, and Azul Systems.
Day 1 I attended the keynote where I watched Bill Shannon talk about the various new acronyms that were being rolled into the new and improved Java Enterprise Edition 5.0.
The main theme is still ease of development. Things like plain object persistence, annotations, resource injection. Simplified web services and support for more standards (clearly we don't have enough acronyms in this realm do we?) In J2EE 1.4 a web service needs an interface, impl, and XML files. In 5.0 a web service needs a single class with annotations. I imagine there's some hyperbole there but we'll see how close to reality that claim will become. (Anyone remember how descriptors were going to be removed in EJB 3.0? Turns out there's some meta data information that's best described in an external location.)
Other new items consist of (alphabet soup time...)
The implementation of all of these, and more are going to be found in Sun's project glassfish.
http://glassfish.dev.java.net
After Bill's talk, Mark Hapner appeared on stage to talk about SOA. His claim is that SOA will fundamentally change the way we develop services on the java platform.
He identified what he believes to be two main elements in SOA:
1) Composite services
2) Enterprise Service Bus
The first step in the java platform achieving this is JSR-208.
Now I know that there's been a lot of talk over the last couple of years about SOA but each time the subject is broached I've kind of scratched my head and wondered "where's the beef?". What's really new about all of this stuff? I've come to discover that SOA is more about a "state of mind" than anything else. It's an approach to application development as opposed to some new wiz bang technology. It's about "unsiloing your apps" so the application logic is loosely coupled and generally available. I say "OK" but isn't the relative merits of decoupling application logic well worn territory? Wasn't this proven sometime ago in a programming class in college or high school? If I write my application, or in SOA speak "service", in a modular fashion so that it's callable by an unknown party aren't I really just writing modular code for reuse? Yes there are new guidelines to keep in mind when creating a service (state information for example) but it's really fundamentally the same.
OK so we've slapped an implementation independent description of what the application can do on the front of it in WSDL and we use XML to make the calls into the application but what's new here? Yes I understand the big win that comes with platform independence, heck I was fascinated with Java back in 1996 because of that fact. So yes we have another level of abstraction with implementation independence (Didn't we already have this with CORBA?)
I don't mean to downplay the significance of what these abstractions bring to the table, I think they're really important, but in reality I just don't see (yet) what's so new and exciting here. At least not exciting enough to proclaim " SOA will fundamentally change the way we develop services". How so? I'm going to write that stock quote service in the same fashion I would've pre-web service, as a web service, and in an SOA architecture. What fundamentally has changed?
I realize that given my employer's position in the market and weight behind SOA and marketing the wonderfulness therein that this would seem to be counter to that vision. That's not my intention. What I imagine is that there are plenty of other developers out there that are pragmatic and want to understand what the real "meat and potatoes" is regarding a technology or technique. I simply want to present the landscape as it occurs to me and see how well that resonates with folks. Am I oversimplifying things? Are there things that I'm missing? Where's the beef? ;-)
The usual cast of characters, Cameron Purdy, Bob Lee, and the JBoss guys were found on the floor and at the various evening festivities. Other folks like Hani and Cedric weren't around because they had to "work". pfft! There were also new folks there like Salesforce, Google, and Azul Systems.
Day 1 I attended the keynote where I watched Bill Shannon talk about the various new acronyms that were being rolled into the new and improved Java Enterprise Edition 5.0.
The main theme is still ease of development. Things like plain object persistence, annotations, resource injection. Simplified web services and support for more standards (clearly we don't have enough acronyms in this realm do we?) In J2EE 1.4 a web service needs an interface, impl, and XML files. In 5.0 a web service needs a single class with annotations. I imagine there's some hyperbole there but we'll see how close to reality that claim will become. (Anyone remember how descriptors were going to be removed in EJB 3.0? Turns out there's some meta data information that's best described in an external location.)
Other new items consist of (alphabet soup time...)
- JSPSTL - I'm not sure about this one. JSPTL is in JSP 2.0 which is J2EE1.4. Not sure if there's something new here but it was on the list.
- Stax - This BEA led technology is now part of JEE 5.0. Congrats to Chris Fry and others.
- JSR-181 Annotations for web services - Another BEA led technology part of JEE 5.0
- JAXB 2.0 - Haven't looked at it myself but have read great things about this new version.
- JAX-WS JSR-224- Formerly JAX-RPC 2.0. This JSR is currently open for public review.
- Common Annotations JSR-250 - The intent is to create annotations for use in JSE and JEE to prevent redundancy
- JSF - Finally making its way into the spec.
- JSP 2.1 JSR-245 - Focusing on better alignment with JSF
The implementation of all of these, and more are going to be found in Sun's project glassfish.
http://glassfish.dev.java.net
After Bill's talk, Mark Hapner appeared on stage to talk about SOA. His claim is that SOA will fundamentally change the way we develop services on the java platform.
He identified what he believes to be two main elements in SOA:
1) Composite services
2) Enterprise Service Bus
The first step in the java platform achieving this is JSR-208.
Now I know that there's been a lot of talk over the last couple of years about SOA but each time the subject is broached I've kind of scratched my head and wondered "where's the beef?". What's really new about all of this stuff? I've come to discover that SOA is more about a "state of mind" than anything else. It's an approach to application development as opposed to some new wiz bang technology. It's about "unsiloing your apps" so the application logic is loosely coupled and generally available. I say "OK" but isn't the relative merits of decoupling application logic well worn territory? Wasn't this proven sometime ago in a programming class in college or high school? If I write my application, or in SOA speak "service", in a modular fashion so that it's callable by an unknown party aren't I really just writing modular code for reuse? Yes there are new guidelines to keep in mind when creating a service (state information for example) but it's really fundamentally the same.
OK so we've slapped an implementation independent description of what the application can do on the front of it in WSDL and we use XML to make the calls into the application but what's new here? Yes I understand the big win that comes with platform independence, heck I was fascinated with Java back in 1996 because of that fact. So yes we have another level of abstraction with implementation independence (Didn't we already have this with CORBA?)
I don't mean to downplay the significance of what these abstractions bring to the table, I think they're really important, but in reality I just don't see (yet) what's so new and exciting here. At least not exciting enough to proclaim " SOA will fundamentally change the way we develop services". How so? I'm going to write that stock quote service in the same fashion I would've pre-web service, as a web service, and in an SOA architecture. What fundamentally has changed?
I realize that given my employer's position in the market and weight behind SOA and marketing the wonderfulness therein that this would seem to be counter to that vision. That's not my intention. What I imagine is that there are plenty of other developers out there that are pragmatic and want to understand what the real "meat and potatoes" is regarding a technology or technique. I simply want to present the landscape as it occurs to me and see how well that resonates with folks. Am I oversimplifying things? Are there things that I'm missing? Where's the beef? ;-)
