[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [ebxml-jc] Groups - ebXML JC Meeting added]
For your information, should others be interested in attending. Thank you. >Tentative ebXML JC agenda, 23 February 2005 > >Note: Summary mentioned in meeting minutes 9 Feb 2005 will be distributed >prior to Wednesday's meeting. Thank you. > > -- Ms Monica Martin > > >ebXML JC Meeting has been added by Ms Monica Martin > >Date: Wednesday, 23 February 2005 >Time: 07:30am - 08:30am PT > >Event Description: >877 330 9868, hit ** and then passcode when prompted (09868#) >For international, dial toll paid 909 472 3386, and then 877 number etc above. > >Agenda: >1. ebXML adoption initiative - and user community requirements channeling - Status > >2. Update on integration and functional separation between specs - e.g. ebBP and CPPA alignment (Martin) > >3. White paper (Martin): Awaiting inputs from Breininger for Reg/Rep. >White paper outline reforwarded 9 February 2005. > >4. Other business >a. ebSOA status and ebXML JC >John Hardin will be attending. > >Note: PLEASE SEND ANY UPDATES or OTHER AGENDA ITEMS, THANKS. > >Minutes: > > >View event details: >http://www.oasis-open.org/apps/org/workgroup/ebxml-jc/event.php?event_id=7163 > >PLEASE NOTE: If the above link does not work for you, your email >application may be breaking the link into two pieces. You may be able to >copy and paste the entire link address into the address field of your web >browser. > >Referenced Items >Date Name Type >---- ---- ---- >Mon, 21 Feb 05 ebxml-jc-mtgminutes-mm1-020... Minutes >Mon, 21 Feb 05 ebXMLWhitePaper-outline-0pt... Reference Document > >
ebXML JC 2/9/2005 Present: Breininger Jamie Clark Durand Ian Jones Moberg Sally St. Amand Martin Regrets: None Absent: John Hardin Tentative Agenda: 1. ebXML adoption initiative - and user community requirements channeling Feedback from Fujitsu marketing. (Durand) Durand: Google group created by Ed Dodds. Marketing representative is coming up to speed with ebXML to become engaged in a more active way. Have not created a TC however. Need more marketing expertise in addition to engineering knowledge. Need well-defined mission. Upgrade web site. Prepare promotional materials. What should be the focus-marketing or integration and SOA, or both? Don't see momentum for a TC. JB Clark: a. TC and another list: In the future, we could create an adoption list for a TC after proposal. Can't do another list however. b. Google list: On Ed Dodds effort, frequently someone wants to take the opportunity to create another list outside of OASIS. c. Other options: Could create another dev list as well, another users group (-dev, -usergroup). Who will be coordinator? d. Open questions: How to coordinate marketing and adoption-TC, this JC or another JC. Moberg: Address users group later. JB Clark: Message and architectural control Publicizing the work Jones: For ebMS, close to plotting our published plan. JB Clark: Have to coordinate across specifications; predictions should be as accurate as possible. Jones: Try before OASIS Symposium. JB Clark: UN/CEFACT asking. Foreign national communities are asking. Martin: Send summary to the JC list of status for JC members to add details. 2. Follow-up on integration and functional separation between specs - e.g. ebBP and CPPA alignment (Martin) No time to discuss. 3. White paper (Martin) Awaiting inputs from Reg/Rep. White paper outline sent 9 February 2005. Martin: Received items from Moberg. Moberg: Use FAQ to enable. Breininger: Reg/Rep will provide her outline. JB Clark: This is also part of the external messaging. 4. Other business a. ebSOA status and ebXML JC JB Clark: Original TC chartered and folks will continue to participate. There was difference of opinion about goal. The two TCs help to solve this. New TC SOA Reference Model TC announced. Reference: soa-rm: http://www.oasis-open.org/apps/org/workgroup/soa-rm/description.php (charter) ebsoa: http://www.oasis-open.org/apps/org/workgroup/ebsoa/description.php (charter) meeting notice: http://www.oasis-open.org/apps/org/workgroup/ebsoa/event.php?event_id=7154 meeting notes 17 Feb: http://www.oasis-open.org/apps/org/workgroup/ebsoa/document.php?document_id=11477 Martin: Do we ask Hardin? JB Clark: Get a new representative. Martin: What relationship ebSOA to ebXML architecture? JB Clark: They are not the owners of the document. No TC addresses this. See if we can get involvement with CEFACT as well. Martin: Isn't the ebSOA some relationship? JB Clark: Yes. Martin: What about SOA RM TC? Read the charter; ebXML is a valid instance of stack of services that might adhere to the abstract model. Coupling is very loose; relationship unknown. Ian Jones: Re: ebSOA, we need to resolve with Hardin. Moberg: Need round of discussion about how to clarify architecture document. JB Clark: Need to have these discussions; OASIS and user communities interested. Moberg: Need to check with Hardin's intent and then discuss in two weeks. Schlegel may be a contributor if we have a better scope. [add] IPR policy JB Clark: No surprises if read the draft. 2 years required to convert. Moberg: Who can sign by company? JB Clark: That is relevant to the company. Jones: What about individuals? What about large company environment, how are individuals educated on these new constraints? JB Clark: Problem is many companies are doing this. Assume companies will coordinate some of these efforts. Martin: Responsibility to publicize by TC chairs and the TC themselves. (private) pushed board out of making that decision and made company decision MARTIN: Contact Hardin, ask Ed Dodds to attend. ALL: Send summary of progress and projections of technical specification updates.
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)
* Relationship to ebMS and CPPA
o Opportunities and challenges
o Conformance testing in the future (link to IIC work)
* Roadmap
o Release of v2.0 draft
o Plans/requirements for v3.0
[1] Enabled by v2.0.
4. Collaboration Protocol Agreements
-What is ebXML CPPA?
-Business needs and requirements
* Technical capabilities
* Configuring public shared protocols
* Enabling collaboration monitoring
-Progress and plans
* Current errata
* Protocol profile negotiation
* Relationship with ebMS and ebBP
* Future plans
-Deployment examples
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]