Computers: June 2005 Archives

P2P makes sense now

• more people (and machines) connected, more data at the edge
• more bandwidth
• more computing power

Limitations of Today's Internet

• physical addressing model (URLs, IPs)
• centralized DNS
• no QoS for message delivery
• optimized for point-to-point (limitations on multicast/anycast)
• topology controlled by network admin, not applications
• no search/scoping at network level
• binary security (intranet or internet)

What is JXTA?

• highly decentralized and reliable
• network protocol for creating decentralized virtual P2P network
• set of XML protocols, bindings for any os/language
• overlay network, decentralized DHT routing protocol
• mechanisms, not policies
• open source (want it to become core internet tech, wide adoption)
• www.jxta.org

What is different?

• JXTA addresses dynamically mapped to physical IP
• decentralized and distributed services (ID, DNS, directory, multicast, etc)
• easy to create ad hoc virtual networks (domain)

What JXTA does

• Brings devices, services, and networks together
• enables interactions among highly dynamic resources

Sample applications

• storage backup (321 Inc.'s LeanOnMe)
• Brevient Connect web conferencing
• grid computing - Codefarm's Galapagos
• SNS - social network application (most used P2P app in China)
• Verizon IOBI (trying to lower the cost of delivering content over the Internet)

Tangent: how do china's network filtering/blocking devices work with P2P apps? It seems like China has been doing two things -- trying to censor information coming in from outside of China, and trying to block Chinese-to-Chinese communications, when those communications don't toe the party line. While I won't say that it is impossible to filter/shutdown P2P, it seems like a hard problem.

JXTA status

• JXTA-Java SE (June 15th release 2.3.4)
  • APIs and functionality frozen
  • Quarterly release schedule
  • full implementation of JXTA protocols
• JXTA-C/C++ (2.1.1)
  • standard peer
  • extended discovery
  • linux, solaris, windows
  • rendezvous support
• JXTA-Java ME (2.0)
  • edge peer only
  • CDC 1.1 compliant
• community: C#, JPython

Looking ahead

• enhance ease of use and simplify network deployment
• enhance performance, scalability, security
• standardize specification further through public organization

Summary: I am totally in love with the idea of peer-to-peer, and JXTA has been on my list of things to check out for awhile now. I need to see how I can preach this at EDS.

Starts with overview of RSS, including uses for RSS, news readers, etc. Then moves into some more technical details of an RSS feed. Shortcomings of feeds:

• Users need one-click subscribe (no standards yet) - Safari RSS doing a good job
• 10% of all Feeds not well-formed XML
• Feeds can be lossy (don't poll often enough, will miss stuff)
• RFC 3229 (FeedDiff) can be used to address this
• Polling based -- traffic waste; HTTP conditional get and caching ease pain

FeedParser (SAX based) and ROME (DOM based) -- two Java libraries for parsing feeds. Atom is the future of feeds? Atom is becoming an IETF standard, which leads credence to this theory. It is a comprehensive and rigorous specification. RSS 1.0 uses RDF (ick), RSS 2.0 has most of the same functionality, but tosses the complexity of RDF. How to serve feeds:

• ROME serialization
• XML DOM serialization
• Template langauge: Velocity, JSP specification
• Plop it on a web server that supports conditional HTTP GET, etags, etc.

Publishing Protocols:

• OLD: XML-RPC based, ad hoc, simple: Blogger, MetaWeblog (most popular), Movable Type, WikiRPCInterface
• New: The REST based Atom Publishing Protocol
• Why not SOAP?

Atom publishing

• Supports features of existing protocols
• plus administrative features (add/remove users, etc)
• spec still under development, will be finished soon

Atom collections

• resources exist in collections
• examples: entries, uploaded files, categories, templates, users

What is ROME?

• Java library
• RSS/ATOM feed parsers and generators
• built on top of JDom
• Provides beans as API

Why ROME?

• existing solutions were incomplete, stale, had unfriendly un-Java API

Pros:

• simple to use, well documented
• single java representation of feeds
• pluggable
• widely used, got momentum

Cons:

• Loss of information at SyndFeed level (abstract all feeds, lose special features of specific feed types)
• DOM overhead

Harmony is a new project from the Apache Foundation, to do an Open Source J2SE implementation.

Why now?

• Lot of interest from community, companies
• J2SE 5 is first version where JCP license permits doing OSS implementation of JVM
• Sun cautiously supportive

Platform includes both VM and runtime (libraries) -- both critical to have J2SE implementation. Want freedom of license for components, flexibility of reuse (want to write your own JIT? Do that part, and reuse the Harmony runtime in order to get a complete system). Requires deep work (VM and JIT -- lot of hardcore CS stuff going on) and broad work (libraries -- just lots of code). They also want to build platform that is 100% compatible, and reasonably as fast. Goals: build community, build architecture, then get it finished and certified. The result will be to push Java into places where it isn't now, and where it cannot go.

Motivations:

• Not going to fork Java
• Not going to add new and incompatible technologies
• too hard, OSS can't do it -- wrong, OSS is just license & community, says nothing about technology
• license of VM is a major deal to some people
• What about Mustang? Not Open Source.
• Enable widespread adoption of Java, without re-engineering
• Provide open and free platform for Linux and BSD communities
• Java is 2nd-class citizen on Linux, Mono making big inroads...
• Get at developing economies (like Brazil), that can't afford commercial licenses, or have government directive to embrace Open Source

Design will emphasize portability, so it can run on many platforms.

State of OSS Java:

• Kaffe VM - borg of VMs (absorbs everything), focus on portability, but performance lags. Harmony is going to work with them
• GNU Classpath - Java class library; long-running; work with them, but licensing issues
• Jikes RVM - research VM; VM written in Java (little C and ASM for bootstrap); good performance characteristics
• ORP C/C++ research VM (Intel research); under Intel license
• GCJ - compile Java to native binary; lot Harmony can learn from them
• KVM - run Java bytecode on Mono (fast); not Harmony approach, but learn from them
• JavaL(?) - brazilian effort similar to Harmony

In summary, I think that Harmony is a great project. Java is going to need a truly open source implementation if in order for it to remain relevant and popular for the next 10 years. However, this is going to be a very hard project, on the implementation side. So, while the though of having an OSS JVM is exciting, I have to temper this with the fact that I think it is going to take Harmony a long time to produce a working JVM.

I got to James Gosling's general session over a half hour late this morning (the balance I had to strike between Caltrain's schedule and my sleep schedule). Here are some highlights:

NetBeans has a new set of tools for developing code for mobile phones. Visual app. builder, can also deploy code to phone from NetBeans. Even cooler, if the phone supports the correct JSR, you can do debugging of the app. while it is running on the phone. Single step, breakpoints, etc. -- all over Bluetooth!

They did a demo of an UAV that is powered by real-time Java. The conclusions:

• RTSJ determinism critical for navigational control
• RTSJ JVM enabled significant productiivity gains over C++ (don't need to worry about low-level stuff like endianess, etc.)
• Continue to perform research on newer RTSJ implementations

The summary for me is that I would like to check out real-time Java. Yet another thing on my list of "things to surf".

Sun is putting out multimedia versions of all of the JavaOne sessions onto the Internet, free for all (including slides, audio, etc.). Allowing Open Source contributions of translated audio tracks? It seems like people can watch in English, and record their own track, in a different language.

---

Shifting gears, the second half of the general session is a panel, about the future of Java. On the panel: James Gosling, Bill Joy, Paul Saffo, Guy Steele, and Danny Hillis (Applied Minds, Inc.). This was just a general talk on a bunch of futuristic mumbo-jumbo -- I wasn't really engaged to the point that I extracted anything interesting.

I spent some time vendor pavilion at JavaOne today. One of the vendors that I spent some time pick on was Sun. In particular, I had hardware on the brain toady, and I managed to track down like, the one person at Sun's booth, who could speak about the present and future of the UltraSparc line. In addition, this fellow was there to talk about the V20z, so I asked him a few questions about that as well.

Regarding the UltraSparc, both the UltraSparc IV and UltraSparc IIIi are currently shipping. The UltraSparc IV has both CMT (Chip Multi-Threading, sort of like Intel's Hyperthreading, but better according to Sun) and multiple cores per CPU. It sounds pretty hot. Unfortunately, it seems like it is only going to appear in Sun's higher-end servers (5U and up), in high densities. The Sun person that I spoke to wasn't sure if it would ever materialize in a workstation, but was doubtful.

The UltraSparc IV is going after highly-parallelized workloads, as is the rest of the industry. However, my group at EDS is working with some applications that are stuck on Sparc, and aren't highly parallel. So, it seems like we're going to be using the UltraSparc III series for awhile. The good news is that the UltraSparc III is up to 1.6Ghz in speed now, which is not too shabby (for a RISC CPU).

Moving on to the V20z, I cut right to the chase on this one. i knew that the only reason to buy an X86-based server from Sun would be for the management features. Luckily, I was not disappointed. The V20z has two Ethernet interfaces for the purposes of management. Even better, once you configure an IP on the Ethernet, you can SSH to it, and get full access to the serial console (OS), or the internal management console! That sold me right there. In addition, the management Ethernet ports can act as a hub, which means that you can daisy chain a rack of servers together, and only take up one switch port for management. That is really, really cool. One thing is that you have to use crossover cables, because the management ports don't support auto MDI-X (while the main GigE interfaces do).

I don't really keep up with the state-of-the-art for PC servers, but I don't think that you can do SSH management of them. Sun is definitely kicking ass here.

-Andy.

Where is the Pain?

• GUI creation and maintenance
• Threading issues
• Widget <-> model binding (n-tier application)
• Input validation

Reaching Nirvana

• All about frameworks -- buying, building, or using them
• OSS frameworks are ideal (great to have source code)
• building should be last resort

No uber framework

• Ideally, one framework would solve problem
• doesn't exist
• Two wannabees: NetBeans platform and Spring Rich Client Platform (RCP)
• Vibrant space (new projects popping up all the time)

NetBeans

• Doesn't address pain points for big apps
• lack of documentation (yeah, I agree)

Spring RCP

• Inspired by Eclipse RCP and JGoodies
• Not released yet, lot of code in CVS
• not ready yet, but keep an eye on it

No comprehensive framework, some smaller focused ones

• JGoodies Swing suite ($$$) - has been released, some free parts
• SwingLabs - Sun's OSS collection of helper frameworks. Also not out yet.

Solving the Pain

• DRY - don't repeat yourself. Do something twice --> build framework
• Think Ruby-on-Rails (interesting web framework)
• Ruby-on-Rails was built this way, so it was a framework that was built in an interactive manner, only for functionality that was actually needed.

Reuse hard in Swing apps, because no strong conventions, GUI layout code can be everywhere.

Solutions

• GUI builders, but with restrictions
• Use GUI builder to generate binary artifact (like XUL), user-modifiable code sits outside
• Load generated GUI at runtime, and manipulate it
• Provide standard contract for screen creation
• Introduce form abstraction (smaller than screen, larger than a widget)
• Both practices increase opportunities for reuse

Framework examples

• JFace has Window and ApplicationWindow classes
• Spring RCP defines Page and View abstraction that aligns nicely with Screen/Form concept

Threading Issues

• Swing components are not thread safe -- only supposed to be accessed by AWT event thread.
• SwingWorker (new in Java 6, being back-ported to Java 5) and Foxtrot?
• Comega - experimental programming language from MS, used as a sandbox
• Concurrency is hard -- Servlet API is admired, because it is simple and single threaded, yet it scales up
• Because there is a container that does heavy-lifting of thread issues
• Container-managed Swing (Inversion of Control)
  • Have container control object, and provide services for object
  • Load and initialize screens on background thread
  • Handle asynchronous population and action execution

Tools

• JFormDesigner - excellent GUI builder tool
• Matisse - next version of NetBeans
• FormLayout - 3rd party layout manager that kicks GridBagLayout in the you-know-where
• IntelliJ IDEA - IDE

Summary: This was a pretty good talk. The take-aways are to go and keep tabs on some of these frameworks (they may need another year), and to look into some GUI builders and 3rd party layout managers.

Two things that suck about JavaOne: it is nearly impossible to find power outlets for my PowerBook, and not all of the rooms have WiFi. OSCON puts JavaOne to shame -- nearly every room has a giant block of power strips, for the geeks to plug their laptops in. It is deplorable that JavaOne doesn't have this.

As for the lack of WiFi, I'm finding myself a bit surprised by this one. I'm finding that since I am blogging the conference this year, having the web available is necessary in order for me to sprinkle links into my posts.

-Andy.

Collaboration Technologies

• occurs within conversations, unlimited # of participants
• all messages to all participants
• conversations include multiple channels (conduit for information)
• collablets provide interface to channel

Collablets

• software component for specific type of collaboration
• stateful within scope of conversation
• only know about their own channel
• uses XMPP (Jabber)

MOXC

• message oriented XML collaboration
• web services approach to collaboration
• simple, just send XML messages using SOAP
• send messages over any transport
• can describe collablet API via WSDL, open to any web services client

All of these technologies allow for integrating collaboration into IDE. Jabber chat is one example, but can also send java code back and forth. Messaging system understands code -- code that you paste in IM is syntax colored, in the right font, same features of IDE (code completion). Can also send XML, HTML, formatted text, etc.

Can go further, and share whole files or projects. In shared file, can have shared editing, sortof like SubEthaEdit. It will lock the portion of the file, make change, when lock times out, will propagate change to other users. Remote users can compile shared project, which will actually happen on source machine (to snag all dependencies).

It seems like the point of the above technologies is to make it easy to implement your own collablets, so you can build custom collaboration modules that suit your particular project or work environment. Very cool.

What about screen sharing (code walkthrough, remote peer programming)? I didn't see the speaker demo this, but it should be possible to make a collablet that does it.

Links:

• Developer collaboration is going open source at: collab.netbeans.org
• Public collaboration service: share.java.net
• Blog about remote developer issues: http://www.toddfast.com

Also thinking about sharing debugging environment as well.

Downside: need some sort of server to do it on Intranet, with Java Server Enterprise. Close to getting it working over any vanilla Jabber server (sweet!).

Jini is a tool for building SOA's. The Master/Worker pattern is a common one in Jini systems.

Generic Virtual Data Access Layer (SOA)

• Distributed data, bring together (left joins?)
• Data is federated (many masters)
• Expose common Grid-like API for clients (JAR), or WebServices, or even JDBC
• Needs virtual data dictionary, metadata to describe data, to glue together
• Decompose data access into generic workers -- break down request/response into many sub-tasks
• Decouple SQL query generation from execution
• Distribute workers, get parallelism

Scalable Real-time Transaction Processing

• Parallelize transaction w/o losing FIFO ordering, and still getting 100% reliability
• Clustered JavaSpaces -- make several instances. Make reliable by replicating data in these instances.
• Build smart proxy that handles JavaSpace client requests, and distributes work into JavaSpaces cluster
• Automate deployment and restart of JavaSpace instances, using dynamic service-grid architecture -- gets you dynamic scalablity (apache httpd forking style)

Why now?

• memory was expensive -- not anymore
• Bandwidth was a bottleneck -- not anymore (GigE, 10Gig)
• Commodity HW finally enterprise grade

Building a Distributed Compute Grid Framework

• design grid applications incrementally with Jini and JavaSpaces
• from programmers perspective:
  1. how design application?
  2. how implement the design?
• too much talk about design, not enough about programming
• Good design always starts with something simple and evolves -- Jini and JavaSpaces make this easy: loosely coupled components, dynamic and flexible infrastructure
• Features can be added as needed

Grid computing framework

• master-worker pattern based compute farm
• A layer of abstraction over JavaSpaces API and Jini programming model
• Framework class design
  • Decomposer - concrete class will decide what correct subtask size is
  • Distributor
  • Calculator (processor)
  • Collector
  • Task
  • Result
  • Communicator - communication and synchronization among compute nodes

Putting the Spring into Grid

• have to consider user interface for the programme
• How can we take POJO model and bring it to Jini/JavaSpaces?
• Get a lot of power in POJO approach, because we decouple from underlying system (be it Jini, J2EE, etc.)
• Spring can do remoting without API via exporters on server side, proxies on client side (talk to exporters)

Summary: I like the idea of doing a Grid overlay of federated databases. This is something that I'm going to need to explore more on my own.

These are rough notes, as I was only there for the first part of this BOF and it was pretty informal:

expose scripting interface to your program. allows 3rd parties to write code that interacts with your code (think plugin). Develop features and addons more quickly & cheaply.

idea: add beanshell to existing application. Once in place, you can use beanshell to poke and prod it, and figure out how it works. Questions like: "What happens to app if I change this value?" are easy with an application that supports BeanShell.

to support scripting in an existing app, may need to provide:

• extra API to support scripting
• debugging support
• logging/diagnostic output
• CLI for interactive control
• Editing tools for recording/manipulating scripts (macro recorder)

Doing JSR for BeanShell, to make it standardized, and potentially part of Java proper (someday). Will give more visibility and participation. BeanShell being developed by small team, so this will expand resources. New in 2.0:

• Full java syntax compatability
• performance: JavaCC 3.0 parser faster and smaller; caching of method resolution gives boost
• better error reporting
• Applet friendly (again) -- doesn't trip applet security; advantage of existing reflection-based implementation (do things w/o code generation)
• new features: mix-ins, properties style auto-allocation of variables (can use BeanShell as more advanced java properties file)
• Mix-ins: import java object into BeanShell namespace.

Java Syntax Compatibility

• Full java 1.4 syntax support (on all VMs)
• Some Java 5 features (all VMs): Boxing, enhanced for loop, static imports
• Core Reflection doesn't allow introspection into core types -- added this in BeanShell 2.0

True Scripted Classes

• Generated classes with real Java types, backed by scripts in the interpreter.
• Scripts can now go anywhere Java goes.
• Expose all methods and typed variables of the class.
• Bound in the namespace in which they are declared.
• May freely mix loose / script syntax with full Java class syntax.
• Full java syntax on classes -- this, super, static, instance variables, and blocks. (no way to access superclass from reflection API)
• Full constructor functionality.

Limitations:

• Reflective access permissions (knocks out applets for the scripted classes)
• bugs

New APIs:

• javax.script (JSR-223) - will be a part of Java 6, powerful API for calling scripting languages from Java
• BeanShell API compiler - have persistent classes backed by scripts.

Compiled API classes are like python -- you can take a .bsh script, and compile it into a .class file. Then it can be used by native Java code. Will it be like Python, in that if you modify the .bsh, it will automatically re-make the .class? I asked about this, and I found that this is sortof different from what Python is doing. Basically, the .class file only includes a stub, that wraps around the functionality that is implemented in the .bsh file. This stub allows the Java code to invoke the functionality of the .bsh file. Behind-the-scenes, BeahShell will launch a separate JVM for each .class file. This separate JVM will execute the code in the .bsh file.

New BeanShell community site, includes Wiki (J2EEWiki). Wiki site is beanshell.ikayzo.org/docs. Subversion for source control.

J2EE specification doesn't go far enough -- need "helpers" in order to be productive and effective in order to produce a J2EE application. Certain "artifacts" are common, such as:

• Generate entity beans from DB
• Using resources (JMS, JDBC, etc)
• Using patterns (service locator, etc) and Blueprints
• Provisioning server resources
• Verifying, profiling.

Offload some of these tasks to tools, others to specifications/core langauge/etc. How does this talk contrast with the Spring talk (which says that all of this crap should be handled by frameworks)?

J2EE 1.4 free tools:

• Eclipse - Web Tool Platform (WTP) / J2EE standard tools (JST)
• NetBeans - 4.1 just shipped (May), full support for all J2EE whiz-bangs

NetBeans notes:

• NetBeans can do one-click compile-assemble-startserver-deploy-execute (Run)
• Refactoring at J2EE level (class name change propagates to descriptors)
• Ant native (project in NetBeans makes build.xml). Good for nightly builds!
• Blueprints compliant -- what is this? Need to look it up. Looks like best practices for J2EE application layout.
• Debugging: hides crap from application server in stack trace. Monitor HTTP requests. J2EE verifier tool.
• Can get JBoss plugin for NetBeans.
• Wizards for making EJB calls, doing JDBC access, or sending a JMS message

Java EE 5

• "The focus of Java EE 5 is ease of development"
• EJBs as regular Java objects (standard interface for inheritance)
• Annotations vs. deployment descriptors (dependency injections)
• Better default behavior and configuration
• Simplified container manager persistence
• Developer works less, container works more (app server)

Annotations

• comments that guide code?
• alternative to XDoclet
• Syntax is to use '@' symbol

EJBs are POJOs

• only a business interface to work with
• XML descriptors replaced by annotations

It looks like if I just learn how J2EE 5 works, I can skip learning the older version, which is far harder/more complicated. EJB 3.0 requires dramatically less XML code to be written in order to work, and less Java code as well. Looks like this stuff isn't fully baked yet, however. :( See below:

Java EE 5 status

• specs still under expert discussion
• delivery date is targeted for 1Q 2006
• Many areas ready: API simplification, Metadata via annotation, dependency injection, persistence
• NetBeans 5.0 will be ready at same time

GlassFish Java EE 5 application server is some sort of new app server being written by Sun. Preview builds are available now? GlassFish purportedly works well with NetBeans. Plus, it looks like it is open source (which you know that I like).

Tools mandatory for J2EE 1.4 development. Features of Java EE 5 make development easier, and will be further assisted by smart tools. I knew that there was a new version of NetBeans out, which I was intending to check out at JavaOne. Also, it looks like there is a new NetBeans book out -- "NetBeans IDE Field Guide" which is good, because I don't like the documentation for NetBeans...

I'm going to pick up a bit of a new format. I'm going to try and blog about the parts of the presentation that are interesting to me, getting away from a full outline of the talk. I figure that the slides can probably be found online somewhere, so I'm going to focus on what my take-aways are.

-Andy.

Research goal is transparent extension of Java programming model and facilities to a clustered environment. More for performance, than failure issues.

Design Approaches:

• Cluster-aware JVMs (potentially optimal [close to hardware], but loses portability)
• Compile to cluster-enabled layer (ex. DSM; good performance, but lose portability and impedence mismatch)
• Systems using standard JVM (transforms at code or bytecode level). lose performance but get portability

Compile to DSM:

• Hyperion - compiles to C code that is DSM aware
• Jackal - violates Java memory model

Cluster-aware JVM software:

• Java/DSM (Rice, 1997) - piggybacks on existing DSM, no JIT
• cJVM (aka trusted JVM) (IBM, 1999) - proxy objects for non-local access (smart), no JIT
• Kaffemik (Trinity college, 2001) - based on kaffe VM, scalable coherent interface, JIT
• Jessica2 (2002) - JIT support, thread migration
• dJVM (2002) - based on Jikes

Systems based on standard JVM:

• JavaParty (1997) - pre-processor + runtime compiles to RMI. Requires langauage change
• JSDM (2001) - supports SPMD apps, not full Java technology
• JavaSplit - bytecode transformation, integrated custom DSM
• J/Orchestra - application partitioning, bytecode transformation

The executive summary is that there is some work going on to make Java cluster-aware at the VM level. I'm not sure why Jini wasn't mentioned more, since it seems like a natural fit for clusters. If I ever need to do some clustering, I can check in on the above projects to see if there is a fit.

What is XQuery?

• New language from W3C
• Queries XML (documents, rdbms, etc.)
• Anything with some structure
• under development, not 1.0, at candidate recommendation stage

XQuery advantages over:

• XSLT - easier to read and write, maintain; designed with DB optimization in mind
• SQL - better for hierarchical data (things that don't fit: book data, medical records, yellow pages). DB is designed for columns of numbers.
• Procedural - define what you want, let engines optimize

demo

• When pulling data out of XML, easier to show more context around the data
• Like breadcrumbs to book, chapter, section
• Then show not only the search term, but also the content around it

Loading Content

• depends on engine, indexed stores require pre-loading

Vendors

• Mark Logic (presenters, demos available), eXist (OSS), Saxon
• Coolest hidden XQuery implementation: Apple's Sherlock

XQuery uses XPath

• a matching language to select portions of an XML document
• Like RE engine for XML; "give me every one of these where that or this"

FLWOR expressions

• pronounced "flower"
• stand for: for, let, where, order by, return
• this is one expression, not five
• XQuery is technology to manipulate XML that you can find with XPath
• XQuery doesn't have to produce XML output -- can produce sequence of elements, or just plain text

Deployment: CGI-style

• Works well on web tier
• Executes in response to HTTP requests like CGI
• Speaks XML to back-end, XHTML to front end
• advantage is easy-and fast, can do blog or searchable FAQ as XQuery (backend is XML, XQuery formats and displays on frontend)

Deployment: Direct Style (POJO)

• Call XQuery stack from Java language
• Think JDBC but for XQuery
• Fits in your Java technology stack

Deployment: JSP Style

• XQuery JSP tag library
• send results straight out, or store in variables

In summary, I feel like I finally understand what XQuery and XPath are all about. This presentation gave a fantastic overview of both, in a way that was engaging and made the two complimentary technologies easy to understand. I don't know if these two technologies are directly relevant to my current work at EDS, but who knows what the future may bring. If you are working with structured data in XML, you need to check out XQuery and XPath.

Got to this one late (lunch), so this is not full notes.

Extended Persistence Contexts

• Rescue the stateful session bean from obscurity
• natural cache of data that is relevant to a conversation
• allows stateful components to maintain references to managed instances instead of detached instances

Conversations

• A conversation takes place anytime a single user interaction spans more than one request
• sometimes helpful to capture conversation in object(s), can optimize, manage lifecycle, etc.

To be quite frank, the content of this session bored me, so I exited early. The basic summary is that if you are doing hardcore EJB and database stuff, you may want to check this topic out in more detail.

Agile J2EE: where do we want to go?

• Need to produce high quality apps, faster and at lower cost
• cope with changing requirements (waterfall not an option)
• need to simplify programming model (reduce complexity rather than hide with tools)
• J2EE powerful, but complicated

Agile J2EE: Why important?

• Survival: challenges from .NET, and PHP/Ruby at low end
• Concerns that J2EE dev is slow and expensive

Why aren't we there yet?

• Difficult to test traditional J2EE app
• EJB's really tie code to runtime framework, hard to test w/o
• Simply too much code, much is glue code (I concur, based on my experience with a J2EE portal in EDS)
• Heavyweight runtime environment -- in order to test, need to deploy

Enter Lightweight Containers:

• frameworks central to modern J2EE development
• frameworks capture generic functionality, for solving common problems
• J2EE out of box doesn't provide a complete programming model
• Result is many in-house frameworks (expensive to maintain and develop, hard to share code)

Open Source Frameworks

• Responsible for much of the innovation in the last 2-3 years
• Several projects aim to simply development experience and remove excessive complexity from the developer's view
• Easy to tell which ones are popular; driven by collective developer experience (refined, powerful, best-of-breed)
• Tapping into "collective experience" of developers

How do Lightweight Containers work?

• Inversion of Control/Dependency Injection (sophisticated configuration of POJOs)
• Aspect Oriented Programming (AOP)
  • provide declarative services to POJOs
  • can get POJOs working with special features, JMX, etc.

What is Inversion of Control?

• hollywood principle - don't call me, I'll call you
• framework calls your code, not the reverse

What is Dependency Injection?

• specialization of Inversion of Control
• container injects dependencies into object instances using java methods
• a.k.a. push configuration -- object gets configuration, doesn't know where it came from
• decouples object from configuration from environment. Values get pushed in at runtime, so it is easy to run object in test or prod.

Why is Dependency Injection different?

• configuration requires no container API
• can use existing code that has no knowledge of container
• your code can evolve independently of container code
• easy to unit test (no JNDI stub, or properties files to monkey around with)
• code is self-documenting

Advanced Dependency Injection:

• shared instance, pooling
• lifecycle tied to container objects
• maps, sets, other complex types
• type conversion with property editors
• instantiation via factory methods
• FactoryBean adds level of indirection; configured by framework, and returns objects based upon that configuration.

What is AOP?

• paradigm for modularizing cross-cutting code (code that would otherwise be scattered across multiple places)
• think about interception
• callers invoke proxy, chain of interceptors decorate that call with additional functionality, callee finally invoked, and return passes back through chain
• idea for transaction management and security
• enabling technology, for defining own services, and applying them to POJOs.

Incremental AOP

• think of it as a generic way similar to how EJB implemented
• can be implemented with dynamic proxies

DI + AOP delivers POJO ideal

• configure objects w/o invasive API

Spring Framework

• OSS project, apache 2 license
• Aims:
  • simplify J2EE development
  • provide a comprehensive solution to developing applications built on POJOs.
  • aims to address all sorts of applications, large banking, or small in-house
• easy to work with JDBC, Hibernated, transaction management, etc.
• consistency makes Spring more than sum of its parts.
• don't need to deploy, can all run from within IDE if desired.

Terms:

• AWS - Amazon Web Service
• ASIN - Amazon Standard Item Number
• Associate ID - pass this # into all AWS calls
• REST - Representational State Transfer

Concept is the programmable website

• support for industry standards
• remote access to data and functionality
• about getting direct access to guts of website

What is AWS?

• APIs that give any developer outside of amazon programmatic access to Amazon's data and technology.
• Includes product information, customer-created content, shopping cart, etc.

Why AWS?

• Legitimize outside access, site scraping sucks
• Third-party developers extend the Amazon platform
• Harness creativity of others

Offering:

• SOAP API
• REST API
• XSLT transformation service - can apply transform to XML results before returned. Can build website with no physical template, just supply XSLT stylesheet, in order to build "virtual website".
• WSDL - documentation for schemas
• Tons of documentation & community outreach

REST vs. SOAP:

• SOAP is standard, strongly typed, requires toolkit
• REST is convention, ad hoc, easy ramp-up, prototype in browser, really easy to use. Key-value pair based. Easy to script. Develop in browser.
• REST is about 80% used, SOAP other 20%.

Getting started:

• http://www.amazon.com/webservices
• developer blog: http://aws.typepad.com
• download documentation

Summary:

• Amazon offers 3 different things via web services API
• Easy to use via Java
• WebServices is like an API for specific websites, allowing 3rd party developers to build new sorts of apps just like if you were to write an app for the Windows API.

After a too-short recovery time from NYC, I am in San Francisco today, attending Sun's JavaOne conference. I am going to be trying to blog about each session that I attend, and then cross-posting my public posts to the EDS blogosphere. So, for my non-computery readers (you know who you are), you're going to want to ignore the next like 3 days or so.

-Andy.

I read a great interview with Linus Torvalds the other day. The main thrust of the interview was questioning Linus as to where the Open Source vs. Commercial Source divide is ultimately headed. Pretty interesting stuff, and well worth a read.

I have been doing some thinking about this as well recently, as I try and evangelize Open Source at EDS. My thoughts are pretty similar to where Linus is at. Open Source is going to continue to commoditize certain things like OSes, browsers, and potentially even office suites. The key for Closed Source commercial vendors is going to be to stay one step ahead of the curve, and earn their revenue by innovating. People will pay in order to be at the cutting edge, the state of the art. And companies will pay for support. Those are the two spaces that I increasingly see commercial vendors playing in.

-Andy.