EPimentl: WebServices

IBM Business Transformation

Mon, 11 Apr 2005 03:16:40 GMT

Business Week writes about IBM's focus on business transformation services: "BM, with its legions of PhDs and closets full of patents, is not built to duke it out with the likes of Dell. Palmisano's strategy promises a neat escape. Instead of battling in cutthroat markets, he takes advantage of all the low-cost technology by packaging it, augmenting it with sophisticated hardware and software, and selling it to customers in a slew of what he calls business transformation services. That way IBM rides atop the commodity wave -- and avoids drowning in it."

[E M E R G I C . o r g]

Is the SUN setting on CLECs ? How will they survive in a UNEP-LESS Post ERA?

Thu, 24 Mar 2005 00:43:49 GMT

In the good old days 199x - 2004 a typical CLEC with a 50 central office (CO) HDSL build-out, the CLEC is able to break even with just 20 business customers, show net EBITDA
(earnings before interest, taxes, depreciation and amortization) of 20-plus percent over three years and become cash-positive in less than two years.
With the recent UNEP ruling how will these xLECs navigate the vehement tumultous telecom sea and steer their company/ship away from the regulatory rocks so as not to shipwreck?

One solution is VNAP http://vnap.ws and http://dv4.agileco.net/BizLocity Now Virtual Operators, xLECs, xSPs, Mobile, Wireless and Cable MSOs, and others can leverage this Virtual Network Infrastructure to redefine how services and products will be created and offer and break the tyranny of the DS0 and and the shackles of the unwilling partner.

I will have more to say about this at a later time.

Ten To Watch in Mobile Content

Tue, 08 Mar 2005 01:58:47 GMT

Ten To Watch in Mobile Content.

This is not a definitive list, just a list of smart young blood in the mobile content sector. Notice that except for one, none of them are CEOs (yet), but youâ€™ll hear a lot from and about them in the next few years (that was the criteria). Just a way of recognizing the people in the second wave of mobile content (in no particular order):
Â»Â Greg Clayman, Vice President, Wireless Strategy and Operations, MTV Networks
Â»Â Rio Caraeff, mobile head at Universal Music
Â»Â Thomas Ryan, Senior VP, Mobile Development, EMI Music
Â»Â Mark Levy, VP content at InfoSpace Mobile
Â»Â Lucy Hood, VP, Content, News Corp
Â»Â Shawn Conahan (end of page), CEO, Intercasting Corp
Â»Â Adam Flick, Chief Marketing Officer, Airborne Entertainment
Â»Â Robert Tercek, Chief Strategy Office, mForma
Â»Â Manish Jha, Senior VP, ESPN Mobile
Â»Â Russell Beattie, Yahoo Mobile

I realize this is a US-centric list, and if you want to add to my list of the people influencing our fast growing sector, post them in the comments belowâ€¦

[unmediated]

SODA

Sun, 06 Mar 2005 16:32:57 GMT

SODA. A month or so ago, I was reading a Gartner handout for a conference, and came across an acronym they invented- SODA[1]. SODA (Service-Oriented Development of Applications), as Gartner defines it, consists of the following areas:... []

Yahoo Web Service API

Sun, 06 Mar 2005 16:31:44 GMT

Yahoo Web Service API. Yahoo joins the growing number of web sites exposing their API as Web Services. Their API is available from Yahoo Developer Network.... []

Yahoo! Web Services

Tue, 01 Mar 2005 13:10:38 GMT

Yahoo! Web Services. Paul Bausch takes a look at the new Yahoo! Web Services interface and shows how to tap into the API with a sample application. [O'Reilly Network ONJava.com]

Yahoo opens up search platform to external developers.

Tue, 01 Mar 2005 13:02:09 GMT

Yahoo opens up search platform to external developers. Yahoo is for the first time opening up its search platform so that external developers can create search applications that tap the vendor's search infrastructure, Yahoo is announcing Tuesday. Yahoo is also expanding access to the Overture ad network to more developers. [InfoWorld: Top News]

Tue, 01 Mar 2005 01:27:38 GMT

Developing Quality Technical Information: A Handbook for Writers and Editors, 2nd Edition. The #1 guide to excellence in documentation--now completely updated! Direct from IBM's own documentation experts, this is the definitive guide to developing outstanding technical documentation--for the Web and for print. Using extensive before-and-after examples, illustrations, and checklists, the authors show exactly how to create documentation that's easy to find, understand, and use. This edition includes extensive new coverage of topic-based information, simplifying search and retrievability, internationalization, visual effectiveness, and much more. Coverage includes: Focusing on the tasks and topics users care about most Saying more with fewer words Using organization and other means to deliver faster access to information Presenting information in more visually inviting ways Improving the effectiveness of your review process Learning from example: sample text, screen captures, illustrations, tables, and much more Whether you're a writer, editor, designer, or reviewer, if you want to create great documentation, this book shows you how! [O'Reilly Network Safari Bookshelf]

Mon, 28 Feb 2005 21:31:01 GMT

BPO battle heats up. BPO (business process outsourcing) is quickly becoming a frontline solution for CIOs desperate to reduce costs and automate business processes.

Reducing the Total Cost of Ownership
Learn how to reduce the total coast of ownership in enterprise data management in this case study.

[InfoWorld: Top News]

Mon, 28 Feb 2005 00:24:48 GMT

Planet Roller internals
[Blogging] Permalink | Comments [2]

I promised some details on PlanetTool (the command-line tool that generates Planet Roller) internals, so here goes. This is what happens when PlanetTool runs:

Startup

(1) We start by reading the XML configuration file (via JDOM and XPath)

(2) From the config, we create a config object, subscriptions and groups

(3) A group has subscriptions

(4) And a subscription can belong to more than one group

Refresh subscription data

(5) For each subscription, call the Rome Fetcher

(6) Fetcher uses Conditional Get and Etags and caches feeds on disk

(7) Feeds parsed into entries objects and added to subscription objects

File generation

(8) Call Velocity Texen with name of a control template

(9) Texen calls our control template

(10) Control template calls file generation templates

(11) Templates calls planet object to get config, group, subscription, and entry objects needed to generates files needed for aggregated site (HTML, RSS, OPML, etc.)

Tue, 15 Feb 2005 23:30:54 GMT

Which interface should I use: XML/HTTP (REST) or SOAP ?

The Amazon Web Services (AWS) program offers two interfaces to (largely) the same basic services. One is an XML over HTTP interface (sometimes called a REST interface), while the other is an API adhering to the SOAP standards.

Which interface should you use?

The very short answer

If in doubt, use the XML/HTTP (a.k.a. REST) interface.

The slightly longer answer

Both XML/HTTP and SOAP are good, standards-based interfaces, and there is a priori little to choose between the two. The table below attempts to summarize some of the strengths and weaknesses of each type of interface.

	Pro	Contra
XML/HTTP	Simplicity: Easy to read and debug the messages between the client and servers. Access to the full AWS functionality. The fastest interface.	Lower-level interface than SOAP and therefore often more work for the programmer. Using UTF-8 characters in query strings can be a little tricky in some environments.
SOAP	High level interface, often with excellent support in the development environment (e.g. .NET) Often easier to code (as above)	Does not provide access to the full AWS functionality (specifically the XSLT service is not available through SOAP) Can be slightly harder to debug due to additional SOAP encoding of the messages between your application and Amazon's servers. Is slightly slower than the XML/HTTP interface: I find an overhead of about 15%. With un-careful coding (e.g. by creating a connection object for each request, referencing the WSDL file on Amazon's servers each time, instead of re-using the object), it can be much slower, especially if network bandwidth is an issue. In the Amazon implementation, SOAP is more unreliable than XML/HTTP, i.e. the SOAP service has a much higher down time. Presumably this will be fixed in the future.

I propose the following little decision table to help you decide between XML/HTTP and SOAP :

Do you need the XSLT service?
If so, then you must use the XML/HTTP interface.
Are you familiar with either XML and HTTP or SOAP already?
If so, use that. Programmer efficiency is likely to be much more important that anything else.
Do you need every last bit of performance?
Really? Buy a bigger server / invest in more bandwidth. Consider caching of important data.
Is SOAP and WSDL well-supported by your development environment?
If so, use SOAP.
Still unsure?
If still in doubt, use XML/HTTP.

eXtreme eXtensibility

Tue, 15 Feb 2005 23:19:13 GMT

eXtreme eXtensibility

(XML Schema Design for the Semantic Web)

by Roger L. Costello

January 25, 2003

Issue: how do we design an XML Schema so that it places no restrictions on the vocabulary that instance documents employ, and which facilitates the growth of data in a highly distributed fashion?

Uses of the eXtreme eXtensibility Design Pattern

This document describes a way of designing XML Schemas which enables data to be collected (and stored as XML) in an independent, distributed fashion, and with no restrictions on the XML vocabulary. The design pattern that is presented is especially useful for situations where:

you would like to collect data about something (and store the data as XML), and
you would like to allow for the data to be collected by various people (that is, the data is collected in a distributed fashion), and
you would like to allow for unforeseen data (that is, no limits on the XML vocabulary employed), and
you would like to be able to aggregate all the distributed data to generate a consolidated picture.

Here are some examples of situations that would benefit from this design pattern:

Describing a Geographic Resource: for example, there may be several independent teams of scientists collecting data about an active volcano. It would be beneficial to enable each team to publish their data independently, and then at a later time aggregate all the data. Another example in this category is the collection of data about a river. I will use this as my example throughout this paper.
Providing Biographical Data about a Person: for example, suppose that you are in charge of a small team of people tasked to collect biographical data about Albert Einstein. This schema design pattern is ideally suited, as it allows each member of the team to work and publish independently.
Intelligence Collecting: by nature, collecting intelligence data is a distributed activity. This schema design pattern supports that data collection activity.

These are just a few uses of the schema design pattern that will be presented in this paper. In general, whenever you want your data collection and publication activities to take advantage of the Web environment then this is a good design pattern. Clearly, its use is limited only by your imagination.

Classical XML Schema Design

Classical XML Schema design is prescriptive. That is, the schema identifies a resource type and prescribes what data is allowed for that resource type. For example, consider this data about China's Yangtze river: Classical schema design would declare a River element, comprised of a sequence of child elements - Length, StartingLocation, and EndingLocation. For example, here's an XML Schema that follows the classical design approach:

Deficiencies of the Classical Schema Design in a Web Environment

XML instance documents and, by implication, XML Schemas are intended to be used within a Web environment. Yet classical XML Schema design is at odds with the Web environment, as we shall see below.

The Web Approach to Data - eXtreme eXtensibility!

Suppose that you create a Web page containing data about the Yangtze river. Independent of you, and without your knowledge, I can create a Web page that contains other data about the Yangtze river. And I can link my Web page to your Web page. Your Web page adds value to my Web page and vice versa. A third person can create still another Web page containing more data about the Yangtze river, and link it to both of our Web pages. A rich Web of data about the Yangtze river is emerging. Note the characteristics of this Web approach to providing data about the Yangtze river:

Distributed Data: the data about the Yangtze river is distributed over multiple Web pages.
Unlimited Vocabulary: the richness and amount of data that is available to describe the Yangtze river is limited only by the imagination of the Web page designers.
Unordered: there is no order to the data about the Yangtze river. The hyperlinked Web pages comprises an unordered collection of data.
Aggregation: the sum total data about the Yangtze river is obtained by aggregating the disparate Web page data.

The Web is the classic example of what Dee Hock refers to as a "chaord" (a system that has a mix of chaos and order).

The Classical XML Schema Approach to Data

A typical XML Schema for defining the structure and type of allowable data about the Yangtze river is shown here: The XML Schema specifies what data is allowed ("you can give the Length of the river, its StartingLocation, and its EndingLocation"), and in what order. If you create an XML Web page, and the page conforms to the above schema then it must necessarily be limited to the type of data dictated by the schema, e.g.: If I create an XML Web page then my page will look the same. And if a third person creates an XML Web page it too will look the same. The schema imposes uniformity, regulated, controlled data design. Let's note the characteristics of the classic XML Schema approach to defining data about the Yangtze river:

Centralized Data: even though there may be multiple Web sites containing data about the Yangtze river they all contain the same data (vocabulary). Thus, there is effectively one, centralized data.
Limited Vocabulary: the richness and amount of data that is provided for describing the Yangtze river is strictly limited by the XML Schema. Unforeseen ways of describing the Yangtze river is not enabled.
Ordered: there is strict ordering of the data about the Yangtze river.
Collection: the sum total data about the Yangtze river is obtained by going to any one of the Web sites and collecting the data.

Recap: Web Data Design vs. Classic XML Schema Data Design

Below is a table which summarizes the above discussion.

XML Schemas	Web
controlled growth of data	anarchical growth of data
centralized data	distributed data
collect data	aggregate data
vertical data design	lateral data design

Effective Use of XML and XML Schemas in a Web World

To make XML, and by implication XML Schemas, usable in a Web world requires a shift in how we design XML Schemas and in how we think about data. Below are the requirements on an XML Schema for describing the Yangtze river where we make effective use of the Web environment:

Unlimited Vocabulary: There can be no restriction on the contents of the River element. This will allow for unforeseen data. Any vocabulary that the schema provides should be considered as merely a starting point.
Unordered: There can be no restriction on the order of the data

[Note: complete anarchy would place absolutely no restrictions on the content of the River element. For example, it would allow the River element to contain a "fuselage" element. We don't want complete anarchy. We want to allow any elements, as long as they make sense for a River.] Next we will see how to design a schema that takes into account these requirements.

XML Schema Design for eXtreme eXtensibility!

Here's how to design a schema that meets the above requirements: Let's point out the key features of this schema:

There is no restriction to the contents of River, other than to say that the contents must belong to this namespace (in other words, I only want to allow as content elements which make sense for the River element).
An initial vocabulary - Length, StartingLocation, EndingLocation - is provided for use in the contents of the River element. This vocabulary may be extended, as we shall see.

Let's go back to the example of the three people building Web pages: you create an XML Web page that uses just the vocabulary provided in the schema: It is important to note that there is no restriction on the ordering of the elements within River. Further, there is no restriction on the number of occurrences of an element (we will see an example of this below). Thus, this is a general technique for enabling the contents of an element to occur in any order, and with any number of occurrences! Note that this technique has similarities to the <all> element, but is much more powerful! Next, I would also like to create an XML Web page about the Yangtze river but I would like to provide different data - data about the famous Three Gorges Dam. Here's my XML Web page: The Dam element is not one of the initial vocabulary that the XML Schema declares, so I will need to supplement the initial vocabulary by creating my own schema that declares the Dam element: The declaration for the Dam element says that its contents is anything, just as long as the elements come from the http://www.geodesy.org/dam namespace. The schema, Dam.xsd, defines that namespace. Here's Dam.xsd: Finally, the third person wants to provide data about the different names that the Yangtze river has acquired over time: Since this third person is also using vocabulary that is not present in the initial schema vocabulary list, he/she must supplement the initial vocabulary by creating a schema: Note that since the River element placed no restrictions on its contents, we are able to use the Name element repeatedly.

Recap of the Example

The above example showed how an XML Schema can be designed to enable each XML Web page to be designed independently and with no restriction on what or how much data is provided for the Yangtze river. It demonstrates a growing body of information about the Yangtze river. Aggregator tools can scoop up all the disparate pieces of (XML-structured) data to present a consolidated view of the Yangtze river. Nice!

Characteristics of this Design Pattern

This paper has presented a way of designing schemas that enables data to be collected (and represented using XML) in an independent, distributed fashion, and with no restriction on the XML vocabulary. It is important to highlight the key characteristics of schemas that employ this design pattern:

Schemas are Small: using this design pattern you create one schema for each resource (e.g., create a schema for a river), and provide an initial set of vocabulary that may be used with that resource (e.g., Length, StartingLocation, and EndingLocation). If you have a different resource (e.g., volcano) then you would create a different schema (and provide an initial set of vocabulary that may be used with the volcano resource).
Namespace = Class: with this design pattern the schema's targetNamespace is essentially defining a class (e.g., the targetNamespace for the River example was: http://www.geodesy.org/river. This can be interpreted as, "this schema is defining the river class")

Aggregation

Earlier I referred to the ability of a tool to aggregate disparate pieces of data and to present a consolidated view. Let's now look at how to aggregate the disparate Yangtze river data. In the example we had three people who created data about the Yangtze river. We ended up with 3 schemas and 3 instance documents:

The 3 Schemas

River.xsd: declared the River element, and declared the initial set of vocabulary that may be used to populate the River element - Length, StartingLocation, and EndingLocation. River2.xsd: this schema supplemented the initial vocabulary with a Dam element. River3.xsd: this schema also supplemented the initial vocabulary with a Name element.

The 3 Instance Documents

Yangtze.xml: this instance document showed the Length, StartingLocation, and EndingLocation of the River. Yangtze2.xml: this instance document described the River's Three Gorges Dam. Yangtze3.xml: this instance document listed the different names that the River has acquired.

Putting the data together

An aggregator tool will assemble the various data about the River, to create a single document: Thus, this instance document is a composite of all the disparate data about the Yangtze river! To validate the composite instance document the aggregator tool must compose all of the schema declarations into a single file. Here's the resulting schema: Thus, the vocabulary that is now available for describing a River is - Length, StartingLocation, EndingLocation, Dam, and Name!

Aggregation Problem

The power of this design pattern is that it empowers each person to independently describe the Yangtze river with no limitats on the vocabulary (i.e., the XML tags) that is employed to describe the River (rather, the vocabulary must all belong to the http://www.geodesy.org/river namespace). With that power comes potential problems when aggregating the disparate data. For example, suppose that two people (independently) want to describe the river's Dam. They each create their own schema which declares a Dam element. Everything is fine. Each person can separately validate their instance data. However, when an aggregator tool scoops up all the instance data, and all the schema declarations, then there will be a problem - the schema will have two (most likely different) declarations of Dam. That's a problem. What's the solution? Here are some ideas that I have (I welcome other people's ideas on this):

Validate Separately, Well-Formedness Collectively: each person can individually validate their data. When the data is aggregated don't bother with validation (what's the point?). Simply check for well-formedness. I suspect in 99% of the cases this approach is perfectly fine.
Wrap Duplicates: when there are duplicates, such as duplicate Dam elements, wrap each of them within a unique element. Do this both in the instance document as well as the schema. Obviously, this will require a much more intelligent aggregator tool.

Recommendation

As we have seen, this Web-oriented (eXtreme eXtensibility) XML Schema design pattern is useful whenever there is a desire to grow a body of information, especially when you want to grow a body of data in a distributed fashion. The above Yangtze River example is a perfect example of where, over time, you would like to grow a body of data about the river. XML Schemas for geographic features is a good candidate for this design pattern. XML Schemas for collecting information about a person is also a good candidate (for example, if you want to create a biography of Albert Einstein you may want to "grow" this data in an independent, distributed fashion). There are many, many other examples of where this design pattern is useful. Your imagination is truly the limit. The goal of the Semantic Web is to enable anyone, anywhere, anytime to provide data about a resource. Using the design pattern presented in this paper will bring your data in alignment with the vision of the Semantic Web.

Relation to RDF?

"This sure sounds a lot like RDF - identifying a resource (e.g., Yangtze river), providing data (property/value pairs) for the resource. Why 'fake it' with XML Schemas? Why not use the 'real thing' ... RDF?" Your observation is entirely correct. Ideally, we probably should use RDF. However, RDF is a less well understood by the XML community, it does not provide the same level of type checking that XML Schemas provides, and there is less support for it in terms of tools. So, the above approach is an interim solution. Using this approach will help make the step to RDF (and the Semantic Web) less painful.

Unification of XML Schemas and RDF

The best of all possible worlds would be to make instance documents usable both by XML Schema tools as well as RDF tools. Interestingly, two of the instance documents from the Yangtze river example are also perfectly fine RDF documents: as well as this one ... The other instance document, however, is not good RDF: The reason is that RDF tries to treat the Dam element as a property. The Dam element is actually a class (and Name, Width, Height, and Cost are properties of the Class). The solution is to wrap the Dam element: Now this instance document is also fine RDF! Since the world is moving towards a Semantic Web it makes very good sense to give your data dual use - useable both by XML Schema tools, and by RDF tools. (A friendly hint)

The Aggregation Problem Noted Above is not Present with RDF

In the above section on Aggregation I noted a problem with aggregating disparate schema declarations into a single schema when there are multiple different declarations of the same element (the example I gave was of two people independently declaring a Dam element). This is an inherent problem with XML Schemas. RDF, however, does not have this limitation. Anyone, anywhere, and at anytime can define the same properties, and when they are aggregated there will not be a problem.

Acknowledgements

I would like to gratefully acknowledge the following people for their excellent insights, suggestions, and advice:

Dave Case
David Jacobs
Frank Manola

Mon, 14 Feb 2005 02:02:46 GMT

Federal Process Improvement Systems.

The U.S. federal government is a BIG enterprise. With that in mind, OMB and FEAPMO have created the Federal Enterprise Architecture Management System (FEAMS). FEAMS is supposed to help agencies during the budget process discover other e-government initiatives within the federal enterprise that might be leveraged by a given agency. In a large enterprise, this is very important. Agencies often do not know what their peers are doing which limits the development of cross-agency and enterprise initiatives.

The latest quarterly federal report cards came out last week. It shows that almost every agency is making progress in eGov. However, only State and AID made enough progress to improve their overall egov status grade. Both moved from red to yellow.

In conjunction with FedBizOpps, the federal government has created the Business Partner Network. BPN.gov refers to itself as the "single source for vendor data for the Federal government." BPN hosts the Central Contractor Registration system (CCR).

Check out this flash training on FEDLOG, a logistics support system that has increased search productivity by a factor of 60. Quite effective.

An Assistant Secretary of State gave this address yesterday on carbon sequestration. AGRC and ITS are supporting several regional carbon sequestration projects. This report from the Carbon Sequestration Leadership Forum provides some interesting background information.

[David Fletcher: eGovernment]

Mon, 14 Feb 2005 01:13:45 GMT

Web Services.

Business Week has a special report on Web services: "Web services refer to a set of programming standards used to make different types of software talk to each other over the Internet, without human intervention...Unlike the ASPs, which were building out massive data centers and basically running rental services for other people's software, today's Web-service companies design their software from the ground up to be delivered over the Internet as a service. That's a big difference. It means their business model can scale, and the bigger they get, the more profitable they become because they're building on that initial research and development investment."

[E M E R G I C . o r g]

Mon, 14 Feb 2005 00:54:46 GMT

Infocus: Apache 2 with SSL/TLS: Step-by-Step, Part 1. This article begins a series of three articles dedicated to configuring Apache 2.0 with SSL/TLS support, in order to ensure maximum security and optimal performance of secure web communication. This part introduces key aspects of SSL/TLS and then shows how to compile and configure Apache 2.0 with support for these protocols. [SecurityFocus News]