Application Platform Strategies Blog

No surprises from Oracle

Blogger: Anne Thomas Manes

Oracle just briefed the world on its product roadmap and the integration of its BEA products. The good news is that there were no surprises. It's nice to know that adults are piloting the ship and making rational decisions.

UPDATE: Oracle has posted the briefing slides.

Quick summary:

Oracle will maintain the WebLogic brand name. Oracle will release rebranded versions of the BEA products within 100 days. It will deliver converged products over time.

Oracle WebLogic Server (WLS) will be the strategic application server going forward. Key features from OC4J will be added to WLS, including Toplink and the SCA container. Thomas Kurian indicated that the next major release will adopt an OSGi kernel.

Oracle Service Bus (formerly known as AquaLogic Service Bus [ALSB]) will be the strategic ESB going forward. Key features from Oracle ESB will be added to ALSB.

Oracle BPEL Process Manager remains the strategic BPEL engine. Oracle will develop a new converged BPM system based on Oracle BPA and AL BPM.

Oracle Enterprise Repository (formerly known as AquaLogic Enterprise Repository [ALER]) will provide the foundation for Oracle's SOA governance solution. Other products include Service Registry (OEM'd Systinet), Web Services Manager, and Management Pack for SOA (a plug-in to Oracle Enterprise Manager). BEA's OEM agreement with AmberPoint is history.

More later...

Progress on the hunt: Resistence is futile

Blogger: Anne Thomas Manes

Progress Software snapped up Mindreef yesterday. Mindreef is the maker of SOAPscope, a popular SOAP quality, testing, and diagnostic suite. Progress will add SOAPscope to the Actional product line, its SOA governance family.

"We are the Borg. Lower your shields and surrender your ships. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile." -- The Borg, Star Trek: First Contact (1996)

This is Progress's second acquisition in as many weeks. Last week Progress announced its intent to acquire IONA Technologies. IONA is best known as the leading CORBA provider, but it is also an innovative player in the SOA/ESB market. IONA has two SOA infrastructure product families:

• Artix: a commercial line of products based on Artix ESB. Artix has the distinction of using a very different type of architecture from any other ESB on the market. The closest architectural match is Microsoft's Windows Communication Foundation (WCF). The product family includes an ESB, an orchestration engine, a data services platform, a mainframe services platform, a registry/repository, and a channel connector for WCF.
• Fuse: an open source line of products based on various Apache Software Foundation projects, including ServiceMix, ActiveMQ, CXF, and Camel. IONA contributes extensively to these projects.

These two acquisitions follow closely on the heals of Progress's acquisition of Xcalia in March. Xcalia is now part of Progress's DataDirect operating company and supplies a data services platform based on the Service Data Object (SDO) standard.

OSGi - A Component of the Next Generation Platform?

Blogger: Kirk Knoernschild

There are many forces that influence technological evolution. After a decade of building enterprise applications on the web, today’s enterprise application platform is slowly evolving to the next generation application platform. What exactly are the components of this next superplatform?  Without question, as the next generation platform slowly evolves, a significant aspect will be the programming models and frameworks that team members use to develop and deploy enterprise applications.

The OSGi Service Platform is a dynamic component system for Java. Succinctly described as “SOA in a JVM”, OSGi provides extended capabilities on the Java platform that include the ability to deploy multiple versions of a component, discover new components dynamically, and deploy components without restarting the system. Because component relationships are carefully managed by the OSGi runtime environment, the benefits of modularity yield the potential for dynamically adaptable software systems. After flourishing anonymously in the embedded systems and networked devices market for almost 10 years, OSGi was popularized by Eclipse upon the foundation's adoption of OSGi as its core plug-in technology in 2004. While still in its infancy within the enterprise, OSGi is poised to surface as the core component model of the next generation Java platform.

While Burton Group believes OSGi is an important technology standard worth adopting, what is your perspective? As part of upcoming Burton Group research, I’d like to ask that you take a few moments to complete a brief survey that will inform us on your point of view on OSGi adoption within the enterprise. I'll leave the survey open until May 30, 2008. I appreciate your help

Spring-ing past Java EE?

Blogger: Joe Niski

SpringSource has been busy this month, just as I put the finishing touches on Burton Group's first in-depth look at the flexible Spring Framework (It's a lightweight container! It's a data access tool! It's a web framework! It may not wash your car, but you could extend it . . .)

For many developers tired of the grunt work involved in Java EE programming, Spring has made life easier for over four years. Today's announcement of the SpringSource Application Platform just might free developers from ever touching a Java EE server or deployment descriptor ever again. (Well, maybe eventually . . .)

Built on the Apache Tomcat servlet container, the innovative and proven OSGi service framework, and Spring, SpringSource Application Platform offers functionality comparable to a Java EE server but with a more modular service infrastructure and a more developer-friendly programming model than Java EE. It has tremendous potential to live up to its “next-generation application platform” label.

The combination of SpringSource Application Platform and the Spring Enterprise Edition bundle of support, software, and tooling constitutes a full stack for enterprise software development, deployment, and management. It may seriously disrupt the server market currently dominated by IBM, BEA, Oracle, and RedHat in the next two to four years.

BEA is now officially Oracle

Blogger: Anne Thomas Manes

Late breaking news: Oracle completed its acquisition of BEA. Details regarding product roadmaps are not yet available.

Oracle Makes another Bid for BEA

Blogger: Anne Thomas Manes

Well, it took a while, but Oracle finally came back with another bid for BEA. This time, the bid is $8.5 billion.

More info on the deal is available here.

The difference between SOA and 3-tier

Blogger: Anne Thomas Manes

Jeff Schneider recently started a thread on the Yahoo! service-orientated-architecture discussion list asking for a comparison between SOA and 3-tier. Here's my response:

3-tier or n-tier application architecture is just that -- an *application* architecture. It's focus is on building monolithic applications that can be distributed across multiple processors to increase performance and scalability. The tiers represent different aspects of the application: presentation, business logic, and data access. But the fundamental architecture doesn't talk about services, and it has never stressed reusability -- except at the DBMS layer.

SOA and n-tier are somewhat orthogonal -- you can build the various application tiers from services. Folks that built n-tier systems with CORBA or similar service-oriented technology were more likely to use services than most others. But consider the predominant n-tier development environment in use today -- Java EE:

• presentation implemented with JSP/servlets
• business logic implemented with POJOs or EJBs
• data access logic implemented with JPA/Hibernate

I don't see much that looks like SOA in this model.

SOA operates at a significantly different level from n-tier. SOA is focused on reducing the amount of redundancy in the corporate application portfolio. I've said it before: SOA is an enterprise architectural style rather than an application architectural style. SOA doesn't focus on individual application architecture. It focuses on encapsulating discrete functionality into services.

SOA and n-tier architectures have one thing in common -- they focus on separation of concerns. But SOA takes SoC to a new level. I think of it as refactoring application systems. (similar to refactoring code,
but on an enterprise  application architectural level).

As industry experience with SOA matures, I expect we'll start to develop new application architectures that more effectively exploit a development model based on services. SCA is a start, although still
way too immature for prime time. I expect to see some synergy develop among RIA, widgets and gadgets, mashups, composite application development, and services.

I also expect that the concept of "application" is likely to go away. Why is it that we as systems users have to be constrained by the limits of this artificial boundary called an application? Why do I have to shift my focus among multiple applications? Why do I have to copy data from one application to another? Why do I have to launch this stupid browser or that stupid application to get my work done? Why isn't everything just accessible to me from my desktop (via widgets and gadgets) or from within my preferred operating context (e.g., email)? Why can't I just link to whatever I need? (think REST)

Think outside the box!

Chris Haddad talked a little about the need to abandon traditional n-tier concepts and the MVC design patterns in his blog post, MVC Matrix and the Red Pill.We'll be talking a lot more about this next generation application platform this year. Stay tuned.

MVC Matrix and the RedPill

Blogger: Chris Haddad

In the near past, Java Servlets, ASP-Classic, and Perl scripts were the truth for web application development. Developers were beholden to HTTP name/value pairs and generated HTML pages via page templates. In 1996, I had a meeting in Redmond with a Microsoft lead Program Manager for ASP Classic. I mentioned that ASP Classic did not enforce a correct separation of concerns between page layout, actions, and business logic. I was thrown out the door and exiled from Redmond for ten years. During my exile, I built intranets with various technologies including ASP Classic and COM, ASP.NET and C#, Apache Struts and Java Server Pages (JSP), in-house developed widget libraries, and DHTML and JavaScript. During my journey out in the cold, I found a sense of elegance missing from all solutions.

 

Over the years, best practices morphed from tightly coupled page templating to use of a Model-View-Controller pattern. But MVC-oriented web applications have glaring limitations. The frameworks subvert the Web model (for example, Universal Resource Locators [URLs] are no longer valid) and convoluted ‘switch’ statements are often used to route client requests to back end transactions.  Additionally, the browser container hailed in the late nineties as the ultimate application host has enslaved application development and balkanized the runtime landscape. A disconnect between client and server capabilities existing in the frameworks, supported languages, and domain models. Client tier development has remained on a starvation diet for the last eleven years, and the backlash against the gaunt, thin clients is on the rise.

 

While presentation frameworks have experimented with event models and added buzzwords to their ‘features list’ (AJAX, Web 2.0, Service Oriented Architecture [SOA], and Rich Internet Applications [RIA]), a Redpill is needed to break out of the MVC Matrix and enable creation of ‘fit clients’. Vendors such as Adobe, Appcelerator, and Lazlo Systems  enforce loose coupling between client pages and server-side application logic by injecting a service layer. A message-oriented interaction instead of a page-oriented interaction will enable developers to experience a new perspective on application interactivity, decouple client-side technologies from server-side technologies, and break down traditional application silo boundaries.

BEA rebuffs Oracle's bid for $6.7 B

Blogger: Anne Thomas Manes

BEA rebuffed Oracle's bid on Friday afternoon, claiming that $6.7 B "significantly undervalues" the company. Even though the bid was 25% over BEA's stock value. Of course in response to the expected bidding war, BEA's stock has surged to $18.82, up more than 38% in a single day.

Now it's up to Oracle to come back with a counter offer. Let the negotiations begin.

Although Alfred Chuang has indicated that he wants BEA to stay independent, I seriously doubt that the board and the BEA stockholders will be able to resist the offer.

As for counter offers?

Speculation has been focusing on SAP, HP, and IBM:

BEA doesn't really offer much to SAP. Because of mySAP's use of ABAP, the WebLogic and AquaLogic product families can't displace NetWeaver. BEA has a few nice bits that SAP could exploit: AquaLogic Data Services, AquaLogic Enterprise Security, the SIP server extension to WebLogic Server, and the Workshop tooling. But those bits certainly aren't worth >$7 B to SAP.

HP has repeated stated that it doesn't want to get back into the application runtime business. It's focused on management -- not runtime. I'd be surprised to see HP jump into the bidding war.

I think IBM has the most to gain from BEA -- if only to prevent Oracle from getting it. Oracle + BEA will be a much stronger force in the superplatform market than the two companies on their own, and the combination should be giving IBM night sweats.

Other possible counter offers?
- Microsoft (not likely)
- Dell or Intel (possibly -- if they were considering getting into the platform business)
- Red Hat (not likely)
- Novell (if only they could afford it -- but that combination would be doomed)
- Software AG (maybe, but it would be an awfully big bite -- especially so soon after webMethods)
- Tibco (maybe, but again -- it would be an awfully big bite)
- Sun (well, now there's an idea -- but I would hate to see it happen)

JavaLand's Suburban Sprawl

Blogger: Chris Haddad

Recent lively team debates have focused on J2EE merits and drawbacks. We are amazed by JavaLand’s suburban API sprawl and propose that there is a strong need for simplifying the J2EE platform stack before the platform collapses under its own weight, redundancy, and complexity. 

For example, do we *really* need another data/resource access API? The JSR 225 team thinks so, and has proposed XQuery API for Java (XQJ), http://jcp.org/en/jsr/detail?id=225. We already have Java Data Objects (JSR 12, 243), JDBC (JSR 54, 221), Java Persistence (JSR 220, 317), Data Mining (JSR 73, 247), and JDBC Rowset Implementations (JSR 114).

After reviewing the 120+ page XQJ specification, I wonder why so much effort was spent creating an API that overlaps so heavily with other Java resource access APIs and is not layered on top of generic interfaces. Are specialized XQuery oriented Connection, DataSource, and ResultSet objects really required? Couldn’t we have re-used persistence objects already defined? If not, is this evidence that the original Java specifications should be reviewed from the ground up and heavily re-factored?

The XQJ specification does not exhibit architectural principles of composition and derivation. Some key nits:

• Why does the specification rename XML Schema type definitions as ‘new’ XQJ constants instead of referencing existing constants?
• Why does the specification present ‘Java to XML Schema type mappings’ instead of referencing JAXB specification definitions?
• Why are XQConnection, XQDataSource, XQDataFactory, and XQResultSequence not derived from non XQuery specific base classes or extending generic interfaces?

Other examples of suburban sprawl are evident in Java messaging, serialization, and XML manipulation. Java should not represent ‘tyranny of choice’. I am coming to the conclusion that the Java platform is going to collapse under it’s own weight, redundancy, and complexity.  Java should contain abstract interfaces that can be configured with behaviors and tuned to specific domain concerns. The Microsoft .NET team has taken these architecture principles to heart in LINQ and Windows Communication Foundation.  LINQ encompasses language-integrated query, set, and transform operations spanning objects, relational, XML and other forms of data. IBM is working on Project Zero to *simplify* web application development. The JCP collective needs to re-align their mindset and stop the sprawl by embracing composition.

Hopefully, efforts such as JSR 299 that propose to ‘unify the JSF managed bean component model with the EJB component model’ will move forward within the JCP. The JCP should simplify the numerous, overlapping, sprawling models and APIs presented by the Java platform. Developers should not have to live, work, and play in a confusing, sprawling platform.  JSR 225 is in a public comment period. To improve developer quality of life, we should speak up against JavaLand's suburban sprawl and demand zoning changes.