Web Services Strategies

Beyond the technology, IT strategies for implementation of Web services by Doug Kaye.

Web Services, Trick or Treat? Web-hosting vendor Conxion is sponsoring Web Services, Trick or Treat: Don't Let the Missing Pieces Scare You on Tuesday, October 29, at Zibibbo restaurant in Palo Alto, CA. On the panel: Antonio Salerno, Conxion CEO Steve Holbrook, Program Director, Emerging e-Business Standards, IBM Corporation Dave Wright,.NET Solutions Architect, Microsoft Corporation Doug Kaye, RDS Internet Infrastructure Consulting Brent Sleeper, the Stencil Group Attendance is by invitation only. Contact Phyllis Davidson, Sr. Manager, Marketing Programs and Alliances, Conxion. (408) 566-8529. Posted Saturday, October 19, 2002 10:41:16 PM

Breaking XML to Optimize Performance. Ron Schmelzer of ZapThink makes the case for not employing any of the various schemes for compressing XML. I agree. Posted Saturday, October 19, 2002 10:14:52 PM

Some Security Considerations for Service Grids. (PDF, 23pp.) In this white paper, Martin Milani and John Seely Brown defend certain security aspects of the Service Grid as put forth in an October 2001 HBR article by Brown and John Hagel. I remain a partial skeptic of the service-grid concept. I think it's an important piece of the web-services puzzle (at least so long as standards are immature), but it also has a number of disadvantages as compared to, say, application/XML firewalls. Some points where I take exception or at least question Milani and Brown, if not the original Hagel-Brown article: Re: DoS attacks, I think a service-grid provider may actually be more vulnerable than an individual corporate IP address for two reasons. First, a well-known service-grid provider may be considered a more enticing target by hackers, and therefore attract more such attacks. Second, a DoS attack aimed at one service-grid customer can impact the performance of other customers by denying the availability of shared resources. IOW, if a hacker goes after my web service that's advertised as responding at a WSN that we both use, your web service may also suffer DoS. This wouldn't be the case if we didn't share this resource. Milani & Brown write, "As the service grid is the only connection to the enterprise for specific services, the enterprise has the ability to significantly simplify intrusion detection and filtering, as only certain protocols and packets from the service grid can be allowed." I don't see how this is any better (but I admit, no worse) than a single corporate connection through an XML firewall appliance. Someone still has to manage the "many point-to-point relationships involving a wide variety of security technologies and standards." It's just an outsource/DIY tradeoff. It isn't inherently better or even easier if done by the service grid. Again, "...managing and maintaining the connectivity to partners and service providers is far simpler and cost-effective by connecting to a service grid rather than by directly connecting point-to-point to all these partners and service providers." In practice, the service-grid customer still has the obligation to determine and express to the provider all of the rules required to create and enforce the security policies. There may only be a single physical/virtual connection to the service grid, but there are no fewer application-to-application (or, more precisely business-to-business) relationships. The service-grid vendors don't make business decisions for you. The only step they'll do for you is transcribe the rules into their systems. "Another important point is that mediation services are provided by the service grid." I've contended in the past that such mediation is only required when the associated standards either haven't been agreed to or haven't been universally adopted. True, today, this is the case for much of the web-services protocol stack, but over time it will be less so. Milani & Brown may, in fact agree, if my inference from the following is correct: "It also speeds up the adoption of webservices by organizations, as they do not need to wait for standards and the expensive and cumbersome task of replacing already existing technologies and infrastructures." Posted Saturday, October 19, 2002 9:55:38 PM

Hagel on Loose Coupling. More gems from John's October 9, 2002 weblog post: [Loose coupling reduces...] the risk that changes within one module will create unanticipated changes within other modules. Software has remained tightly coupled because of the inability of major vendors to agree on a universal set of standards to define interfaces across software modules. [That sounds obvious, but the implications are significant.] Business practices have largely evolved around available technology. Since most application software was very tightly coupled or hard-wired, business practices have tended to be tightly coupled or hard-wired. Posted Saturday, October 19, 2002 9:22:44 PM

Making Web Services Work. (PDF) This is an excellent explanation of the issues addressed by the Business Transaction Protocol (BTP). [Source: Mark Potts, Talking Blocks] Posted Saturday, October 19, 2002 9:16:19 PM

Iterative Improvement. In a web-services world it's often less expensive to modify a service than it is to redesign and reprint a paper form. Does this mean we can relax the usual fanatacism for the top-down design of our business processes? Can we actually plan for a more iterative design approach? In terms of version control, adding an output XML element or attribute is almost always backwards compatible, something that's been elusive with older technologies. Just something I've been thinking about. Posted Saturday, October 19, 2002 7:11:40 PM

The Three Steps to Web Service Integration. Some particularly insightful thoughts in this article by Sean Baker, Chief Scientist at IONA from two months ago: By far the biggest danger with EAI integration project is that they simply produce larger islands of data, functionality and complexity. Middleware, by its nature creates proprietary solutions. [Excellent!] Web services, first and foremost, provide a way to break-out of this value destroying cycle. The real value of Web services will lie in the ease of doing business with a relatively small number of trusted suppliers. Its real potential lies in the opportunity to create new, composite applications that leverage the strengths and assets within an organisation, or group of organisations. Posted Saturday, October 19, 2002 10:57:24 AM

The Web Services Scandal. (PDF) Modulant's Jeffrey Pollock writes: Web services technology, despite its potential benefits, is limited in its ability to work with randomly formatted, non-standard data or data not based on XML. most of the web services community is aligning around ebXML for the advanced business process capabilities and standard vocabularies embedded in the specification. [Really? We must be talking to different people.] Standards are a painfully slow way to develop common vocabularies, they're not easy to change, and they're certainly misused and abused. The hype around dynamic discovery is overblown. Vendors aren't focused on the semantic element of the problem. [But is that their role?] [Source: EAI Journal] Posted Saturday, October 19, 2002 9:25:36 AM

October 2002
Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31
Sep   Nov