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
May 14, 2008 | Comments: (0)
How badly do you want a MacBook Air?
At least partially in response to my coverage of TopCoder last week, I have been getting a spate of programming contest and community announcements. ZocDoc is an API for doctor appointments. Appistry Enterprise Application Fabric (EAF) is a grid-based application platform for the development and deployment of scalable applications in Java, Spring, .NET or C++.
Notice what these two have in common:
Tuesday, May 13, 2008
ZocDoc Announces Developer Contest - Win a MacBook Air!
Today, ZocDoc kicked off a contest for software developers to create new applications that help patients book doctor appointments anywhere on the web. ZocDoc users have frequently requested integrations into popular applications and devices such as Facebook and iPhones, among others.
The contest, which runs from now until August 1, 2008, challenges developers to build the application that will most benefit patients looking for a doctor. A new API allows developers to pull data from ZocDoc such as doctor and dentist information, practice locations, pictures, URLs and available appointment times, which can be integrated into custom mashups and applications. The developer of the application that benefits the most users (as measured by appointments made) wins a brand new MacBook Air!
If you are a developer, visit the ZocDoc Developer Center to register for the API.
Join Appistry's Peer2Peer Developer Community and you could win a MacBook Air
Appistry Enterprise Application Fabric (EAF) dramatically simplifies the process of developing, deploying, and managing highly scalable and reliable Java and Spring applications.
Now, with Appistry EAF Community Edition, anyone can experience the benefits of Appistry EAF for FREE. Your Peer2Peer membership allows you to:
- Download Appistry EAF Community Edition at no cost
- Utilize it on up to 5 servers or 10 CPU cores for an unlimited amount of time (no expiration)
- Use it for development, testing, even production deployment of applications
It's easy to get started - join the Peer2Peer Developer Community today to download the free software and access developer resources such as tutorials, on-line documentation and support forums.
You could win a MacBook Air when you join Peer2Peer
Hmm. This is the computer that my high-school classmate Steve Levy (or possibly his wife) accidentally threw out with the newspapers.
Posted by Martin Heller on May 14, 2008 11:11 AM
February 12, 2008 | Comments: (0)
You can't know how much it excites me to hear that Microsoft is designing yet another computer language. Why, what a novel idea! It isn't like there were hundreds of new computer languages designed every year. If that were the case, there would be conferences about the subject. Oh, wait: that's how we first heard about this one, at the Lang .NET conference on the Redmond campus.
But it's a declarative language! Ah, yes: that eliminates maybe half of the languages proposed every year. "Declarative" is an awfully broad term, with multiple meanings. Standard ML is considered declarative, and so are its derivatives OCAML and F#.
Prolog and rule-based AI systems are considered declarative. You declare the rules: the logic engine decides how to run them. SQL queries are declarative: you describe the data you want to see, and the query optimizer figures out how to get it out of the database.
Haskell is considered declarative as well as functional, not to mention that it has monads. Don't ask me to explain monads in the context of functional programming: it's not a short answer. The "Summarizing Proust" contest isn't on today, thank you very much.
Back to declarative languages. XAML is a declarative language for the domain of graphics. It was designed as an extension of XML. It's such an expressive language that Charlie Petzold, arguably one of XAMLs most vocal proponents, built himself a alternative to Microsoft's XAMLPad called XAML Cruncher, so that he could "interactively type XAML code and see the object it creates." In Visual Studio 2008, Microsoft included a bidirectional, split-screen XAML designer, so that you can create XAML by dragging and dropping objects and by typing XAML code, with the ability to freely switch back and forth between the two methods. I freely admit to needing these tools; I can almost never write XAML that will display correctly on the first try.
Watching the Connected Systems Division (CSD) at Microsoft over the years, it has been clear that they have been on a code-reduction path. Why? SOAP was invented by Don Box and others to be an XML-based lingua franca for communication among disparate computer applications and systems. The functional deficiencies of SOAP were addressed by the WS-* series of standards, to give it security, authentication, reliability, and so on.
All of those standards made it harder to write conformant client and server code, raising the complexity by orders of magnitude. CSD engaged in a series of efforts to counter this by raising the level of abstraction for programmers developing connected systems. Web Services Enhancements (WSE) for Microsoft .NET cut the amount of code you needed to write drastically, but not enough for mere mortals.
Windows Communication Foundation (WCF) brought the amount of code down by another order of magnitude or so, partly by using attributes in code and by depending on XML-based configuration files. Attributes are of course one approach to making a language more declarative, and configuration files are another.
Looking at WCF in Visual Studio 2008, it seems like the classes and attributes and design tools are fairly mature, but are still built on top of the general-purpose C# language and the .NET Framework. I wouldn't be at all surprised to hear that the CSD architects decided to try starting over from scratch with a new language that would raise the level of abstraction and reduce the amount of code that needed to be written for a connected application by another order of magnitude. But it's not like nobody else has ever tried that: there's a robust research community working on that kind of problem.
I can guess about the process they're going through, but I can't guess what the outcome will be. It's an emergent experiment, and there are a dozen ways it could go. Nevertheless the criteria are kind of obvious:
High level of abstraction? Check.
Regularity of syntax? Check.
Easy to write? Check.
Easy to read and understand? Check.
Suitable for connection to disparate systems over multiple protocols? Check.
Posted by Martin Heller on February 12, 2008 07:35 AM
July 27, 2007 | Comments: (0)
When I encountered Web service problems earlier this month, one of the first diagnostic tools I reached for was SoapScope. Naturally, it wasn't on the computer where I was developing the client, but that wouldn't have mattered so much; the big problem was that my license had expired. Yes, Murphy struck again, twice.
Writing for InfoWorld brings precious few perks, but one of them is that software vendors are often willing to give me review copies of their products. Mindreef graciously supplied an updated SoapScope license, so I uninstalled the old, expired copy, downloaded the current build, and installed it where it would do me the most good.
There was another catch (yes, Murphy again: that makes three times): SoapScope's collector function needed WinPCap 3.1, but WireShark had installed WinPCap 4.0.1, which has a different interface but works on Windows Vista. I decided that SoapScope would do me more good than Wireshark right then, so I uninstalled WinPCap 4.0.1 and installed WinPCap 3.1. For once, Murphy was wrong: both programs were happy with WinPCap 3.1.
Of course, the next morning when I had all my tools fired up and wanted to do some serious debugging, the Web service was down. Make that Murphy 4, Heller 1. But once the guys on the West Coast got to work, they restarted the service for me.
SoapScope let me manually try out different parameters to the Web service call I was debugging from its own interface, and view the results cleanly. It also captured the Web service traffic my program was generating and nailed down the problem: everything was absolutely fine until the ATL Web service stack tried to parse the response. That knowledge triggered my email to a friend at Microsoft; you know the rest.
You can develop and debug Web services without having SoapScope, but why would you want to?
Posted by Martin Heller on July 27, 2007 07:14 AM
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
July 23, 2007 | Comments: (0)
When I needed a Network Protocol Analyzer last week, I realized that I had recently uninstalled one (I think it was NetSniffer), in a fit of tidiness. It was several years old, and I hadn't used it in over a year, so it seemed reasonable to nuke it at the time. I should have known that deleting it would be the computer equivalent of putting my snow boots away in early spring.
I tried using Fiddler2 to capture Web service traffic, but it couldn't: Fiddler hooks into WinInet, but Microsoft's implementation of Web services in C# and C++ works at a lower level. I thought of the open source Ethereal project, but the latest release was over a year old.
Dave Methvin pointed me at Wireshark, which is the current name for Ethereal: it was renamed in May 2006. Wireshark did indeed show me the Web service traffic I needed to monitor, along with a whole bunch of other network traffic that I didn't care about.
Wireshark depends on the WinPcap driver on Windows. On Linux, where Wireshark comes as a standard package, it hooks into the system drivers. Wireshark isn't the easiest software in the world to learn or use, but it works nicely, and the price is right.
Posted by Martin Heller on July 23, 2007 07:50 AM
July 11, 2007 | Comments: (0)
One of my software development clients is licensing a Windows application to another software company, for bundling with that company's own product, and I was tasked with integrating this unmanaged C++ application (compiled with Visual Studio .NET 2003) with the other company's C# 2.0 application and ASP.NET 2.0 Web site for licensing. It seemed simple enough.
At first, my opposite number at the licensee and I agreed on a licensing scheme in which their software would write an encrypted license code and expiration date in the registry for our software to read. Then we realized that a simple clock setback attack could effectively extend someone's subscription indefinitely. So, we decided to create a Web API for license verification.
There were two obvious choices: a RESTful API, and a Web Service API. We both had experience with both kinds of Web APIs, and neither of us had a strong preference. For me, it seemed like implementing the RESTful client would have been a matter of adapting a function that was already in the program. Implementing the Web service client seemed like a matter of importing some WSDL and letting Visual Studio generate a proxy, then instantiating and calling the proxy.
We decided on the Web service, because it looked a little easier to implement at the server. It took them under an hour to put up a stub service; it took me under an hour to import the WSDL, generate the proxy, and write the call. It took me about a day to write the rest of the code needed to process all the necessary parameters and handle all the possible error conditions.
When it came time to test the code, I found that the Web service call never returned. My counterpart supplied a C# client that demonstrated that the service was working and could be called from my machine, so I massaged my code and tried again. This time the Web service call returned, but with an error. Further debugging showed that the C++ proxy code couldn't parse the reply from the Web service.
As we fade out to a commercial, my counterpart is trying to make the C++ equivalent of his C# test client work on his machine. The last I heard, he was having the same trouble that I had.
I wrote Web service code, it seemed like the thing to do,
Yes I wrote Web service code, it seemed like the thing to do,
But the client hates the server, and it makes its Daddy blue.
Posted by Martin Heller on July 11, 2007 07:59 AM
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
- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
