istribution and decentralization?with XML as their foundation?are at the core of Digimax Multimedia’s collaborative decentralized services (CDS) technology. CDS is a development framework that is both a consumer and a provider of data or functions, integrated with a dynamically configurable logic or processing layer.
CDS can consume XML data from any source through various transports, including HTTP, FTP, SMTP, POP3, or an instant messaging format. The XML consumed can contain presentation templates, raw data, connection profiles/preferences, and security information, as well as application logic. CDS then sorts through this data, using its XSL-like tag schema to describe where to get the information, what to do when it has all the data, and what to do with the result when it is done processing. CDS documents act as scripts that describe the logic of the application (see Figure 1).
|Figure 1: Digimax’s CDS Process
This functionality, called entity-to-entity computing, is a concept that Digimax believes will emerge and enable the next generation of Internet-based business technology. With this concept, an entity can be a single user, a company, or a group of companies; a computer or a fleet of computers all over the world; or a variety of combinations of users, functions, computers, companies, or devices. The only requirement is that the data exchanged among them must be in XML form. However, data in another format can be transformed into XML with a connector that abstracts the conversion from the CDS core. For instance, a connector to convert to and from EDI could be used to process data that is accessible through one of the transports.
CDS’s ability to be both a data provider and a data consumer in conjunction with conditional logic enables it to be both a client and a server. A few additional factors contribute to its future value:
- CDS does not need to be on both sides of the entity-to-entity connection to function.
- Since CDS documents are text that contains the application, logic, or functionality, a CDS-based application can receive new instructions over the Internet without requiring user or administrator intervention (except possibly for security).
- The possible configurations and locations of the data are at the discretion of the application designer.
- A high degree of separation exists between the developers who specialize in each tier of development. For example, an HTML developer need never know anything about how CDS functions or is coded. The same is true for third-tier developers. Data designers need to have an understanding of XML and how it relates to the data management systems on which they develop.
|Editor’s Note: The author, Joshua Lynn, is a member of Digimax Multimedia’s executive team. We have selected this article for publication because we believe it to have objective technical merit.
How Does CDS Work?
The CDS Processor encapsulates a group of standard tags, each representing one or many complex objects beneath it. These tags provide core functionality common to many applications (see Listing 1 for sample code). This standardization lets users learn a single tag, leaving the underlying complexities of object selection and proper utilization to vertical experts. For example, the
Digimax strongly modeled the CDS Processor after the concepts and styles of XSLT. The language has support for common structural tasks such as iteration and conditionals, including tags for manipulating XML documents, ODBC, and Microsoft’s SQL Server. Also, since the language is fully XML-compliant, CDS documents can take advantage of pre-existing and proven technologies such as schema validation, XPath, and processing-instructions to name a few.
At this time, developers can create functions but not elements. These functions can be derived from CDS or by using the msxsl:script element and language attribute. Developers can use any language supported by the Microsoft XSLT processor. In the next release of CDS, users will be able to create their own elements.
How Can I Use CDS?
Initially, CDS can be used to build any Web-based applications that are commonly used today. Using the CDS technology to build familiar Web-based applications such as e-commerce, CRM, and back-office applications has several benefits. Speed to market is the most noticeable, through improved performance and rapid development and modification. Second is the ability to rapidly expand the types of interfaces supported by an application to include wireless devices, handheld computers, or whatever comes next. The CDS technology can also render any text-based output and adapt to any transport as a result of the strong separation between the presentation, logic, and persistence tiers. Additionally, CDS can work alongside or in-line with any other Web application technology such as ASP, JSP, or servlets (see the CDS-based Web sites ModernAgent.com and Aquatech.com).
CDS can also be used in enterprise application integration (EAI) as a middleware application. Integrating applications that already exist inter- and intra-enterprise is a natural fit since CDS functions independently of interface and data source. The interface could be for a user with a Web browser or a computer system at a partner that needs or provides information. The location of the data sources is irrelevant to CDS so long as they provide XML. This is where the real benefits of entity-to-entity begin to emerge:
- An application can have an infinite number of interfaces so long as they can accept a form of text. (i.e., Web services such as calculators for shipping and materials, cash registers as a service that can be run on computers with browsers or handheld devices, stand-alone or as part of a work group).
- Applications delivered as services, such as payroll, timesheets, and order entry, can integrate with each other in a distributed or centralized environment.
- Auctions could be held peer-to-peer on the fly.
- The capabilities of instant messaging and chat could be applied to automating supply chains in real time, allowing groups of systems to chat with each other.
How Does CDS Differ from Other Technologies?
The technologies that most easily compare with CDS are ASP, JSP, CGI, and servlets. They all are used to build dynamic Web applications, and architecture similar to CDS also can be built with these technologies. In fact, CDS could be used directly inside all of these technologies. Because CDS is transport-independent, it does not require a Web server to function. Although integration into a Web server is the primary technique for using CDS today, it isn’t a requirement of the technology.
Other technologies have features or architectures in common with CDS. Microsoft’s BizTalk has XLANG, a schema for orchestrating workflows, which is similar in function to the CDS schema. However, BizTalk is designed as a server-messaging product to be hosted in a server environment. CDS is designed independent of scale. It can operate from text files on a workstation’s local drive all the way up to a high-performance server attached to a high-performance XML data repository. Also, BizTalk is dependent on ASP for Web integration and other Microsoft technologies for wireless connections or extended functionality. CDS utilizes external technologies but doesn’t depend on them for its core functionality.
webMethods is another product that has similar functionality. However, it has many of the same drawbacks as BizTalk. Both products are designed strictly as integration tools. CDS goes beyond integration to enable a platform that can incorporate unlimited interfaces. These interfaces can be uniquely configured for each connection based upon persisted information. CDS provides only a framework to accomplish customized presentation development. It is the implementer’s option to specify this type of behavior.
Past, Present, and Future of CDS
CDS currently is a technology and not yet a solution. Its versatility combined with a lack of terminology to describe its future uses make defining CDS difficult. However, if one thinks of it as a building block or fundamental element that can be assembled into larger parts or applications, seeing its potential becomes easier.
Digimax currently uses the technology to build generic solutions that it configures to meets its individual clients’ development needs. These generic applications can be custom configured very rapidly to fill the needs of ASP-type hosted applications. Ultimately, Digimax would like to market the CDS technology to other developers, independent software developers, or companies who can use the technology to build custom solutions in-house.
Over the coming months, Digimax will release a series of applications built on the CDS Development Platform. The CDS Processor currently resides on top of Microsoft’s .NET platform. Digimax plans to release a Java-enabled version in mid 2004.