WebServices dot org

Q: You offer an open marketplace for publishers and subscribers to Web services to meet and transact. Where are you getting the most traction at this point?

Brauer: We’re seeing a lot of interest from ISVs in building Web services into their applications. If we try to market an individual Web service, it’s difficult. But if we market a solution to a pain somebody’s feeling, they get it. That’s why the ISV wrapper around Web services is working so well. People don’t need a Web service. They need tax data, address updates, or fraud prevention.

A metaphor is the database. In the early days of the database, the only people that could take advantage of it were those who could write SQL. But who can really do that? It wasn’t until we got reporting tools and CRM applications that databases started to make sense to the larger masses of people. I see a very similar model here. When Web services first emerged, you had a sophisticated set of developers that could actually utilize this stuff and put it to work. Now, Web services are becoming part of applications, and that’s driving the usage. The advantage of a Web service is that it’s better to just reuse something in the form of a Web service than have to recreate functionality from scratch.

Q: Is your message now extending beyond developers, then?

Brauer: A large part of the value of StrikeIron is the network effect. We realize the easier we make access to Web services, the more success our publishers are going to have. It’s one thing to just provide a Web service to a developer so they can build it into their Web site or application. But the value is with the business user. The business user might have a need for tax rate, or to cleanse data.

Q: You recently signed an interesting agreement with CRMfusion, which serves the Salesforce.com space. Can you talk about what StrikeIron provides?

Brauer: CRMfusion built add-on tools for the Salesforce.com environment. If you are a Salesforce.com administrator, you have a lot of data in your system. You buy CRM Fusion’s tools to eliminate duplicate records, do some reformatting of the data, identify records with missing records, and so forth. CRM fusion recognized that we have several services that provide related functionality. For example, they saw our address-verification Web service, and wanted to integrate that, because the data that feeds these services is updated on a monthly basis from the United States Postal Service or Canada Post. Rather than build and maintain all of that, they integrated our service it into their product, and delivered it to all their Salesforce.com customers. This is key, because traditionally, in a CRM system, as you’re trying to cleanse your data, you have to export it out for cleansing and import it back in. This can be very error-prone, since you have to account for the delta that’s occurring while the data is out of the system. And it’s always been a very hard thing to have it done in real time without data ever having to leave the system. So they took our service, put it inside their product, and now a Salesforce.com user can just click a button and say ‘yes, I want to cleanse my addresses.’ Or, they can set up a filter to cleanse portions of their data.

Q: Can end-users see that they’re accessing a StrikeIron-based service? Or does StrikeIron work under the covers of such applications?

Brauer: It’s not a requirement that it is known that a service comes from StrikeIron, but every ISV so far has chosen to identify StrikeIron-powered Web services, primarily to leverage our transaction-based billing capabilities

Q: Recently, IBM, Microsoft, and SAP ended their UDDI service. Where did the concept of public Web services directories go wrong?

Brauer: UDDI has never really taken off. Nobody has ever really managed that content. A lot of people were using it as a test place. Somebody would put up a service, and two weeks later it would come down, but no one would bother to ever remove it from the UDDI directory. The services you would find there no longer worked. You would have to try four of them that don’t work before you can give up on using the thing. It was kind of a difficult thing conceptually to understand, and there were no real tools on top of it to make it useful. Imagine the Web with no real search engine behind it; a place to actually find stuff.

Q: There needs to be some type of quality assurance oversight to such a directory, then.

Brauer: Until you’ve got somebody that’s actively managing content in a directory, making sure that the services there are of value on an ongoing basis, and monitoring those services, you would have a situation similar to UDDI. It needs to have a commercial component, in the same way that the successful search engines are commercial.

Q: Why would an ISV or end user want to link into services via an intermediary such as StrikeIron, versus simply identifying and accessing Web services on their own?

Brauer: If an ISV had 10 different sets of functionality that they wanted from 10 different Web services providers, they would have 10 different sets of services responses and 10 different ways that they would have to do billing reports, that would have to be passed on to customers. We offer a very consistent interface for the ISV, at basically no cost. They can just start making the services available, and get paid on the usage. We handle all the billing, collection, and account information.

Q: Does StrikeIron or its partners use UDDI for internal registries?

Brauer: Yes, people are using it internally, and we can make our services available through a UDDI interface. We also have a Web service that has additional functionality above and beyond what UDDI provides, such as setting up trial accounts and those kinds of things. That’s in the new API we’re announcing.

Q: Tell us about your new API.

Brauer: It’s a mechanism that we make available to our ISVs to make the integration of services from our marketplace more seamless. All of the things you can do in the marketplace – get free trials, register, purchase services – can now be done through this API. We have different operations, in which users can do all of these things without ever having to leave the ISV’s application.

Q: How many services are now offered through the StrikeIron Web Services Marketplace?

Brauer: As of this time, we’re nearing 70, and we have several in the pipeline. In each case, we make sure each service in the marketplace is reviewed and is of value before we actually publish it.

Q: What are the most popular services offered through StrikeIron’s marketplace?

Brauer: It varies. Our SMS Web service is very popular because people can programmatically, as part of an application, send an SMS message to 460 different carriers across the globe. All you need is a number and the text of the message to send, and invoke the service. Also, we’re seeing demand for any type of demographic data that enriches customer data, as well as the emergence of on-demand CRM.

Q: What is the transaction volume going through your marketplace?

Brauer: It varies. In general, it’s in the hundreds of thousands. We’ve been upgrading our data center just about every six months. We’re adding more and more horsepower, and have the capacity to handle millions of transactions. That number fluctuates, because people are doing very large batch jobs. We’ll see times where there’s hundreds of thousands of transactions, and sometimes, maybe half that, where Web services are actually being invoked. But that has doubled in the last four months alone.

Q: Are all services hosted directly by StrikeIron? Do any of your publishers run their own services?

Brauer: There are cases in which data or functionality is coming from a third party. Our Dun & Bradstreet Web service is an example – we haven’t loaded up all the D&B data onto our data center. They have a proprietary API that they make available to us, so when we get a request, we interact with that API to get the data that we’re looking for. Then serve it back to the subscriber of our Web service. We put the Web service in front of it, wrap it into our infrastructure so somebody can gauge the usage, and provide this information in a consistent way with all the other Web services in the marketplace.

Q: What technology do you run in your data centers?

Brauer: We have Dell servers running in parallel, and everything is run on top of .NET. We’ve done some work with the [Microsoft WCF] Indigo folks with some of their new stuff, and they’ve been interested in what we’re doing. We’re hoping to push their theoretical limits.

Q: Since you’re a .NET shop, are there any issues with supporting Java Platform-based Web services?

Brauer: Our communication between various applications is all done via XML, so the platform they happen to be running on isn’t of any consequence. That being said, in cases where we’re hosting underlying applications, we do have an environment for Java applications to live.

Q: There has been criticism of XML as too verbose a language for some systems. Has this been an issue for you or your partners?

Brauer: Not really. One of the things that we’ve learned through time is that the more simple a given Web service can be, the greater use it’s likelier to get. So if you create a very convoluted Web service that’s got 27 different input parameters and 74 different output parameters, which might create a very large XML message, then it’s less likely to be used and understood by the mass of people that might want to use it. You could store binary images with an XML, for example, so it could conceivably become very large, but that hasn’t been an issue for us.

For more details about StrikeIron’s Marketplace API announcement, click here .