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 <DAPI>

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 <OMAPI>

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 <PAPI>
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 peered-
limitedStanding).

• 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 / elevate-
standing-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 tgould@ld.com

Alan Wilensky awilensky@ld.com