« December 14, 2002 | Main | December 17, 2002 »
December 16, 2002
Web Services: Incrementally Exposing Your APIs
The December issue of the Web Services Journal has an article by Henry Bowers on "Building Business Rules in Web Services Applications." What caught my attention was the ability to do something like this incrementally in the same way I advocate doing incremental transitions to web services for data in my paper on Enabling Web Services. At one point, Henry says:
[Another] approach is to separate business rules from the business logic. Depending on the construction of the applications, this can be fairly easy. For example, the 400 pages of if/else statements mentioned earlier are located in a handful of functions. These routines can easily be wrapped up as a Web service. This service is sent the same parameters with which the original functions were called and returns the same values after executing the rules. ...
The first advantage is that other applications can now make use of the same rules. Suppose, for example, that a mortgage insurance company wants to establish what proportion of its loan portfolio is at risk. It might obtain updated information on its customers and run the data through the qualification engine to see who would be rejected or assigned a lower credit score. To do this analysis, the company needs to access the business rules without dealing with the other processing of a loan application. It is not interested in receiving text streams for loan documents; it wants only the results generated by pushing data through the qualification rules.
Web services provide a unique opportunity to implement this kind of reusability by carving out sets of rules into callable services. In addition, they encourage the conversion of many standalone data formats into XML, which has the benefit of simplifying overall application integration (at the cost of performance, which in high-volume settings is far from negligible).
Sites that choose this path are often surprised at how quickly benefits become apparent. The separation of rules processing as Web services can be implemented progressively. Complete conversions of applications are unnecessary. Also, once rules are segregated as Web services, new opportunities for their use appear quickly. For example, business analysts can much more easily perform what-if scenarios by rolling hypothetical data through the rules.
This is exactly the right approach. As you can, incrementally expose web APIs (internally or externally, as appropriate). The marginal cost isn't that great and the more APIs you expose the greater the potential interoperability. Small, scripted aggregations lead to serendipidous applications: Jon Udell's LibraryLocator bookmarklet is a perfect example of the kind of interesting things that can happen with just a few scripts when APIs are exposed, documented, and reachable.
02:19 PM | Recommend This | Print This
IM TCO
Jeremy reacted to my post on the enterprise wide IM:
I'm wondering what the costs really are. Given that the software (Jabber) is free on both the client and server, what's left? Deployment? That's a one-time cost that's no higher than deploying any other software. Training? IM software isn't terribly complex (compared to Word or Excel). Many already use IM at home thanks to AOL, Microsoft, or Yahoo. The less technically inclined can always ask their kids for help. :-)
What Jeremy says is mostly true. This really comes down to total cost of ownership. The one gotcha is that software cost is almost always a small part of the overall cost of doing anything across an organization with 22,000 employees. its also usually the easiest part to figure out. Jeremy's statement presupposes a few things:
- Sufficient priority to get the engineering time necessary to create a solution. Jabber is a great tool. I've played with it some and got some people using it to see what it could do. Still, rolling it out in a reliable way for 22,000 people involves some planning, capital expenditure, etc. There are lots of fires being fought and that keeps us from working on new, interesting things. One of the things that people frequently don't factor in when they look at organizational dysfunction is the opportunity cost. Its huge.
- A desktop support structure that isn't extremely fragmented. A fragmented organization makes rolling something like this out difficult because you've got to convince 30 separate kingdoms to do it and then you've got to make sure it happens right, that the training is occurring, etc. Utah just isn't organized in a way that makes something like this a simple task.
The fact that it will be integrated into an existing product means that it will just happen and be prioritized along with email upgrades. Sometimes, this kind of upgrade is the only hope for moving in a new and interesting direction.
As an aside, I noticed on some of the comments on Jeremy's site that people were asking why not just use AIM? A number of us do use AIM everyday to get work done, but the consumer version has a few holes that need to be filled in an enterprise IM solution:
- An enterprise IM solution should tie into the corporate directory so that its easy to find people and create workgroups automatically (for presence, if nothing else).
- An enterprise IM solution should be secure. I want encryption from me to the recipient (not just the server) and I want positive feedback that its there.
- An enterprise IM solution should be as ubiquitous as you can make it across the enterprise so that its a tool people can count on for collaboration.