[ebxml-jc] 2/2/2005: White Paper Outline for ebXML (Need CPPA Reg/Repinputs)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Note: I am still awaiting inputs from Kathryn and Dale. Since we will 
meet 9 February, it will give you time to provide your feedback, Kathry 
and Dale. Thank you.

> ........(1/13) Below 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.
>