May 21, 2008 | Comments: (0)
Bungee Connect: Platform-as-a-Service
On Tuesday, I had a long telephone conversation with Lyle Ball, VP of Marketing, and Brad Hintze, Director of Product Marketing of Bungee Labs, who also gave me a Web demo of Bungee Connect. I've been on the Bungee Connect developer beta since March, so it wasn't all new to me, and we were able to skip over the basic "What is it?" questions. Instead, we did a deep dive into the development process and took a broad look at the business model. Today I want to tell you a little about it at a high level.
The elevator pitch for Platform-as-a-Service is: "A single environment delivering the entire software life-cycle as a service. Cloud-based integration creates increased productivity, open collaboration, shortened time-to-market and reduced overall costs." What that means in practice is that you use a Web-based development environment to build, test, and deploy Web-based applications that run either on the Bungee Grid or on a self-hosted virtual appliance. The Bungee Grid has one server farm in the U.S., another in Europe, and uses Amazon EC2 to handle any loads that exceed the Grid capacity.
Everything you need for the entire software lifecycle is built into the Bungee Connect Web IDE: UI, Application Logic, Debugging, Team Development, Deployment, and Maintenance. The IDE itself is a Bungee Connect application. The server programming language is somewhat similar to C#; it is currently stored as XML and interpreted, and can easily connect to XML and RESTful Web services and to PostgreSQL and MySQL databases. The server talks to the UI over the wire using optimized packets that tell the UI what to do. The UI is implemented as JavaScript controls. The whole thing performs surprisingly well on a moderately good PC as long as you have a good broadband Internet connection.
In some ways, Bungee Connect is the antithesis of a Rich Internet Application. Rather than pushing most of the computation to the client, which is the way Flex, Silverlight, Curl, and Ajax work, Bungee Connect uses the client only for the display layer, but uses a beefy Grid of servers and optimized communications.
What about pricing? Using Bungee Connect for development is completely free, but running deployed applications does cost money. There are two pricing models. If you run on Bungee's Grid, the price is $0.06/user-session hour; if you run self-hosted Virtual Appliances, the price is $500/month per image. Compared to buying development tools and servers, this seems like it'll be dirt cheap, unless your application is heavily used and wildly popular.
Bungee Connect is currently in an open beta phase. Major improvements to the implementation are planned for the end of the summer, and Bungee Connect should go into general availability by the end of the year.
Posted by Martin Heller on May 21, 2008 02:10 PM
July 25, 2007 | Comments: (0)
When I wrote about my Web Service Blues on July 11th, I had no idea that I'd still be singing them two weeks later. But I was. The short summary of the issue is that my unmanaged Microsoft Visual C++ Web service client couldn't parse the response from a Microsoft ASP.NET 2.0 Web service.
Every day or two, I'd think of something that could be wrong, come up with a way to test my hypothesis, do the experiment, and see yet another idea go down in flames. Maybe I was formatting the GUIDs incorrectly? We created another Web service call that took strings: ffft.
Maybe the response was malformed? SoapScope didn't think so. And nothing we did to the Web service output changed a thing.
I combed the MSDN news groups. Were people writing C++ clients for Web services? As far as I could tell, yes. I searched the documentation: was there a known problem with C++ WSDL import or parsing? Not that I could tell. I tried porting the project from Visual Studio .NET 2003 to Visual Studio 2005, the same generation of tool used for the service: surely the situation would improve. Nope.
Finally, a query to the Microsoft C++ team, sent through an old friend, got me an answer. It wasn't what I wanted to hear, but it freed us to pursue a RESTful API rather than an XML Web service API.
What you're encountering is very likely by design. We stopped evolving the native Web services stack shortly after we released VS 2002 and now it is a deprecated part of the product (and removed for the 2008 release). Lots of functionality was added to SOAP, WSDL and the entire range of WS* standards after that time (in fact more than 10x the original feature set counting by pages of specs). However we have moved this code to CodePlex at http://www.codeplex.com/AtlServer.
If you have specific problems, the VC++ team has offered to be as helpful as they can, but they encouraged me to encourage you to try working with the sources of ATL Server first.
So there it is: if you want to write a Web service client using Microsoft technology, do it in managed code. Use the .NET Framework. Better yet, use the Windows Communication Foundation.
C++ programmers who insist on trying to make Web services work in native code, write this in your documentation: Here be Dragons.
Posted by Martin Heller on July 25, 2007 12:35 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
