I started working in systems programming as a middleware guy writing the low level plumbing in queuing systems aimed at high volume telco applications. I moved on to CORBA (and also started to work with the open source TAO ORB and ACE framework), mostly in C++, with a bit of Java for management infrastructure. After that I worked on building J2EE servers - everything from the Web tier load balancer to EJBs. After that, it was portal, Web services, mobile infrastucture, more transactions, integration frameworks, etc. Almost all the work was the innards. Like ever profession, sofware makes careers a matter of specialization to some degree. For a while I resisted this, but its darn hard to be an effective generalist.
While I've always enjoyed the middleware work, I often struggled with the question of how best to make it useable for non-specialist developers. People who need to implement business logic and Web enable their applications. One of the first times I had to build a real Web application was to show off the work we'd done on one of the first EJB 1.1 containers back in 1999: we had a B2C application (and framework) that we wanted to "port" to use EJB. That's when it really struck home that J2EE didn't really solve the problem for the application developer. Just simple problems like correlating the lifecycle of EJBs to servlets was a nightmare. So I started to write light weight frameworks to tie things together to make it possible for our end user to use J2EE technologies together -- but always felt that was the perspective that the J2EE umbrella specification should have taken from the beginning.
Now we have layers on top of J2EE that make many aspects of the application server more of an SPI: the application server is necessary and important for reliability and consistency of applications, but J2EE is less and less the programming model for end users. The folks that pushed this the furthest and, in my opinion, did the best job were the consultants that developed the Spring framework. At first, I was skeptical at some of what they were doing (treating JTA as a dependable interface without knowing the innards of the application server was a primary concern), but now that the framework has gotten traction, most of the application servers have actually adapted to Spring -- OC4J, for example, is independently certified to interact with Spring correctly. That the "big guys" are bending over backward to accomodate a framework that replaces a big section of J2EE as an API is something I wouldn't have guessed would happen back in, say, 2001. At the end of the day, though, its a great development that really seems to benefit everyone involved.
I've just started to poke around with the new Spring Web Flow framework, which seems to be the right solution at the right time. Managing scopes in Web apps can be a real pain and if this does for state management what Spring does for application logic, score another one for Interface 21 -- and for Java in general.