ActiveGrid CEO Sees LAMP, XML as �Next-Gen� Apps Platform [OETrends.Com]
: "ActiveGrid CEO Sees LAMP, XML as �Next-Gen� Apps Platform
Posted on: 07/08/05
by Vance McCarthy
ActiveGrid Inc.�s campaign for helping Open Source LAMP-based tools and platforms to play a growing role in enterprise app development is getting a boost from some of the biggest names in LAMP, including Red Hat and Novell (Linux), Covalent (Apache), MySQL AB (MySQL), and Zend (PHP scripting language). "
ActiveGrid has reached strategic partnerships with each firm to map out plans for technical co-development, marketing, support and other streategies important to further seeding Open Source solutions into the enterprise IT – particularly the appdev and deployment sectors.
ActiveGrid founder and CEO Peter Yared described the goal of these LAMP partnerships this way:
"By partnering with the key LAMP players, ActiveGrid is able to integrate the LAMP stack into a cohesive platform for enterprise customers. The strategic relationships we are announcing today will enable ActiveGrid to collaborate on LAMP-based technology innovation and streamline mission-critical customer support by resolving technical issues directly with the principals behind each component of the LAMP stack."
ActiveGrid’s offerings, slated to be released late this year, is comprised of a visual toolset (Application Builder) and LAMP-based Open Source deployment platform designed to expand using commodity hardware (Grid Application Server). The two components 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 native XML enterprise applications – using grids of commodity computers. Pre-release versions of the company's Open Source offerings are available for download from ActiveGrid’s website.
Why ActiveGrid’s Yared Says
It’s Time for the Next Shift
"ActiveGrid’s vision is based on a shift away from conventional languages like Java and C, to Open Source, native XML, and grid computing. The reason, Yared says, is that enterprise managers, architects and even devs, are beginning to see that the current way of building and updating apps is just too costly and time-consuming.
Yared points to ActiveGrid’s Application Builder as the model for how to cure what ails today’s traditional apps development woes. The ActiveGrid Applications Builder marries procedural and declarative coding help devs apply caching and asynchronous communications to applications as properties – not hard-coded attributes.
The tool provides an Open Source visual development environment, which marries XML and Python technologies to enable devs to graphically and iteratively create, test, debug and even deploy apps from the same environment. The tool also provides wizards and other graphical abstractions to build apps and/or services that need to interact with other resources, and integrates a Web server, database, and debugger to let devs run demo apps, test, and perform iterative development against their early codesets.
A key, Yared said, to ActiveGrid’s Application Builder dual capability is the tool is based on Python (the wxPython GUI framework) for Python. Another key: Application Builder’s ability to make deployment patterns not just declarative but also adaptive. As a result, a session-replication feature, for example, can be activated selectively based on traffic or customer priorities.
Through the Python GUI, devs can build applications and/or services that will comply automatically with a variety of web services and XML data flow standards. Among the key technologies supported are: BPEL (Business Process Execution Language) to define application flow, XML Schema to represent data sources, XPath to specify queries, and XForms to define dynamic Web pages. All logic is automatically encapsulated as Web Services, which can be written in Python, PHP, Perl, or Java.
To get a more in-depth look at how LAMP and XML develop/deploy environments could improve the lot of many legacy developers, including Java/J2EE, Open Enterprise Trends spoke in-depth with Yared, who served as CTO for Sun’s application server unit prior to founding ActiveGrid.
Open Enterprise Trend Interview
with Peter Yared, CEO/Founder
OET: What does ActiveGrid’s approach grid do to push adoption of Open Source, or the LAMP stack in the enterprise?
Yared: In Open Source and with LAMP, we’re not just talking about mission-critical Linux. 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
OET: 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 backends, including commercial and Open Source software, and make a new application that ties these together
OET: 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.
OET: 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.
OET: And 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.
OET: 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.
OET: 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 standard to 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.
OET: So, ActiveGrid’s platform approach is to make light-weight servers using Open Source/LAMP not just mission-critical, but deploy-ready?
Yared: That’s a key point, There is a shift underway that we call “traditional development cycle” versus a “services-driven” development cycle. 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. With ActiveGrid’s approach, developers can be 10X faster than J2EE, and that means changes and updates they need to do to their code can be done in much less than the year or 2 it can take today. And, we can make updates 10x less expensive than J2EE because integration and deployment costs are greatly reduced.
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.
OET: Is your approach that we should treat the app server like the way the Java treated the mainframe?
Yared: 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.
OET: 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.
OET: 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
OET: 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. .
OET: 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.
OET: You mentioned E-Trade earlier. Is that the new pattern for quick development/quick deployment? And, if so, what is it they’re doing that is getting the attention of the architects and business execs you’re talking to?
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.
OET: 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.
OET: So, what you’re saying is that Hibernate the new target devs are building to – and not building native component apps, which could be more intuitive?
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.
OET: So, how to devs escape from this growing complexity to 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.
OET: 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.
OET: 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.
OET: 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. lets 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.
OET: What about 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.
OET: 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.
OET: 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.
OET: 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].
OET: 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 your 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.
OET: 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.
OET: 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.
OET: 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.