Former Sun CTO Sees Flaws in EJB 3, Hibernate
Peter Yared, former CTO for Sun's J2EE app server unit says the newest J2EE technologies - EJB 3.0 and Hibernate - don't go far enough to solve the pain of today's devs and architects. See why, as a result, Yared says J2EE may lose out to Open Source LAMP approaches for building more efficient, scalable apps. Yared, after leaving Sun, founded ActiveGrid Inc., which will unveil an Open Source-based "develop-to-deploy" framework later this year.
Peter Yared, former CTO for Sun J2EE app server unit says Java/J2EE may lose out to Open Source technologies in the future. EJB 3.0 and Hibernate just don't go far enough to solve the pain of today's devs and architects, Yared told IDN.
"There is a shift underway that we call 'traditional development cycle' versus a 'services-driven' development cycle," Yared told IDN. "In traditional appdev, applications get written by Java and mostly by hand, and devs have to pick out the exact server architecture they want and whether it will include stateless session beans, Hibernate or whatever. Then, they hand-code to that [architecture] directly," he said. [Read the full interview]
ActiveGrid's vision is based on a shift away from conventional languages like Java and C, to Open Source, native XML, and grid computing. ActiveGrid's use of Open Source offerings, including Python, is designed to enable devs can build apps and/or services that will automatically comply a range of web services and XML data flow standards. Among them:
ActiveGrid has a two-part offering slated for release later this year, and includes (a) a visual toolset (Application Builder) and (b) a Linux-based deployment platform (Grid Application Server). The two are designed to work together, and aim to make it easier for commercial developers (Java, C, C++, ASP/.NET) to easily create, scale, and deploy enterprise apps that will work with and extend existing Java, .NET and legacy apps.
ActiveGrid's dev approach uses wizards and other UI abstractions to help devs build apps and/or services. The deployment platform includes a Web server, database, and debugger to let devs run demo apps, test, and perform iterative development against their early codesets. And, because ActiveGrid marries "procedural" and "declarative" coding technologies with an easy-to-use interface, Yared says it will help Java devs quickly ramp up their skills for building composite apps.
Pre-release versions of theses Open Source offerings are available for download from ActiveGrid's website.
Even before the commercial launch, ActiveGrid Inc. is already attracting the attention of the biggest name in enterprise Open Source, forging partnerships with Red Hat and Novell (Linux), Covalent (Apache), MySQL AB (MySQL), and Zend (PHP scripting language).
Integration Developer News spoke with ActiveGrid Peter Yared to find out more about why his approach will attract Java/J2EE devs.
Integration Developer News Interview
with Peter Yared,
Former CTO, Sun Microsystems' App Server Unit
CEO/Founder, ActiveGrid Inc.
IDN: How does your vision fly with end users?
Yared: What's interesting when you talk to the business people or upper management, they want to lightweight servers on commodity machines. They are seeing some pretty heavy-duty mission-critical apps using this approach, from companies like Google and E-Trade, and they want those kind of benefits from commodity hardware and software too.
IDN: Can you give an example of where you see this new non-Java pattern for quick development/quick deployment emerging?
Yared: E-Trade just switched their infrastructure to use 160 commodity [Linux] machines running Tomcat, and they didn't even buy maintenance. So, today, I think the challenge is that a lot of folks are trying to build mission-critical applications for these low-cost, light-weight [Linux] servers using the same methods and approaches they used to build applications for their heavy-weight servers, and so it's not just the deployment [environment] that's a cost issue. It's also in the application development. Unless the dev changes their approach to application development for light-weight [Linux] servers, they will still face 2-year development cycles and lost of expense.
IDN: That sounds simple enough. But it is always easy to figure out how granular the components of a lightweight app should be?
Yared: It is self-evident. That's because you start to think of services the way you used to think of database calls. In a database, you would never call a database with 'get me the first name,' then 'get the last name' and then 'get the address line 1'. Instead, you would say, 'get me the data on this person.'
So, for developers, services are really not that unfamiliar because they are not that different from what they've used in the past. The real problem is that developers are coding to Hibernate. And, it's Hibernate that says 'get first name' and then 'get last name' etc.
IDN: It sounds like ActiveGrid is using Open Source/LAMP to form a new apps platform to make it easier to update and even integrate legacy apps (Java, C, or even VB/ASP apps). Is that right?
Yared: What we're doing is building a next gen application server, releasing the server and the [application] builder. Then, we're tying together three (3) emerging trends in the enterprise: (1) an applications grid on commodity machines, (2) Open Source LAMP ,and (3) XML to make it easier for devs to build apps. For us, the key differentiator is that the development and deployment are decoupled. So, I can take a variety of enterprise back ends, including commercial and Open Source software, and make a new application that ties these together
IDN: Give that vision, how does your approach change the way developers and architects work today?
Yared: The first thing to recognize is there is a shift away from running heavyweight application servers on larger machines, especially for "Greenfield" projects. The Java community is starting to grasp this. No one at the design point says they want to run on 4 8-way [CPU] servers anymore. It's expensive, hard to build applications for, and hard to deploy. And, in the end you end up with really complicated software [because] EJBs are hard to do correctly.
IDN: So, are you saying there are a lot of CIOs and even developers out there getting J2EE fatigue?
Yared: We shift computing architectures every 5-10 years, from mainframes, to minis to client/server and to the Internet. Now, we are in the beginning of a new shift to a grid architecture. With each shift transaction volumes have increased. People are already doing all their numeric computations on the grid, and provisioning apps on the grid. The next step, which is coming now, is to do 'transactions grids' which can run mainstream applications on large clusters of machines. This is where ActiveGrid's opportunity lies, in the move to what we call the 'transaction grid' and bringing Open Source platforms to mainstream app development and deployment.
IDN: Hmm, so you don't need Java's platform independence?
Yared: That's the irony. You know you're running on Linux 'x86, you don't need platform portability at the language level anymore. We all spent a long time in Java to make sure developers were no longer locked into an operating system or chipset. That was what made Java successful. When it took off in 96-97-98 when it moved from the browser to the server, you weren't locked in to Solaris or HP-UX or AIX or whatever. Linux does the same thing. So, if you know what operating system you are running on, in this case Linux, do you need layer in between? We think the answer is no. So, developers should be very comfortable running C++ again.
IDN: But today, aren't there plenty of Java standards, and even Java standards for web services to help developers?
Yared: That's the problem, in fact. There are too many. Today, there are Java web service standards for many different things, but there are still many different [standards]. . When you want to go to a database, you use JDBC, going to a transaction monitor, you use JTA, go to a legacy system, you use JCA. And, the web service things are even worse. We see the integration developer using XML. And, that's it - only XML. It's XML in and XML out. All data sources should look like a web service and represented as an XML schema. In ActiveGrid, all that done in declarative XML. All schema and the data sources are accessed in the exact same way.
IDN: Is your approach that we should treat the app server like the way the Java treated the mainframe?
A lot of tools and services companies that advising to get the nirvana of SOA you have to re-architect plan where you re-service your tightly coupled assets. That's unrealistic. You never Java-ized the mainframe; you just figured out how to get [requests for data and rules] there and back.
We know customers have J2EE applications they haven't touched at 2 years. When they need to update their apps, they will build new ones with all those old ones, and use adaptive transactions. ActiveGrid makes it so you don't have to call the backend all the time. You have your existing J2EE server and you open a web services 'pipe' into it. It will get millions of requests, so that won't scale. To address that issue, we let you set policy - such as 'responses from this EJB are good for 15 hours,' and so on.
IDN: You mentioned Hibernate earlier. What about Hibernate? That's geared toward taking complexity out of Java development. Are you saying that Hibernate should not be a target for Java developers? And, they should spend time learning more about composite app development?
.Yared: That's exactly it! Hibernate is an extension of the past, and Hibernate belongs to that yesterday column. Hibernate is a better way to do object/relational mapping, but it's really juts band-aids. It's dealing with development in the old way. Java developers have a huge list APIs, and now they are going to all more. It'll make the 'EJB stack' look more like the yellow pages more than the whitepaper.
IDN: How do devs escape from this growing complexity of J2EE and get on the road to composite apps?
.Yared: At the end of the day, there is not a single high-level tool for J2EE that is useable or clean. They are all either code generators or generate proprietary metadata, There is nothing that's clean. So, there is no high level development tool. That means you have people hand coding to these [Java] APIs, and that limits the number of people that can build these kind of new [composite] apps.
IDN: So, is that where ActiveGrid comes in? To offer devs a lighter-weight alternative to conventional, and complex J2EE app development?
Yared: In the future, the way to build is lightweight servers that scale horizontally. Many in the Java community, for instance, have switched away from using J2EE and are now using Spring or lately Hibernate.
With our approach, developers develop through XML schema and deploy separately and we see this as a pretty cool way to build quickly and deploy easily. So, our approach lets developers or architects take a variety of enterprise backend systems , including SAP, all sorts of J2EE EJBs from BEA or IBM and make a new app that ties all these together. You can run it locally, or deploy to an ISP or a datacenter. We will make it such so that decision can be left to IT, but all the capabilities to support that decision are pre-packaged.
IDN: How does ActiveGrid's approach make Open Source an attractive option or alternative for Java devs?
Yared: We're saying there needs to be a complete develop-to-deployment framework for applications. Our idea of 'grid" is all about developer agility. Once a developer builds an application using declarative XML schema [approaches and tools], all the code can be encapsulated as a web service. From that, the developer gets two benefits:
1. One, developers can deploy their application seamlessly across an extensible infrastructure -- from one to 100 machines. That's because the developer is not hard-coding to a platform or cluster, so the infrastructure can adapt; and 2. Developers can change the application easily
IDN: There are a lot of vendors trying to define grid, IBM for hardware and Oracle for database software. How does ActiveGrid think of the "grid"?
Yared: Grids are an infrastructure for applications - business process and applications change management. It's not just hardware clusters or grid, like IBM will sell you a bunch of Linux machines. With an applications infrastructure grid, Amazon, for instance, can put up a new store in a month and it takes everyone else 2 years.
IDN: Would you compare your abstraction approach to BEA Weblogic Workshop, which also uses a code generator, in conjunction with workflow abstractions?.
Yared: BEA's approach put all that as metadata within Java files, rather than storing a BPEL file. With ActiveGrid, we give developers a graphical development environment, and the difference is now they are editing [standard-compliant code] they used to build by hand. This means whenever developers want to add code, they can.
IDN: So, BEA's approach was too proprietary?
Yared: It was exactly that. BEA's whole value prop was 'Use our server because it's standard,' and then sell their tool, which was not standard. So, they started off on the wrong foot. But among Java developers, I can tell you a lot of Java developers it takes
IDN: How easy have you made it for developers not used to thinking in that way to invoke such situational features?
Yared: We've tried to make our ActriveGrid developers tool familiar to developers, so they can be up and running in 15 minutes. So, it looks like a PowerBuilder approach so our tool has a built-in web service, database, demos and a variety of patterns so they can begin projects using iterative development. There is a reason why people stopped using 4GLs, it was very proprietary, difficult to learn and somehow all that promised reuse never showed up.
Our tool is service-oriented from the ground-up, so when you are editing a web page flow, for example, you are automatically making a BPEL file. When you are bringing in any datasource, including SQL databases, it is internally represented as an XML schema (.xsd file), UIs are in XForm and queries are in XPath. .
IDN: What type of developers are you targeting?
Yared: We're targeting the 80% in the midriff in the corporate developer team. It's the people who used to do COBOL, went to PowerBuilder and now may be using Java. Among the developers we've talked to who are working deep inside the infrastructure to build and deploy apps, they are very happy about the idea of running on a much smaller machine.
IDN: So, it's the design and tooling that is just as important as the underlying 'grid' infrastructure?
Yared: Exactly so. That is why we also did a developer toolset. We like to say that with a grid, developers can build apps rapidly, like with PowerBuilder, deploy scalability like Google, and serve with dozens of differentiations, like Starbucks does with coffee.
IDN: Talk a little more about that Starbucks part of your vision?
Yared: OK. Adapt applications across a grid can be customized to meet a business need based on who an application is interacting with. .
So, for example. let's say I have web order entry system. And, guess what? Just when an important customer is online, that's when one of your servers hangs and loses the order. The customer calls your CEO and says 'You just lost my order." So, you as IT in trying to fix it might suggest turning on session replication, which exacts 3 times the performance hit, or suggest that the server infrastructure be scaled up. The CEO says to you: 'Why can't you just turn on session replication for Jim?' or for any high-value customer. The key is that with adaptive applications, you can do different things for different people, all based on policies that can be run at runtime.
IDN: How architects are reacting to your approach?
Yared: This is the first time that no matter what level in the org we talk to -- the CIO, the Chief Architect, the mid-level architect or even the developers who do the coding - we can offer the same exact message about simplifying development and deployment. And all these groups have given it the thumbs up.
IDN: Really. No resistance?
Yared: (Laughs)> Well, they don't all like it for the same reason. But, but they all give it the thumbs up. Everyone wants to move to large clusters of commodity machine. They all get it, and understand the value. Commodity machines running Open Source hardware are cheaper, and they also would like to do more Open Source development if they knew the rules and knew their commodity hardware can support their applications needs. And, we're showing with our grid approach that LAMP can meet more of those needs than they originally think.
IDN: And how do these developers, architects and CIOs see ActiveGrid contributing to moving from tightly-coupled to loosely-coupled ways of building - and deployingâ€”apps?
Yared: To put it succinctly, it's very hard to deal with loosely structured data when you have a strongly typed language. Also, every Java thing that works with a web service generates a bunch a classes. And, the minute the web service changes, even a little bit, developers have to go generate a whole new bunch of classes and re-deploy their application. The whole point of web services is that they change a lot, and people we talk to understand the need to have tools and a platform that can accommodate those changes in a cheaper and quicker manner.
IDN: So what are some of the "transitional" technologies that ActiveGrid offers to get enterprise devs from Point A to Point B, or from tightly-coupled to loosely-coupled development?
Yared: We support Java. We call our environment 'service-oriented, language neutral'. It's actually the same message that Microsoft has [with the CLR].
IDN: Speaking of .NET, what does ActiveGrid have in common with Microsoft?
Yared: What Microsoft says is if you're doing control flow, do it in Basic. If you're doing heavy computation do it in C and if you're doing business logic do it in J++ or their Java derivative. It's very rational, actually. And, that's a lot like what we say. We say when you're doing text processing or flow control do it in PHP. When you're doing heavy computational stuff use C++.
With CLR, Microsoft lets developers call from one language to another. But, in a service-oriented world I don't care what Salesforce.com is written in because I know I can communicate with them because they use web services technologies, like WSDLs and so on. Similarly, I don't care what the Google or the Amazon APIs are written in because I know I will be able to communicate with them.
IDN: How do your tools work, for identifying assets, as well as any new programming?
Yared: For the most part, wizards walk you through it, using the IP address, MySQL configurations, etc. And, developers build an app through flows and such. The minute you need to do code, every bit of code you do will be a service. This is straight-forward, so now you are dealing with services and tying them together. Examples might be: How do I get from this web page to another web page; or Now that I am getting data from SAP [ERP software applications] what do I need to put out.
IDN: Does ActiveGrid support security?
Yared: We define a service as XML in and XML out, so when you are talking to customer that wants to do an end-to-end cert check over SSL, we are doing that based on policy at runtime. We also have plug-ins to an identity server, and let you set a policy for an individual service.
IDN: How does ActiveGrid help avoid performance bottlenecks?
Yared: We do is data-caching. An example is Sabre the online travel system. Initially they only serviced travel agents. Then they bought Travelocity, and set up a transaction grid of 15 machines that would pull down their fair matrix every hour. ActiveGrid is setting up data caching patterns like that and productizing them for other users to use.