Grand Horizon

The Grand Horizon of Embedded Commerce Services Todd Gould, President Loren Data Corp Alan Wilensky, Analyst bizQuirk Abstract by A.D. Wilensky This monograph explores the mid-market adoption of electronic commerce communications services. Taking a page from Loren Data Corp's ECGridOS Communications API, (a flexible set of services for integrating EDI communications into applications), we posit an imaginative and expansive set of API services suitable for hosted commerce platforms. Software as a Service models are starting to have an effect on the adoption of lightweight, specialized commerce services; a perceptible move towards a services model (SAAS, PAAS, IAAS) is changing the way small and medium businesses run capital line applications. Web Services APIs (application programing interfaces) figure prominently in offering the types of embedded services that cloud platforms consume in order to expand their commerce communications repertoire. Services Registries (compendiums of related APIs), could play a role in delivering such services to this market. Companies who field these systems are prodigious consumers of 3rd party APIs. A target market therefore exists for providing e-commerce communications services to these hosted services providers. Some of this optimism is tempered by market perceptions of EDI services as unfit for agile commerce. Some of these opinions come from savvy developers eager to pioneer alternatives, some from EDI virgins merely seeking a easier path to electronic trade. Either way, there are perception issues, many grounded in reality, and there shall be opportunities to address them with an eye towards innovation. Colleagues may differ over technical issues; all in good time. If past experiences are any indication, we shall see thought-leaders, laggards, and innovators. There may arise a Utopian, cohesive registry, or several competitors may overlap. It is a big industry, an almost unlimited opportunity, and a new way to create as yet unheard of services via combining APIs. Analyst's look down the adoption curve and discern the dynamics of product uptake, while technology providers focus on product creation and delivery; neither owns a crystal ball, yet somehow the partnership is productive. A portion of these concepts form a portion of Loren Data Corp's malleable product road map. We are pleased to share these musings with the community of VANs, tool-smiths, platform providers and OEM's. We welcome the considered criticism of colleagues, and hope that all will be engaged in the future of open commerce services.

Old Problems and New Markets Never did I not exist, nor did you nor these kings. Nor shall we ever cease to exist in the future. - Bhagavad Gita 2.11 and 2.12 The problems of partner communications remain with us, particularly in the mid market. Exchanging data between partners, creating streamlined trading agreements, and handling transaction exceptions are some of the challenges facing SME's. These problems are long standing and perpetually irksome for all enterprise classes, and the questions is, 'at what cost can these issues be addressed'? Don't let the hype surrounding cloud computing obscure its potential for providing valuable services to the SME. Mid market commerce is suited to cloud platforms, because data access, translation, and process orchestration are delivered at a fraction of the cost of licensed applications. Most platform providers work with an impressive cadre of 3rd party web services via public APIs, while PAAS (Platform as a Service) environments rival well established IDE's for custom code and UI craft. Beyond the supply chain, we see the development of workforce and task management, subcontractor RFP, accounting, and plenty of variations on lightweight floor inventory control and POS. Supply chain functions are there too, some rivaling the robustness of costly integration servers. In short, this is a rich market. These platforms will not totally eliminate the problems of partner peering, enabling open trade, and liberating data from rigid tabular confines, but they are certainly the next place to tackle the problems of data transparency. Having partially addressed the economics of applications delivered at-scale, the cloud operators are on the lookout for broadly applicable solutions for their subscribers, perhaps via partnerships with commerce messaging providers that will provide the path to expanded services.

Rapid Services Creation and Delivery Seemingly impressive partnerships and strategic agreements abound within the B2B cloud ecosystem most being enabled by external APIs. A popular on-line GL application might connect to a plethora of external services for project management, content management, logistics, etc. These partnerships are often quick to form - particularly when API access is provided at low or no cost as a value add. While these architectures may not be paragons of standardization, they prove that new services can be mashed-up and delivered when opportunity calls. Agility is the watchword when mastering the 'art of rapid services'. Classic EDI providers take note that a few of these companies have forged alliances with retailers and independent service companies. Not all of the programs have been successful, and very few would survive a direct comparison to capital line applications within the EDI orbit. However, this trend will only continue to gather steam. The cautionary tone is not to alarm, but to inspire. Some of these companies provide free API access with limitations. Similar to open source models, these product strategies bring in business via free API access, and monetize via extended and premium service and support packages. Lessons:

• • • •

Create simple to use services. Create a flat, flexible pricing model Foster an ecosystem that encourages experimentation and mash-ups. Make it easy for SAAS and PAAS providers to adopt your API, they are your new channel. (consider and adapt to their run time environment)

In the enterprise, there is also much to say about the other prime adopters of API's - SOA and ESB; we will save that for another time.

Classic Challenges & The Business of Web Services The longstanding challenges are still with us. In spite of the fact that experienced EDI providers have so much to contribute, there is too wide a gap between sophisticated e-commerce system integration solutions and the EDI reseller offerings. Agile competitors, poised to occupy the solution space, could just as easily be partners through a coordinated effort to build and market a comprehensive commerce services registry. Offering a palette of fine-grained commerce services that solve the problems of partner peering, data interchange, and communications, is the grand vision. Here is a run down of the proposed API families. Todd can provide special insight into ECGridOS currently the only Web Services API for embedding EDI communication within applications.

The Business of Web Services Marketing a web service is a different ball game. Sales targets are technical staff members that must become internal advocates. Time must be allocated for prospective clients to test and experiment. Sector uptake in the early days requires evangelism, with the best strategy being a cooperative marketing approach coordinated amongst providers adhering to standards of interoperability. Creating a community of developers and advocates that use Web Services to deliver solutions does not occur overnight. There are distinctions between trivial and non-trivial API flavors. Web Services with 90+ functions are quite different in character from a REST API with a dozen functions. APIs are a challenge to demonstrate at trade events without a supporting library of training assets and demo code. There are many contemporary Web Service registries; some are free, some are vendor paid. Many of these directories are true 'central registries', where the infrastructure for serving, scaling, billing, and metrics is shouldered by the registry. Industry consortia often catalog and refer members, but do not host or manage accounts. Some industry organizations are starting to think about services continuity - allowing one API provider to backstop a competitor, while keeping client data safe.

The EDI Communications API Loren Data Corp's ECGrid® is well know in the VAN industry as a trusted communications service for brokering traffic and routes. ECGrid solves a specific problem for a special class of electronic commerce service provider by removing the operational and administrative burden of inter-network message minding. For application level access, however, there was no way to integrate EDI message transit. Todd Gould saw that FTP and AS2 connection methods were lacking in flexibility, and that at some point hosted commerce portals would need more direct control over message delivery and partner

configuration - not as a bulk connections and external adjunct protocols, but as a fine-grained services bound to application code. ECGridOS was born to serve internal and external requirements: 1) For Loren Data to manage its operations and extend services, and 2) to provide a faster response to customers needing custom administrative and application level communications bindings. The API has been very successful for Loren's internal work. The administrative challenges of running a new service with a different model of access is an evolving and enlightening challenge. Cloud Platform providers have been warm to the idea of ECGriOS. In the course of discussing what the API can do for these potential partners, the conversation inevitably turns to future functionality that might be offered - these conversations are where analyst's mines their best industry intelligence. Lets take a look at the API families.

Directory API Directories are not information portals, although portals can certainly use directory APIs. There are a few ventures endeavoring to marshal EDI organizational data for trading partners trying to keep up to date on certificates and contractual data. A directory can certainly encapsulate this data without being married to the UI and access layer. Directories are important for a reason: • If an entry exists in the directory, it is there for a reason • Permanent or transient (expiration bound) entries imply a most elementary grant of access to other services • Directories provide a place for meta data and other intermediate state variables The directory becomes the central place to store all further access / grant items, data format schema, extensible membership data, etc. Each class of API must be able to stand alone, such as when an explicit trading partner ID is invoked 'old school' in an EDI Communications API. However, as registries gain momentum, an increasing number of platforms will advocate for directory moderated peering. Direct communications will be reserved as a legacy. The communications and directory APIs are the first examples of where vendors will cooperate.

Open Market API An open market API provides unpaired, unstructured data gateway services for non registered systems (applications and data) to enter the ecosystem. Outbound requests are uniform, and the API provides a way for subscribers to get a predictable document object for RFPs and service dispatch orders. The current state of the industry encompasses a mix of specialist portals offering data scrapings of offers and listings; open market web services provide a way to normalize data from these fragmented portals, and to promote better distribution of market opportunities via the hosted platform channels. OMAPI might become important, as the mid market is all about leveraging technology to boost market traction. The service industry (repair, trades, technical specialty) is quite appropriate for applications that build atop this registry. Clever, informative marketing might lead to partnerships outside of the e-commerce regulars. Think of OMAPI methods as structured messaging for inbound and outbound work orders on the wire.

Peering and Approvals API Peering is a work flow process initiated to create a trading pair. Today's process of creating EDI trading pairs is non-standardized; some would say it is a profoundly broken process. A services registry is one approach to formalizing the peering procedure. Trusted pairs are created via grants-of-standing. The peering web services API (PAPI) uses grants of standing that are extended by approvals, which may be provided by 3rd parties. There are countless instances of relationships that can pair in a simple, ad-hoc manner. In a local services market, pairs can be initiated via search, portals, introductions, or memberships. A simple API for presenting a request to pair might encompass the following: • Request to peer / command to peer (directional) Universal Request to Peer - another API layer uses the work flow recursively, e.g. directories can request transient RTP (request to peer) and changes in status from (unpeered to peeredlimitedStanding). • Grants of standing (dynamic - subject to revocation) Standing is a grant to accept and act upon the exchange of data objects. Standing may use approvals to extend the standing context. Example of a grant: grant-limited- standing / elevatestanding-provis-to-good. • Approvals (implied and via 3rd parties) Approvals are extension to standing. The predicate relationship allows a service consumer to create a grant instance that is dependent on a trusted 3rd party (like an X12 type org) or a paid 3rd party (credit). Example of an approval: forprovis-standing-(orgID-)alicense-asomething.? • Extensions to the BPM Orchestration ( API providers, 3rd parties, and developers) All encapsulated, long running processes that extend the default peering and approval work flows. A library of custom orchestrations. There is a very active B PM tools sector pushing the "value proposition", with numerous free and open source vendors. There has never been a better time to adopt orchestration tools for the long running processes of peering.

Data Objects and Access API There is an entire class of services concerned with data access. Just as a peering work flow in classic EDI is tied to specialist labor, data access services (eliminating one-off mappings and translations), have the potential to cause disruption. This is what progress looks like. There are current efforts circulating around developer tools and language forums discussing the adoption of ecommerce micro-formats. Canonical libraries are semi fixed common business documents. Libraries curated by organizations look like X12 style documents. All of these are ways to simplify data exchange. Advanced data exchange regimes enable the source or destination schema to be unbound from inviolable table structures. Linked Data conveys a set of URIs that deference to RDF data in the format (subject, predicate, object). The end result of any data exchange API should be to liberate the partner pairs from the constraints of data field ordering that may hamper mutual trade. It is instructive to note that ASC X12 is actively working on a specification called, "CICA" that uses RDF /XML and OWL (Web Ontology Language).

Data reconciliation is one of the greatest obstacles to increasing mid market adoption - it has become, like peering, a show stopper. Some issues relating to data exchange between partners: • Cloud Platforms may be better candidates for offering data independence due to their sophistication and familiarity with the cutting edge of data access systems. •

Data Flexibility must be important, as the list of companies betting the farm is impressive. The cloud computing sector is doubling down on RDF, it seems.

• A Data access APIs should to keep it simple for the partners. Some programmers advocate canonical class objects that are completely unambiguous from a data field order point of view. • There are too many solution domains for data exchange. • The data objects API may use the directory API to store instances of which data objects belong to various partners. • Entire professions that 'owned' data migration will undergo great upheaval. Fresh Channels for Commerce Industry Web Service Registries Web services are now a proven business model, and cloud platforms are the most informed consumers of remote APIs. With the EDI market facing a challenge to meet competitive forces, the platform providers are a key channel for conveying web services for ecommerce communications. There is enough work proposed herein for literally dozens of companies to participate without the need for artificial exclusivity; multiple entities may offer similar API's1 distinguished by price, service and support. The most important benchmark for such a registry is that services must inter-operate and provide repeatable results - down the line, this might require industry certifications. Other issues to consider may include continuity, security, and indemnification against outages.

Conclusion The EDI industry's collective experience is highly transferable to a flexible, distributed, and coordinated service architecture. Models of scarcity, inflexibility, and closed systems must be relegated to our fabled past. The introduction of Loren Data Corp's ECGridOS places a marker on the future of platform providers, and the web services that extend their architectures. The ultimate measure of successful practices is their migration towards less sophisticated markets that are nonetheless lucrative. Therefore, the author's best judgment points to the future of cloud platform providers as a vital channel for extending the reach of granular commerce web services.

1. (as is done by BGP and DNS

The authors can be reached at: Todd Gould [email protected] Alan Wilensky [email protected]