[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 1/13/2005: White Paper Outline for ebXML
Attached is the latest outline. Jacques has provided feedback and some additional introductory information. We are awaiting CPPA and Reg/Rep outline inputs so we can continue this process (strong hint). Thank you.
ebXML White Paper Synopsis (V 0.2)
==========================
NOTES:
- the audience is "technical executive", say CTO and IT management, since they are decision makers on
adopting ebXML. Yet the style should resonate with vertical users with a B2B experience (e.g. EDI).
- also, for those already familiar with ebXML, the paper should give a feel of the future version.
- Each section would average 3-5 pages (overall paper between 30-50 pages, including figures).
Sections don't have to give an exhaustive view of the material referred to, nor a balanced summary,
but should convey the rationale behind it, and may focus on a few remarkable features.
Each section could include a short FAQ at the end.
- The outline below is rather classic, in breaking down by component. It could be different: describe
first the ISO version, then separately the future version (But the latter is too unstable today to deserve
a full section.) Or, could downplay the components and focus more on the integrated view, how everything
works together, giving away features details while unwinding scenarios & use cases. I though it would
be sufficient to have Section 1 do a bit of this binding-it-all-together job.
- we could involve marketing team to do Section #9.
1. ebXML: the Requirements, the Approach
- short definition: an ISO standard for Exchanging business messages, Conducting trading relationships,
Defining and registering business processes, Communicating data in common terms, Assembling business transactions.
- the business case (EDI-compatible in both content and architecture, accessible to SMEs, non-managed env.,
covering all partners of a supply chain, XML-based)
- (can reuse the EDI / ebXML stack comparison from Jon Bosak)
- an integrated approach of B2B focusing on interoperability needs, yet loose coupling with back-end systems.
eBusiness transactions can be of very different nature.
Some transactions can be characterized as "service calls" , others as "document transfer".
An inquiry for catalog information or a status request are usually queries of modest size and stable structure for which a fast response
is expected, and which can be repeated without trouble if needed. Such cases fall in the "service call" style.
But many other transactions consist of the exchange of sizeable business documents in very different formats (XML or not),
and which will be consumed by back-end processes in an asynchronous manner. ebXML Messaging supports these two styles of tansactions,
and in particular the exchange of business documents.
There may be many such business documents of different types between business partners for a domain of application.
These documents may be complex and likely to evolve via a versioning process over time. The processing of such documents usually requires
a decoupling with the messaging layer. The consumer of these documents may not be directly a “service” known in advance, but instead a
business process instance that needs this document at some point in its life cycle, or an application that will consume a batch of these
at the end of every day, or yet a dispatching system that will forward or queue messages based on content.
Such documents cannot be directly associated with an application service in a predefined way. The coupling between the messaging system
and the consumers of these messages (a business process, an application) must be loose.
The concept of a message as a “business document” envelope has also given the “message” a certain almost legal status at the end-user level,
as being a part of a business transaction. During the processing of a particular message, some actions may be taken that have
significant business value and yet are independent from the back office application, such as logging for keeping a trace as
legal evidence of business, authorization, generation of a confirmation of receipt.
Although some of these processing steps may be handled by messaging intermediaries
(like in the SOAP processing model), others will depend on the business payload content.
These functions will need to be performed before the message reaches its final destination - requiring even more decoupling with the
consuming application or “service”.
The ebXML model is aligned with this perspective of a message being a business item, which must allow for various ways of coupling
with the consumer of this business item.
The resulting architecture is of a clear separation between the messaging layer and the business process layer, with options for
integration in form of bindings.
- transitioning to ebXML (migration path)
- anatomy of an ebXML deployment (showing architecture, the interaction steps in usage scenarios)
2. Messaging
2.1 - Overview of current version
- requirements & driving principles, (SOAP on pervasive Internet transports, reliability and security,
smooth EDI transition, etc.)
- summary of salient features,
- some use cases, relationship with other ebXML specifications.
2.2 - the roadmap: what is next, the new requirements:
. leveraging Web services protocols for security, reliability.
. support for low-level payload processing (payload services)
. support for various message exchange patterns that map to business transactions.
. support for connectivity constraints (occasional connectivity, firewall restrictions, light ebMS clients)
3. Business Transactions and Collaborations
* What it is and how does it relate to ebXML BPSS: Standard language
for business collaboration
o Supporting process design and description
o Enabling collaboration monitoring and validation
o Guiding execution
* Design principles based on business semantics: [1]
o Standard business transaction patterns
o State alignment
o Binary and multi-party collaboration
o Composition: Visibility and relationships
o Enabling web services (abstract)
o Party and role definitions
o Enabling the process lifecycle
* Exemplar use cases
o Telecommunications (M. Roberts)
o Financial services (M. Arrott)
+ Automotive (Moberg)
o Retail (Yunker)
o Others...TBD
* Relationship to ebMS and CPPA
o Opportunities
o Challenges
o Conformance testing in the future (link to IIC work)
* Roadmap
o Release of v2.0 draft (hopefully by the time we get this
report done)
o Plans/requirements for v3.0
o White papers and technical notes (hopefully)
[1] Enabled by v2.0.
4. Collaboration Protocol Agreements
- Overview of current version
(requirements & design principles, summary of salient features, use case, relationship with other ebXML parts)
- the roadmap: what is next, the new requirements.
5. The Registry-Repository
- Overview of current version
(requirements & design principles, summary of salient features, use case, relationship with other ebXML parts)
- the roadmap: what is next, the new requirements.
6. Standardizing COntent
- Core components (requirements & design principles, summary of salient features)
- UBL
7. Testing ebXML
7.1 - Interoperablity testing and Badging.
. status in US, with UCC/DGI (for ebMS)
. status in Asia, (ECOM / ebXML Asia)
. status in Europe (CEN/ISSS, ETSI).
7.2 - testing environment for ebXML.
- Challenges of testing B2B interoperability.
- The IIC approach (conformance + interoperability, standard scripting of test suites, automation,...)
- Test Framework of IIC: an overview, current implementations.
8. Deploying ebXML in a SOA environment
- where ebXML fits in (example arch from GM)
- pilot projects (AIAG...)
9. Who deploys ebXML
- survey
- what do people do with ebXML, value they see.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]