We're finally getting
started at 6:25 and we were supposed to start at 5:50. Good ol'
projector issues. This time it was a bent pin.
J2EE 1.4 introduced the first web services component type (SE) and
augments EJB specification (2.1) to expose SLSBs as a web service
endpoint.
Writing J2EE 1.4 web services ("endpoints")
Two J2EE components to implement a web service:
- JSE (JAX-RPC Service Endpoint). New component, new deployment
descriptor. Looks like a servlet, acts like a servlet. Run's in a web
container like a servlet. Isn't a servlet.
- SLSB. Exposed as web service via deployment descriptors.
JSE is easier because it's (mostly) POJO based. EJB might be preferred
if you already have EJBs or you need transaction management. However,
the SOAP client calling the EJB web service does not participate in the
transaction (at least the spec does not define it).
"Mandatory" transaction attribute not allowed in EJB endpoints because
SOAP client can't propagate transaction.
JSEs are similar to servlets:
- Instances run in the web container
- follow servlet lifecycle
- Must have a public no-arg constructor
- Can
add servlet filters just like you do normally
Steps to writing a web service JSE:
1. Write remote interface (the
service endpoint interface) - must extend java.rmi.Remote and throw
RemoteException
2. Write implementation class
3. WSDL Document
4.
Deployment Descriptors (web.xml and web-services.xml)
5. Create WAR File
J2EE 5 will allow you to turn any POJO into a web service - no interface
needed. Apache Axis can be used to generate the WSDL for you with Ant.
You map the implementation class as a servlet, with a servlet-mapping
and everything. The difference b/w JSE's and servlets is you can only
map one JSE to one URL.
Writing web service clients. Client model is defined by the JAX-PRC 1.1
spec. You can write web service clients using three JAX-RPC techniques:
1. Generated Stub - Easiest. Done at development time. JAX-RPC is
invisible to your code. Stub classes hide it. Runtime implementation
will be tied to a vendors JAR because vendor tool will generate class
based on WSDL.
2. Dynamic Proxy - Most Portable. Done at runtime. Your code asks
JAX-RPC factory to create stub at runtime that implements SEI (Service
Endpoint Interface).
3. Dynamic Invocation Interface (DII) - No Stub Necessary. Useful for
tools - e.g. dynamically retrieve WSDL then show user on a GUI what
services are available and allow user to select what should be called.
Client sets URL, methods to invoke and required parameters.
Future of J2EE web services. JAX-RPC 2.0 (JSR 224) in the works. The goals
of JAX-RPC 2.0 are several:
- Make writing WS simpler by using metadata and annotations.
- If you write an endpoint interface, your implementation class won't have to implement it.
- Remove requirement to define a remote object.
- Better support for document-centric web services.
- Integration with JAXB.
Tom's presentation was quite good for his situation. There was a *ton*
of technical issues and he had to show his presentation on Chris
Huston's Powerbook. This meant no demos since he had JBoss 4.0 and
everything else setup on his Windows laptop. After flailing about for
the last hour - he admits its time to buy a Mac.
Apache Geronimo
1. Apache Software License
2. Uses other BSD-derived, open source
projects
3. Initial manifestation as a J2EE 1.4 application server 4.
J2EE 1.4 certified (in-progress)
Started a year ago in September. The main motivator for Geronimo was
there was no BSD-derived license for an open-source application server.
The GPL license requires you to contribute code back if you customize a
product. BSD allows you to do anything, you just have to give credit
back to the originator. Sounds like the proper license for AppFuse to
me.
The heart of Geronimo (the kernel) knows nothing about J2EE. It's
designed to do just about anything you want it to do - it's just a
configuration away. Jakarta project at Apache makes up a huge portion of
ASF projects. Many of these projects are pieces of the J2EE puzzle.
However, there wasn't any glue to hold it all together. Geronimo
re-uses a *lot* of existing (best of breed) open source projects.
Geronimo still doesn't support Tomcat. The main reason is because 3 of
the Jetty committers are part of the Geronimo team. Jetty was the first
component every deployed in Geronimo. According to Bruce, someone is
working on integrating Tomcat right now. You'd think this would be
pretty easy and only take a couple days to do. Maybe I'm wrong.
Geronimo is NOT another lightweight container, web framework, or AOP
framework.
It IS designed for long running servers. Its designed to tolerate partial
component failures. System oriented services.
Geronimo Kernel - Fundamental Core
- Small memory consumption ~ 150KB code
- Component Registration
- Component Configuration
- Integrated Repository
- Lifecycle Control
- Dependency Manager
Now Bruce is going on about Maven and how it works. ZZZzzzzz. Maven schmaven.
He does have a good point though - it works great for building and managing
multiple projects and their dependencies. Geronimo has 30 sub projects - yow.
A lot of concepts and architecture in Geronimo is derived from Maven. Hmmm,
I wonder if that means it's slow. 
What are GBeans? They're a J2EE managed component (a JMX MBean), which are basically
simple objects plus some metadata. Used to bridge JSR-77 lifecycle requirements.
GBean wrappers allow just about anything to be plugged into be plugged into
Geronimo. Implement the GBeanLifecyle interface: doStart(), doStop(), and doFail().
Bruce is now showing us the DerbySystemGBean that's used to stop and start GBean
w/in Geronimo. Bruce has a lot of good things to say about Derby and thinks it's a much
better database than both MySQL and PostgreSQL. That's a pretty strong statement, but
since he met with Derby's architect last week, I tend to believe him. I'm assuming
since I got AppFuse working with DB2 that using it with Derby would be pretty easy too.
Bruce says there's supposed to be a Geronimo release this week. I thought they were supposed
to be done with Geronimo by this year's ApacheCon?
Now we're looking at an XML file that's a GBean configuration file. It looks like Spring is going to get some
competition for long class names. And if you thought Spring's XML was verbose - Geronimo puts
it to shame! I'm not saying this is a bad thing - it's just an observation.
GBean Archive - A JAR file that contains persisted GBean instances, GBean metadata. The Java classes
in the GBean can reside in the JAR or be dependencies in a central repository.
GBean Descriptor - dependencies and configuration are defined in XML.
Repository: Structured collection of JARs. Designed to work in conjunction with Maven (pluggable implementation).
Every JAR has a unique group and artifact id. Default repository is local file system, others allow auto-download.
Observation: Bruce's presentation is interesting - he seems to be targeting folks that want to dig
into Geronimo and customize it.
I think most developers just want to use it and would be more interested in seeing a demo of deploying an app on Geronimo,
rather than how to integrate Derby or Jetty into the server. If it's so easy to plugin a component, why hasn't Tomcat
been integrated? Maybe it's just me, I want to see it run and deploy apps to it - that's about all I want to do. In most
cases, I shouldn't need to customize it. It's nice to know that it's an option though.
Basic Configuration Builder: Deployers are J2EE specific (JSR-88). If you have standards-compliant deployment descriptors -
your application should deploy on Geronimo. Rather than calling them deployers, Geronimo uses "Builders". The Builders
/deployers create configuration objects containing GBeans. Most complex Builder is J2EE deployer. It implements
a JSR-88 deployment specification and accepts JARs, WARs, EARs, and RARs. You can also add in a deployment plan in XML.
From this, a Geronimo Configuration ARchive (.car) is created. The nice things about these builder is you can
do deploy-time optimizations, before the application is started.
Everything above the System Services and Kernel is hot swappable. You can remove the J2EE Configuration and replace
it with something else like Pico or Spring. This means that you'll be able to swap out servlet containers w/o shutting
down the server. That's pretty damn cool. If the system services and kernel are stable, and no JVM dumps occur - this
means that your Geronimo server could be running forever. Sounds awesome.
High-availability (clustering, etc.) has not been built into Geronimo yet. This is primarily because this is not
part of the J2EE spec. Developers are focusing on gaining 1.4 compliance, then they'll start looking at the fancy features.
Wow - good presentation Bruce. I feel like I know more about Geronimo than I ever wanted to know.
As I was getting ready to post the above transcript, I noticed that
Geronimo 1.0 M3 was released. According to Bruce's presentation, this is the last release before 1.0. Nice work gents.
. Next Monday I'll be in Vegas at ApacheCon. I've never done two different talks back-to-back before, let alone at two different conferences. Should be fun.