1
3
UN/CEFACT eBTWG – Electronic Business
Architecture (UEB Architecture)
4
Working Draft
5
6
UN/CEFACT/CSG/eBTWG
Electronic Business Architecture
7
Revision 0.50
8
05 June 2002
2
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Table of Contents
UN/CEFACT eBTWG – Electronic Business Architecture (UEB Architecture) ........... 1
Table of Contents ............................................................................................................ 1
1.0 Status of this Document ............................................................................................ 3
2.0 Introduction ............................................................................................................... 3
2.1 Summary of Contents of Document ..................................................................... 3
2.2 Audience ............................................................................................................... 4
2.3 Related Documents ............................................................................................... 4
3.0 Objectives ................................................................................................................. 4
3.1 Goals of the UEB Architecture ............................................................................. 4
3.2 Requirements ........................................................................................................ 5
3.3 Caveats and Assumptions ..................................................................................... 5
3.4 Design Conventions for UN/CEFACT eBTWG Electronic Business
Specifications .............................................................................................................. 5
4.0 Overview ................................................................................................................... 6
5.0 Phases ...................................................................................................................... 11
5.1 Implementation Phase ......................................................................................... 11
5.2 Discovery Phase .................................................................................................. 14
5.3 Design Phase ....................................................................................................... 14
5.4 Runtime Phase .................................................................................................... 19
Component Constraints................................................................................................. 22
6.0 Modeling Methodology .......................................................................................... 23
6.1 Introduction ......................................................................................................... 23
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 1 of 53
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
6.2 Formal Functionality........................................................................................... 26
6.3 Interfaces ............................................................................................................. 26
6.4 Non Normative Implementation Details ............................................................. 27
7.0 Business Process, Collaborations, Commitments and Schemas. ............................ 27
7.1 Introduction ......................................................................................................... 27
7.2 Formal Functionality........................................................................................... 28
7.3 Interfaces ............................................................................................................. 28
7.4 Non Normative Implementation Details ............................................................. 30
8.0 Core Components.................................................................................................... 31
8.1 Introduction ......................................................................................................... 31
8.2 Functional Requirements .................................................................................... 34
8.3 Interfaces to other Components .......................................................................... 35
8.4 Implementation Details (Non Normative) .......................................................... 35
9.0 Trading Partner Profiles and Agreements ............................................................... 37
9.1 Introduction ......................................................................................................... 37
9.2 Trading Partner Profile and Agreement Formal Functionality ........................... 37
9.3 Trading Partner Agreement Specific Formal Functionality................................ 38
9.4 Trading Partner Profile and Agreement Interfaces ............................................. 39
9.5 Non-Normative Implementation Details............................................................. 40
10.0 Registry ................................................................................................................. 40
10.1 Introduction ....................................................................................................... 40
10.2 Formal Functionality ......................................................................................... 42
10.3 Interfaces ........................................................................................................... 45
10.4 Non Normative Implementation Details ........................................................... 45
11.0 Messaging ............................................................................................................. 46
11.1 Introduction ....................................................................................................... 46
11.2 Formal Functionality ......................................................................................... 47
11.3 Interfaces ........................................................................................................... 48
11.4 Non-Normative Implementation Details........................................................... 49
12. 0 References ............................................................................................................ 50
13 .0 Disclaimer ............................................................................................................ 50
14.0 Contact Information .............................................................................................. 50
14.1 Project Team Membership ................................................................................ 50
Copyright Statement ..................................................................................................... 52
70
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 2 of 53
71
1.0 Status of this Document
72
73
This document specifies an eBTWG WORK IN PROGRESS - NOT FOR
IMPLEMENTATION - for the UN/CEFACT eBusiness community.
74
Distribution of this document is limited to Architecture team members.
75
The document formatting is based on the eBTWG Standard format.
76
77
78
This version:
http://www.ebtwg.org/projects/documentation/architecture/eBTWG_Architecture_v0.50.
doc
79
80
81
Previous version:
http://www.ebtwg.org/projects/documentation/architecture/eBTWG_Architecture_v0.49.
doc
82
2.0 Introduction
83
2.1 Summary of Contents of Document
84
85
86
87
88
89
The goal of the UN/CEFACT eBTWG Electronic Business Architecture (heretofore:
UEB Architecture) specification describes a high level architecture for an infrastructure
to facilitate electronic business on a global scale in a secure, reliable and consistent
manner. This document abstracts architectural components in order to facilitate both
Extensible Markup Language (XML) and other structured information exchanges such as
Electronic Data Interchange (EDI) formats like EDIFACT.
90
91
92
93
This Architecture document shall be considered a superset of the Electronic Business
XML (ebXML) Technical Architecture v 1.04, and serves to complement and extend that
document. This extension to the ebXML architecture shall provide input for revision to
the ebXML v 1.04 architecture.
94
95
96
97
98
99
100
101
102
103
104
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].
The following conventions are used throughout this document:
 Capitalized Italics words are defined in the UEB Architecture Glossary.
[EDITORS NOTE; add reference to Glossary]


[NOTES: are used to further clarify the discussion or to offer additional
suggestions and/or resources]
[EDITORS NOTES: expressed in red font are used to express works items that
need attention by the team]
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 3 of 53
105
2.2 Audience
106
107
108
109
110
111
112
113
The immediate audience considered for this document is the UN/CEFACT (United
Nations Centre for Facilitation of Electronic Business) eBTWG project teams, and their
successors, OASIS (Organization for the Advancement of Structured Information
Systems) Technical Committees (with relatedebXML work), other electronic business
groups working under the UN/CEFACT umbrella, and software implementers. Secondary
audiences include, but are not limited to, international standards bodies and topical
industry organizations.
114
2.3 Related Documents
115
116
Documents:
117
118
1. ebXML Technical Architecture v 1.04
2. etc…
119
Normative References:
120
[EDITORS NOTE: Revise once rest of document is complete]
121
122
123
124
125
126
127
128
129
130
1. UMM, UN/CEFACT Modeling Methodology (UMM) TMWG/N090/Division 10
2. ISO/IEC 14662, Open-EDI Reference Model (via ebXML TA v1.04)
3. UN/EDIFACT Architecture, ref 1509735, www.unece.org/cefact/
4. OO-eb, (OO-EDI Demonstration Project, Preliminary Technical Report,
CEFACT/TMWG/N088, 25 Feb '99), ANSI ASC X12/SITG
5. RFC 2119: Keywords for use in RFC's to Indicate Requirement Levels,
www.ietf.org/rfc/rfc2119.txt
6. ebXML TA v 1.04
7. ebXML Requirements Document v1.06
8. W3C XML v1.0 Second Edition Specification
131
3.0 Objectives
132
3.1 Goals of the UEB Architecture
133
134
135
136
In May of 2001, the ebXML initiative was delivered as a series of Specifications,
Technical Reports and White Papers, to UN/CEFACT and OASIS to address the needs of
business1 on a global basis. While ebXML has rapidly gained attention, continuing work
within UN/CEFACT and the existence of EDI require a more flexible electronic business
1
The needs of businesses, on which the ebXML Technical Architecture v 1.04 is based, are described in
the ebXML Requirements Document v 1.06 at http://www.ebxml.org.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 4 of 53
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
architecture that maintains a technology-neutral perspective where possible. This
eBTWG architecture incorporates the use of several UN/CEFACT electronic business
initiatives in addition to that of XML.
153
3.2 Requirements
154
155
156
157
158
159
The work of the UN/CEFACT eBTWG Architecture team is governed by the processes
adopted and approved by eBTWG. Accordingly, the architecture group has defined a set
of requirements that are available at http://www.ebtwg.org. This architecture addresses
requirements specified in the ebXML Requirements Document v 1.06 (www.ebxml.org).
Other requirements are noted herein. The architecture shall use UMM ontology to
describe its elements.
160
3.3 Caveats and Assumptions
161
162
163
164
165
166
167
168
169
170
171
This specification is designed to provide a high level overview of the UN/CEFACT
eBTWG electronic business architecture, and as such, does not provide the level of detail
required to build Applications, eBusiness components, and/or related services. Please
refer to each of the respective specifications for more detail.
172
173
3.4 Design Conventions for UN/CEFACT eBTWG Electronic Business
Specifications
174
175
176
In order to facilitate a consistent capitalization and naming convention across
specifications designed to use this Architecture, "Upper Camel Case" (UCC) and "Lower
Camel Case" (LCC) Capitalization styles SHOULD be used. UCC style capitalizes the
This architecture SHALL use modeling techniques described in the UN/CEFACT
Modeling Methodology (UMM). Modeling is the basis for the business process areas of
the architecture.
The UN/CEFACT eBTWG architecture attempts to define functional requirements and
component interfaces in a more precise manner than that described in the ebXML
Technical Architecture v 1.04.
This Architecture defines the different perspectives of electronic business conforming to
the four phases of Implementation, Design, Discovery and Runtime. Because this
Architecture is modular, this document notes the minimal functional requirements,
constraints and interfaces for each component.
The normal process for fully developing a UN/CEFACT Specification includes a full
implementation of the subject of the specification. The eBTWG Steering Committee
unanimously agreed that implementations provided by individual project teams would be
sufficient to meet this requirement without an independent implementation of the
architecture specification;therefore, no such implementation was delivered as part of the
approval process for this document.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 5 of 53
177
178
179
180
181
182
183
184
185
186
first character of each word and compounds the name. LCC style capitalizes the first
character of each word except the first word.
187
4.0 Overview
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
Some of the key feature capabilities of this architecture are:
1) Any XML DTD, XML Schema and XML instance documents SHOULD have the
effect of producing XML instance documents such that:










Element names SHALL be in UCC convention (example:
<UpperCamelCaseElement/>).
Attribute names SHALL be in LCC convention (example:
<UpperCamelCaseElement lowerCamelCaseAttribute="Whatever"/>).
Platform-independence.
Event driven Architecture.
Facilitation of multiple concurrent implementations.
Component based architecture allowing eBusiness components to be added,
deleted or modified.
Allows proprietary protocol support, including custom extensions for industry
standards. This refers to, but is not constrained by, electronic message payloads.
Custom workflow, information and syntax definitions are allowed in support of
unique business rules and requirements, as may be defined by users.
Incremental phased implementation.
Business to business interoperability.
Figure 1 (below) shows high-level relationships between components of this architecture.
The model is provided as a description of components, processes and the necessary
relationships for facilitation of the Requirements as described in Section 3.2.
By using this model, readers are provided with an overview of the processes and steps
that MAY be required to configure and deploy eBusiness Applications and supporting
architecture components.
Figure 1 introduces the following concepts and underlying architecture:
1. Standard methodologies and mechanisms for modeling a Business Process and
its’ associated information models. (UMM – UN/CEFACT Modeling Methodology
including proposed changes to N090).
2. A methodology to analyze associated information models (from item 1 above)
and discover abstractions of relevant information for globally reusable
components (Core Components).
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 6 of 53
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
3. A standard methodology for converting artifacts derived from item 1 (above) to
specific syntaxes including, but not limited to, XML and EDI.
4. A mechanism for the capture and storage of information about each participant
including:
 The Business Processes they support.
 The Business Service Interfaces they offer in support of the Business
Processes.
 The Business Messages that are exchanged between respective Business
Service Interfaces including Business Information Entities used in such
exchanges.
 Underlying Business Intent of Trading Partners
 Business Collaboration Rules and details of commitments which arise
from business activities.
 The technical configuration of the supported transport, security and
encoding protocols.
(Trading Partner Profile)
5. A standardized mechanism and methodology for registering the aforementioned
information so that it may be subsequently discovered and retrieved by using a
standardized communication protocol and query syntax (Registry).
6. A mechanism for describing the execution of a mutually agreed upon business
agreement which can be derived from information provided by item 4 (above).
(Trading Partner Agreement)
7. A standardized business Messaging Service framework that enables secure and
reliable exchange of electronic messages.
The following required concepts and components are specifically associated with the
Business Information described above:
1. A mechanism for the capture of context rules, and a format for declaring Business
Context (Context Declaration) in a syntax that may be interpreted by both
application and human actors.
2. A mechanism for representing contextually modified Core Components (Business
Information Entities).
3. A mechanism for declaring which Core Components or BIE’s will be used to
build a Business Message during the Design Phase (Core Component Assembly
Document).
4. A mechanism to express associations such as semantics between Core
Components and those components from other taxonomies including EDI and
XML vocabularies.
The following diagram covers the four phases expressed later within this architecture.
These include Implementation Phase, Design Phase, Discovery Phase and Run-time
Phase. The phases are discussed independently and in greater detail in section 5.0.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 7 of 53
265
266
267
268
269
270
271
272
273
274
275
There are five distinct views of the architecture that logically group activities and
components. They are expressed in the following diagram as Business Domain View
(BDV), Business Requirements View (BRV) – moving forward with Business entities as
a concept, Business Transaction View (BTV), Business Service View (BSV) and one
technical/implementation view- the Implementation Functional View (IFV). These five
views are aligned with UMM.
[EDITORS NOTE: Change Diagram –
- “Message” to “Payload”
- “UMM” is on top of BDV – outside domain
- New revisable figure 1 to come from John Yunker]
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 8 of 53
UEB High-level Overview
276
277
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 9 of 53
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
The purpose of the diagram is to show the relationship of work products created using the
specifications to the workgroups described in Figure 1. The Business Domain View
(BDV) identifies the Common Business Processes that will be used by the Trading
Partners. In the BRV, Monitored Commitments are composed of related common
business processes (business collaborations) and Business Entity Types.
In the diagram above, UMM is used to model all aspects of real-world business objectives
and activities during the “Design Phase”. In this phase
Graphs of common business process (business collaborations), monitored commitments,
and business entities are modeled. The business models are used to construct two main
artifacts during the Runtime Phase – Business Process Schemas (BPS) and Assembly
Documents (ASDOC) (BPS and ASDOC are referenced by a Registry mechanism).
A BPSS is an XML expression of a business process instance that declares the
choreography of messages between two or more parties. It is derived by applying
consistent methodology converting the UML expression of a business process to an XML
expression. At a higher level, there is a Business Collaboration that governs the
execution of any BPSS instances. During the Design Phase, the business information is
bound to the BPSS instance by an Assembly Document, a container with instructions to
build the final business-message instance (PAYLOAD).
An Assembly Document may reference one or more Business Information Entities (BIE),
which are created from Core Components contextually adopted for use within specific
Business Processes. While BIE’s are Core Components that are context specific to
certain Business Processes, they may be further contextually constrained during a
subsequent part of the Design Phase when geographic and industry information become
apparent (during the CPA formation process). Like the BPS, the BIE may be referenced
from within a Registry.
During the Implementation Phase, trading partners create a Trading Partner Profile
Protocol document that captures all technical and eBusiness capabilities about the
particular trading partner. When the CPP document is created, it MAY be referenced via
a Registry system. The trading partner may enter into the Discovery Phase and locate the
CPP document of another Trading Partner from the Registry. Through the intersection
of two CPP documents, the Trading Partner MAY discover a business process that is
supported by both Trading Partners. By binding the BPS to two or more CPP
documents, the Trading Partner creates a Collaboration Protocol Agreement (CPA), a
service level agreement on how the two partners collaborate. This process creates a set of
Context rules that are specific to the business process within the realm of both trading
partners. Alternatively, a Trading Partner may derive the Business Context by designing
a Business Collaboration that is an intersection of the Trading Partners’ CPP document
and a profile of a Trading Partner that may be suitable for the collaboration.
By applying the Business Context to BIE’s or Core Components, a final context and
syntax specific representation of the Business Payload gets created for each businessmessage step (PAYLOAD) defined and referenced by the BPS. This final businessUN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 10 of 53
324
325
326
327
328
329
message metadata, constrains the structure of the final payload, yet still requires instance
data for each individual message. If the PAYLOAD is expressed in XML, the same rules
for converting UML to XML SHALL be applied to create the final PAYLOAD instance.
330
5.0 Phases
331
332
333
334
335
336
337
338
339
340
341
342
343
344
The following section describes in detail the phases of the architecture. These are only
intended to provide different views of this architecture. While there may be specific
dependencies between components of different phases, there is no underlying
requirement to complete the phases in any specific order. While in a particular phase,
users may deem necessary to switch to other phases to complete certain activities as
required.
345
5.1 Implementation Phase
At the point of definition of the final PAYLOAD, trading partners may enter into the
Runtime Phase whereby they exchange instances of messages with one another.
This architecture uses four phases – Implementation, Discovery, Design and Runtime.
The Design phase may be distilled into two logical views – UMM modeling of Business
Processes and Associated Information, using a metamodel, and the second, designing and
configuring specific Business Collaborations. The first Design stage creates a series of
standard artifacts, and the second yields artifacts that are specific to individual business
collaborations.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 11 of 53
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
During the implementation phase, Trading Partners become knowledgeable of the
UN/CEFACT and related ebXML Specifications. They acquire the necessary resources
to build a Registry Client Interface. [Implementation note: this may be done by
building it themselves or purchasing software]. In doing so, they acquire the
capabilities to query compliant Registries, which allows them to locate Business
Processes and/or Core Component. Each Business Process references associated
information manifested as an Assembly Document. The Assembly Document provides the
metadata for each Business Message Payload. The Assembly Documents are written as
XML files and are built using a special set of context specific Core Components called
Business Information Entities. Alternatively, a set of temporary, fixed payloads may be
adopted to jump start implementation. Such fixed payloads SHOULD be built using
UMM.
During the next steps of the Implementation Phase, Trading Partners make a decision to
support certain Business Processes and decide what protocol model to use to implement
that business process. They also need to configure their systems to support certain
communication, security and transport protocols. All the details of these supported
Business Processes and technical configuration details are captured in a document called
a Trading Partner Profile (see section 9 – “Trading Partner Profiles”).
The partners specialize these artifacts to their application by making certain optional
process transitions and information entities that were required optional, as well as
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 12 of 53
370
371
372
373
374
375
376
377
378
379
380
specifying additional elements or actions. (e.g. the last context that is applied is
“Organization A”)
As an alternative implementation scenario, a Trading Partner MAY decide to use their
own business processes, modeled using UMM (see “Design Time”).
In the last steps of the Implementation Phase, a Trading Partner may decide to use their
Registry Client Interface to have a compliant registry manage their Trading Partner
Profile.
381
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 13 of 53
382
5.2 Discovery Phase
383
384
385
386
387
388
The Discovery Phase covers all discovery and retrieval of information about other
Trading Partners from the Registry. It is important to distinguish between calls to the
Registry during this phase as opposed to those during the Implementation Phase to
discover infrastructure related resources.
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
A Trading Partner who has implemented a Registry Client Interface can now begin the
process of discovery and retrieval of other Trading Partners who have registered their
profiles with a Registry. One possible discovery method MAY be to request the Trading
Partner Profile of another Trading Partner. The information about where to locate the
Trading Partner Profile is located in the Registry Information Model (RIM).
The received Trading Partner Profile MAY contain references to business processes.
Such references SHALL be done by a Globally Unique Identifier (GUID) which can be
subsequently used by the first Trading Partner to query the Registry for a reference to the
Business Process Schema. Although a GUID reference is required, other reference
methods may be additionally used.
5.3 Design Phase
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 14 of 53
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
During the Design Phase, Trading Partners design and/or configure a Business
Collboration and its’ associated business information. This may involve the initial
creation of a new Business Process to the modification of an existing Business Process so
that it is contextually and syntax specific. It is likely that this phase will require several
round trips to the Registry. Any registry lookups constitute a reversion to the Discovery
Phase.
Some of the activities that may be undertaken during this phase include:
1.
2.
3.
4.
Designing Business Processes and their associated information models.
Modeling business collaborations, patterns and commitments.
Configuring business information so it is context specific.
Negotiating a Trading Partner Agreement by binding two or more Trading
Partner Profile documents and a BP together.
5. Working with XML or other specific syntax representations of eBusiness
Artifacts.
Artifacts that may be used during this phase include:
1.
2.
3.
4.
Business Process and Associated Information Models.
Context Rules Messages (XML declarations of contexts)
Trading Partner Profile instances.
Trading Partner Agreement instances.
The Business Process Information (BPI) Meta Model, as defined in UMM N090, is the
meta-model for both the Business Information Model and Business Process Model. These
two models will be produced during the design phase, using UMM and form together the
“Business Process & Associated Information Model”.
434
435
436
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 15 of 53
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
Business Information Model
The Business Information Model SHALL reference all meta-information associated with
a specific Business Process. The Business Information Model references Business
Entities, Business Information Entities, and Business Information Objects to accomplish
that task. A Business Entity is used in the business process models to represent a
business artifact. Business entities have states that are referenced in business process
start, end, success, fail and transition conditions.
A Business Information Entity (BIE) is a Core Component that is contextually specific to
a certain business process, although further contextual constraints may be imposed upon
it subsequent to when two Trading Partners create a Trading Partner Agreement
Document.
During the Design Phase, when a Business Process is modeled and designed, the
associated business information used SHOULD be from the Core Component Catalog.2
When the designer of the process uses a Core Component within a specific Business
Process, they MAY modify or constrain the Core Component specifically for that
Business Process. At that time, the Core Component becomes a Business Information
Entity.
Business Information Entities MAY be described using the same XML Schema as Core
Components, since their meta-information model is identical.
Assembly Documents show what information should be included in a specific
transactional step of a business process.
2
Also it is possible that through modeling new Components are discovered. Please see section on Core
Components.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 16 of 53
464
465
466
467
468
469
470
471
472
473
474
475
Business Process Model
The Business Process Model describes the Business Roles, Business Collaborations
(including the Business Roles used in each Business Collaboration) and any monitorable
commitments that are used or created from the Business Process. Each Business
Collaboration is a choreography of Business Transactions, where each Business
Transaction involves some Business Roles and one or more Business Payloads.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 17 of 53
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
The Business Collaboration is transformed into a Business Process Schema, which MAY
be stored in a Registry.
Trading Partner Agreement and Final Context Rules Generation
One of the most important aspects undertaken during the Design Phase is the generation
of a bilateral (or multilateral) Trading Partner Agreement. During this process, two or
more trading partners decide they want to enter into a Business Collaboration. During the
Design of their Business Collaboration, they generate a Trading Partner Agreement.
Several Contexts may not be known until the time that this agreement is generated
including geo-political, industrial and language constraints.
When the Trading Partner Agreement is generated, a refinement to the Business Context
may be generated. By applying the Business Context against the Assembly Document
(hence the BIE’s), the final business document metadata can be generated. The final
business document metadata MUST be bound to the Business Process before the Trading
Partner Agreement is agreed to by both parties. Once a Trading Partner Agreement is
finalized, no further modification of information requirements can be made.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 18 of 53
500
501
502
5.4 Runtime Phase
503
504
505
506
507
508
509
510
511
512
513
514
515
516
The Runtime Phase covers the execution of a Business Process Schema, governed by a
Trading Partner Agreement. During the RunTime Phase, ebXML Messages are being
exchanged between Trading Partners. These messages have already been defined during
the Design Phase and require no further modifications or constraints.
Some Runtime artifacts include:
-
Trading Partner Agreement Documents
Business Process Schemas
Business Message Payload Metadata
Messages Instances and associated Error messages.
BPS Guard condition messages.
Business Service Interfaces
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 19 of 53
517
518
519
520
521
522
523
524
525
526
527
528
529
530
Functional Service View: Run Time Phase
[Implementation Note: There is no Runtime access to the Registry. If it
becomes necessary to make calls to the Registry during the Runtime
Phase, this SHALL be considered as a reversion to the Discovery Phase.
Likewise, if it becomes necessary to re-design aspects of a Business
Collaboration and/or any related Business Information, it SHALL be
considered a reversion to the Design Phase.]
During the Runtime Phase, Message Payload instances are exchanged.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 20 of 53
531
532
533
534
535
536
537
538
5.4.1 Runtime Stack (Non-normative)
The Runtime Stack MAY have a minimal set of components that facilitate the
functionality of this Phase. The Runtime Stack Diagram is intended to aide developers
and implementers.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 21 of 53
539
540
541
542
543
544
545
546
An assumption exists for a well-defined API between each layer of the stack to keep the
implementation agnostic to underlying technology. This is a place where Web Services
may be implemented
547
Component Constraints
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
[Editors NOTE: Each of the subsequent sections is written to cover 4
very specific topics for each component grouping:
*.1 Introduction
This section should be 1-5 paragraphs to introduce the component.
should not contain any reasons why or implementation details
It
*.2 - Functional Requirements
This section must contain the minimal functional requirements of this
component in order that it allows the entire infrastructure to operate
as a cohesive unit and perform its intended and stated functions. This
section should be brief and concentrate on only those requirements
which are expressed as “MUST”, “SHALL” or “MAY” according to RFC 2119.
Include such things as:
syntax it must be expressed in
what the thing must accomplish
can there be multiple instances of the thing in the system
Think of both XML and EDI problems
*.3 - Interfaces
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 22 of 53
569
570
571
572
573
574
This section should deal with the interfaces that this component has to
other components and specify during which phase that interface exists.
(eg Runtime, Design time).
No implementation details.
575
6.0 Modeling Methodology
576
6.1 Introduction
577
578
579
580
581
582
583
584
585
586
587
Real-world business components must have counterparts in the electronic business
infrastructure in order for the UEB Infrastructure to be capable of facilitating all aspects
of business electronically. Modeling business-activities, captures all details of business
collaboration and the information associated with the collaborations. This section deals
primarily with Design and Implementation Phases of the UEB Architecture.
*.4 - Non Normative Implementation Details
This last section contains non-normative details.
The UEB Architecture breaks down all aspects of Business Collaborations into two subgroups, the Business Operational View (BOV) and the Functional Service View (FSV), as
per the Open-edi Reference Model, ISO/IEC 14662. The figure below shows this logical
sub-grouping.
B
U
S
I
N
E
S
S
T
R
A
N Viewed
as
S
A
C
T
I
O
N
S
588
589
590
591
592
593
Business Operational View
Comply with
Business aspects
of
business transactions
BOV RELATED
STANDARDS
Covered by
Interrelated
Functional Service View
Information technology
aspects of
business transactions
Comply with
FSV RELATED
STANDARDS
Covered by
The BOV addresses semantics of business data during transaction and associated data
interchanges. The BOV also also addresses the architecture for business transactions,
including operational conventions, agreements, arrangements, mutual obligations and
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 23 of 53
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
requirements. These items apply specifically to the business needs of Trading Partners
that are Actors within the infrastructure.
The BOV MAY be further decomposed into other modeling artifacts that include, but are
not limited to, Business Processes, Business Collaborations, Business Object Types
Library, Business Transactions and their related Business Information (documents) and
Business Commitments that are capable of being monitored. Analysis through the
modeling process identifies Business Process and Information Models that are likely
candidates for re-use and standardization. The UEB Architecture approach looks for
standard, reusable components at all levels in business process and information models
from which to further construct new models. This approach facilitates interoperability
through its reuse of well-understood models and sub-models.
The FSV addresses the supporting services meeting the mechanistic needs of this
architecture. The FSV focuses on the information technology aspects of functional
capabilities, Business Service Interfaces, Protocols and Messaging Services. This
includes, but is not limited to, capabilities for implementation, discovery, deployment and
runtime scenarios, user Interfaces, data transfer, infrastructure Interfaces, and protocols
for enabling interoperability of different vocabulary deployments from disparate
organizations.
Business Process and Information Modeling methodology SHALL be the UN/CEFACT
Modeling Methodology (UMM) that utilizes UML.
[EDITORS NOTE: Because there is no way to enforce the use of modelling
during the Runtime Phase, modelling can not be enforced as a
prerequisite for participation in a Business Collaboration governed by
this Architecture.]
Business Modeling, Requirements, Analysis and Design workflows are needed to
understand the business needs in order to produce business scenarios, business objects
and areas of business collaboration. The use and relationships of the methods, patterns
and model artifacts are defined within each workflow. The final deliverables of the
Modeling workflows are shown in the figure below.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 24 of 53
632
633
634
635
636
637
638
639
640
641
[EDITORS NOTE: Check with John Yunker]
Business Collaboration Knowledge is captured in the Core Library3. The Core Library
contains data and process definitions, including relationships and cross-references, as
expressed in business terminology that MAY be tied to an accepted industry
classification scheme or taxonomy. The Core Library is the bridge between the specific
3
Core Library: is BOV of the Core Component Library (CC) and Business Process Catalogue (BP-CAT).
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 25 of 53
642
643
644
645
646
647
648
649
650
651
652
653
654
655
business or industry language, and the knowledge expressed by the models in a more
generalized context neutral language.
656
6.2 Formal Functionality
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
Business Modeling Artifacts SHALL be capable of being discovered and shared by other
Actors within the infrastructure to facilitate reusability.
674
6.3 Interfaces
675
676
677
678
679
680
681
682
683
Modeling and modeling artifacts are used in the Implementation, Design and Discovery
Phases of the Architecture.
The first phase defines the requirements artifacts that describe the problem using Use
Case Diagrams and Descriptions. If Core Library entries are available from a Registry,
they will be utilized, otherwise new Core Library entries will be created and registered in
a Registry.
The second phase (analysis) creates activity and sequence diagrams (as defined in the
UN/CEFACT Modeling Methodology specification) describing the Business Processes.
Class Diagrams capture the associated information parcels (business documents). The
analysis phase reflects the business knowledge contained in the Core Library. The class
diagram is a free-structured data diagram. During this phase, Actors will have access to
artifacts in the Business Object Type Library.
The Models MUST be capable of being expressed in a single unified Syntax.
The Models SHALL contain all the information required to facilitate the Design and
Discovery Phases. This may include discovering relationships between processes and
information, retrieving associated items from a Registry. The Models MUST also
contain all the information needed by the Runtime Phase to execute a specific Business
Collaboration instance.
Multiple Actors within the system SHALL be capable of working on models
independently of each other yet must still be capable of understanding every model.
Modeling SHALL NOT be based on the premise that it will be used only in a manner that
is specific to one syntax at Runtime, such as XML or EDI, for the business payloads of
messages.
Modeling SHALL capture the semantics of all components of the architecture therefore it
has an implied interface to every other component within the architecture.
The resultant models SHALL be capable of Registry reference, therefore an implied
interface to the Registry exists.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 26 of 53
684
685
During the modeling process, modelers SHOULD have access to Core Components,
Business Information Objects and Business Information Entities.
686
6.4 Non Normative Implementation Details
687
688
689
690
691
692
693
694
695
696
697
698
Modeling should ideally be uncomplicated and presented in an easily human
understandable form.
699
700
7.0 Business Process, Collaborations, Commitments and
Schemas.
701
7.1 Introduction
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
The Business Process and Information Model consists of artifacts that capture details of
specific business scenarios using a consistent modeling methodology. The Business
Process and Information Models are used during the Design Phase, to build a Business
Collaboration Model.
Currently, modeling SHALL use the UMM (which utilizes UML), though conceivable
that this Architecture may be adopted and used with other standard modeling
methodologies.
Using a single modeling methodology will improve the quality of artifacts by ensuring
they are developed consistently.
Aligning the goals of two or more Trading Partners from a top-down perspective will
aide the alignment of other Business Collaboration activities.
A Business Collaboration Model describes in detail how Trading Partners assume roles,
relationships, and responsibilities, to facilitate interaction with other Trading Partners.
This interaction between roles takes place as a choreographed set of business
transactions. Each business transaction is expressed as an exchange of electronic Business
Documents and signals. Business Documents MAY be composed from re-useable
Business Information Entities (see “Relationships to Core Components Interfaces”
below).
The Business Collaboration Model is expressed as a special Runtime artifact called a
Business Process Schema (BPS) and MAY be stored in a Registry. Trading Partners may
bi-laterally establish the durations of Business Collaborations. In instances of longer
running Business Collaborations, certain commitments between two or more Trading
Partners MAY be monitored. Examples of such monitored commitments are as follows:
a) Collaboration patterns.
b) The states of a commitment.
c) Auditable logs of the transactions.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 27 of 53
724
725
726
Certain events may trigger new instances of a Business Process Schema to be executed.
Some of these events may be based on the results of monitoring commitments.
727
7.2 Formal Functionality
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
The information contained in the Business Process and Associated Information Model
(BPAIM) MUST be capable of being displayed in forms which will allow both humans
and applications access to the information.
757
7.3 Interfaces
758
759
760
761
762
763
764
765
The BPAIM SHALL be capable of being referenced from a Registry. Business Processes
MAY be registered in a Registry in order to accomplish discovery and retrieval.
To be capable of being executed during the Runtime Phase, a Business Process SHALL
be rendered in a syntax that may be parsed by an application.
BPS’s MUST be capable of carrying all the information required by the Runtime
execution engine. The BPS may contain, but is not limited to, the following items:





Information on the choreography for the exchange of transactions. (e.g. the
prescribed sequence of Message exchanges between two Trading Partners
executing that transaction.)
References to the information required for the construction of the Business
Document Payloads (possibly DTD’s or Schemas).
Definition of the roles for each participant in a Business Process.
Definition of the Roles allowable within the Business Collaboration and
responsibilities and constraints for assuming each Role.
All the information necessary to build or constrain error and exception handling.
A Business Process:


Provides contextual drivers for constraining Core Components during the Design
Phase (though not all).
Provides the framework for establishing CPAs.
Relationship to Core Components
At Design Time, a Business Process Schema instance SHOULD specify the constraints
for exchanging business data with other Trading Partners. The business information
MAY be comprised of components of the ebXML Core Library. A Business Process
document SHALL reference the Core Components directly or indirectly via an Assembly
Document.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 28 of 53
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
At Runtime, a BPS SHALL fully constrain the Business Message Payload for each step
of executing the Business Collaboration.
The mechanism for interfacing with the Core Components and Core Library SHALL
vary depending upon the type of syntax used. The two primary candidates for syntx are
EDI and XML.
Relationship to a Registry System
A Business Process and Associated Information Model SHALL be capable of being
referenced through a Registry query.
Relationship to Trading Partner Profile and Trading Partner Agreement
A Trading Partner Profile instance defines that partner’s functional and technical
capability to support zero, one, or more Business Process Schemas and one or more roles
in each process.
The agreement between two Trading Partners defines the actual commitments under
which the two partners will conduct Business Collaborations. This includes a reference
to the actual Business Process Schema(s) they have agreed to execute. At the time a
Trading Partner Agreement is finalized, the Business Message Payloads must also be
agreed upon and static (not subject to change).
A BPS document contains a number of parameters to configure the Business
Collaboration. The values of these parameters SHALL be considered to be default values
or recommendations. When a Trading Partner Agreement is created, the Trading
Partners MAY decide to accept the default parameters in the BPS or they MAY agree on
values of these parameters that better reflect their needs. At Runtime, parameters
specified in the Trading Partner Agreement MAY assume precedence over choices
specified in the referenced BPS document. For more details on this, please see the nonnormative implementation section of the Trading Partner Agreements herein.
The BPS SHALL be capable of being referenced from the Trading Partner Agreement
and/or Trading Partner Profile by way of an identifier that is:
a) Globally unique
b) Includes a reference to which Registry can provide the
correct Metadata about the BPS
Relationship to Messaging
The Business Process Schema will govern choreography of business messages and
signals. The ebXML Message Service Specification, one of the possible messaging
specifications that may be used within this Architecture, provides the infrastructure for
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 29 of 53
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
message / signal identification, typing, and integrity; as well as placing any one message
in sequence with respect to other messages in the choreography.
827
7.4 Non Normative Implementation Details
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
During the Design Phase, a BPS instance SHALL be capable of referencing the business
information in a way that it is uniquely identifiable, to aide in the Discovery Phase. The
reference may be either direct or indirectly available via the associated Assembly
Document.
A BPS MUST contain all the information required to govern the choreography of
messages necessary to execute a specific Business Collaboration.
A BPS SHALL contain information for error and exception handling routines that MAY
occur during the execution of a Business Collaboration.
A BPS, in conjunction with a Trading Partner Agreement, MUST be capable of relaying
technical configuration details to the messaging engine (ie . – security details, time outs,
etc.).
The Business Process Schema execution engine MUST be capable of receiving signals
from the messaging engine at Runtime that will relay information about the state of a
given Business Collaboration instance as requirements dictate.
The type of reference used by the Trading Partner Profile and Trading Partner
Agreement documents to locate the Registry containing the metadata necessary to retrieve
a BPS MAY be accomplished by use of a Globally Unique Identifier(GUID). The
Globally Unique Identifier SHOULD contain three items:
1. The URI for the Registry
2. An Identifier which is unique within that Registry
3. The protocol used to query the Registry (It is recommended that the OASIS
ebXML Registry Services Specification(RSS) and Registry Information Model are
used; additionally, it is suggested that the RSS be used in conjunction with a
standardized registry transport layer protocol, such as the ebXML Messaging
Handler Service (MHS) specification.)
BCP MAY provide the specification of business dialogues that are defined in compliance
to UN/CEFACT UMM N090R10.
There are no formal requirements to mandate the use of a modeling language to compose
new Business Collaborations; however, if a modeling language is used to develop
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 30 of 53
855
856
857
858
859
860
861
862
Business Collaborations, it SHALL be the UN/CEFACT Modeling Methodology (UMM)
(which is dependant upon the Unified Modeling Language (UML)). This mandate ensures
that a single, consistent modeling methodology is used to create new Business
Collaborations. One of the benefits to using a single consistent modeling methodology is
model comparison to avoid duplication of existing Business Collaborations.
863
8.0 Core Components
864
8.1 Introduction
865
866
867
868
869
870
871
872
873
874
875
876
A Core Component (CC) is a Design Phase artifact. Each Basic Core Component is a
semantic atomic building block that is used as a basis to constructing electronic business
messages. The Core Component captures information about real-world business
concepts. The Core Component is meant to be a reusable object for electronic business.
In order to achieve reusability, a Core Component is abstracted to a context-neutral level.
The deliverables of the UN/CEFACT eBTWG Business Process groups MAY be
considered candidates that meet the needs of this architecture.
The Core Component MAY be modified or constrained for use within a particular
Business Collaboration instance. During the Design Phase only, a Business Context
MAY be used to constrain the Core Component to a specificadaptation of the Business
Collaboration. Once constrained or modified by a Business Context, it is called a
Business Information Entity (BIE).
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 31 of 53
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
An initial set of Core Components, grouped together as a Core Component Library, are
required to enable the functionality of the Design Phase. Users may adopt and/or extend
components from that Core Component Library.
There are two basic types of Core Components:
1. Basic Component – A simple, singular Core Component that has a non-divisible
semantic meaning. (NOTE: the term used by the UN/CEFACT teams to describe
this type of Core Component is “Basic Core Component”)
2. Aggregate Core Component – A collective or packaged Core Component.
Packaging of Core Component concepts MAY occur in the Design Phase.
A Core Component MAY be bound to a specific Business Collaboration during the
Design Phase.
NOTE: There are specific Context Drivers or categories for which contexts may
be used to constrain or modify Core Components. These may evolve over time.
To view the latest Context Drivers, please review the work of the UN/CEFACT
Core Components groups.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 32 of 53
900
901
902
903
The table below gives a brief introduction to how a Core Component may be specifically
constrained for inclusion in a specific Business Collaboration. It is meant to be an
example only.
Original Core
Component
Monetary. Amount
Address
904
905
906
907
908
909
910
911
912
913
Used in
Business Collaboration
Could Become BIE
Invoice Monetary. Amount
“ShipFrom” Address Element
A BIE may be further modified prior to multiple Trading Partners designing a Trading
Partner Agreement. The Business Context is finalized when a specific Business Process
is bound to a Trading Partner Agreement;for example, it would not be possible to know
the geo-political Context Driver until the geographical information is available from both
Trading Partner Profiles. Once a Trading Partner Agreement has been finalized, it is not
possible to modify or constrain the Business Message Payloads any further, without
changing the Trading Partner Agreement.
914
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 33 of 53
915
916
917
918
919
920
921
922
923
924
925
At Trading Partner Agreement design time, Business Context Driver information MAY
be discovered from the Trading Partner Profiles or the Registry Information Model data.
Design rules SHALL be used to represent the BIE (a modeling artifact) into a desired
syntax, such as extensible Markup Language (XML) or Electronic Data Interchange
(EDI).
One or more BIE’s SHALL be used for designing a Business Message Payload or syntax
specialized message. BIE’s SHALL NOT be bound to a specific syntax.
926
8.2 Functional Requirements
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
Core Components + BIEs + Business Contexts SHALL be storable and retrievable using
a Registry mechanism.]
A Core Component or BIE, SHALL be capable of providing semantic information about
itself.
It SHALL be possible to construct an Aggregate Core Component using other Core
Components, which MAY include Aggregated and Basic Core Components. Aggregate
Core Components SHALL contain references to the components they are composed of.
The same is also true for Business Information Entities.
A Core Component, via the Registry Information Model, SHALL be capable of
associating BIE’s that MAY be used based on specific Business Contexts. This is not a
requirement of the Core Component directly.
A BIE or aggregate BIE SHALL reference the Core Component or aggregates that were
used as the basis for creating the BIE.
A BIE SHALL be capable of containing references that indicate semantic equivalence to
elements of other taxonomies.
Either directly or via the Registry Information Model, a Core Component or BIE
SHOULD contain a reference to where the artifact physically resides, who maintains it
and who may be contacted to suggest modifications or constraints (Data Steward).
1. The BIE MAY contain references on how it may be expressed in a specific
syntax (eg. EDI or XML). This may be done by using an assembly schema an artifact which constrains how the component may be physically
represented in a specific syntax such as XML.
A + CC too BIE SHOULD be capable of expressing enumerated lists or impose datatype
constraints for values. These would be details of constraints on values allowable for each
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 34 of 53
959
960
961
962
963
964
965
966
967
968
969
970
971
972
component. An example of this, may be to allow only integer values for components
which represent numerical data.
973
8.3 Interfaces to other Components
974
975
976
977
978
979
980
981
982
983
984
985
986
A Core Component or Business Information Entity MAY be referenced indirectly or
directly from a Business Collaboration. This MAY be done via an intermediary
document (Assembly Document) that describes how to construct a Business Message
Payload during the Design Phase. The Assembly Document MAY specify a single, or
group of Core Components, or Business Information Entities (required or optional) as
part of a Business Message Payload instance.
987
8.4 Implementation Details (Non Normative)
Core Components and BIE’s MUST contain information about their Core Component
Type.
Core Components MAY be associated with other artifacts during all phases described
within this architecture. It is RECOMMENDED that these relationships are stored in the
Registry Information Model.

Core Components + BIEs SHALL be capable of being realized in XML syntax.
This does not mean that instances may only be in XML Format.
A Core Component SHALL be able to be uniquely identified. + BIE + Business Context.
A Core Component or Business Information Entity SHALL interface with a Registry
mechanism by way of being storable, searchable and retrievable in such a mechanism.
The Business Message Payload Metadata MUST have a way to reference each Core
Component or BIE used within instances of the Business Message Payload.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 35 of 53
988
989
990
991
992
993
994
The Core Component work being done by the Core Component related UN/CEFACT
995
eBTWG groups is a RECOMMENDED candidate for use within this Architecture.
996
997
UN/CEFACT Core Component team SHOULD deliver a starter set of Core Components
998
for Trading Partners to use within this Architecture. This starter set SHOULD be
999
developed using a normalized process of discovery and analysis. In order to continually
1000
develop the Core Component Library, the discovery and analysis for Core Components
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 36 of 53
1001
1002
1003
1004
1005
1006
1007
1008
1009
SHALL include the capability to define a new Core Component (Basic or Aggregate).
One of the goals of the discovery and analysis process SHOULD be to avoid duplication
of existing Core Components.
1010
9.0 Trading Partner Profiles and Agreements
1011
9.1 Introduction
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
To facilitate the process of conducting eBusiness, potential Trading Partners need a
mechanism to publish information about the Business Processes they support along with
specific technology implementation detailing their capabilities. This is accomplished
through the use of a Trading Partner Profile. The Trading Partner Profile is a document
that allows a Trading Partner to express their supported Business Processes and Business
Service Interfaces in a standardized manner.
1033
9.2 Trading Partner Profile and Agreement Formal Functionality
The Registry Information Model classification schemes SHOULD be used to express how
a Core Component or Business Information Entity is part of a lexicon or Core Component
Library.
A special business agreement called a Trading Partner Agreement, is a document derived
from the intersection of two or more Trading Partner Profiles. The Trading Partner
Agreement serves as a formal agreement between two or more Trading Partners wishing
to enter into a Business Collaboration.
An ebXML Collaboration Protocol Agreement (CPA) is a technical agreement and is not
intended to capture any legal agreement between two Trading Partners however, entering
into a CPA MAY have legal implications. Trading Partners MAY rely on external
documents to capture the legal details of their Business Collaborations. Capturing the
details of any legal agreements between Trading Partners is outside the scope of this
architecture.
A Trading Partner MAY have one or more Trading Partner Agreements.
10341. A Trading Partner Profiles and Trading Partner Agreements SHALL be capable of
1035
describing the specific technical capabilities that a Trading Partner supports. This
1036
SHALL include, but is not limited to the following:
1037
1038
a) The details of their Business Service Interface that include details of one
1039
or more communication endpoints (URI, Port information, protocol and
1040
messaging format).
1041
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 37 of 53
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
b) Details of Security Protocols that the Trading Partner supports and
implementation information.
c) Information that points at technical error handling routines including how
the Trading Partner handles malformed messages, re-routing capabilities,
time-outs, and what constitutes an unrecoverable error.
The Trading Partner Profile MUST be capable of containing a list of Business Process
Schemas supported by the Trading Partner. The BPS instances SHALL be capable of
being referenced via a Unique Identifier. Additionally, the Trading Partner Profile and
Agreements SHOULD be capable of providing details of the physical location of each
Business Process Schema and the details of the protocols that may be used to retrieve a
copy of the Business Process Schema.
The Trading Partner Profile and Trading Partner Agreement SHALL be capable of
identifying the Roles that the Trading Partner is capable of, or will assume responsibility
of, for each Business Process Schema.
The Trading Partner Profiles and Agreements SHOULD contain a reference to
information, in a structured and known format that MAY be used to provide Business
Context information. This information MAY include the physical address of the Trading
Partner (used for the geo-political Context Driver).
Both Trading Partner Profiles and Trading Partner Agreements MAY provide
information for one or more physical contacts that may be reached via conventional
techniques (eg. telephone or email).
Business and industrial classifications for each trading partner and references to the
Classification Schemes used to classify the Trading Partner. This MAY be done via the
Registry and careful attention should be taken not to duplicate any information available
as Registry Information Model.
A Trading Partner Profile SHALL contain details of how a Trading Partner Agreement
is proposed, and engaged by other Trading Partners.
Both the Trading Partner Profile and Trading Partner Agreement MUST be capable of
providing a way to uniquely identify each Trading Partner.
The Trading Partner Profile definition SHALL provide for selection of choices in all
instances where there may be multiple selections (e.g. HTTP or SMTP transport). In
cases where multiple choices exist, a methodology SHALL have the capability to select
and bind localized configuration preferences to each BPSS instance.
9.3 Trading Partner Agreement Specific Formal Functionality
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 38 of 53
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
The Trading Partner Agreement MUST be capable of describing the specific technical
capabilities that two or more Trading Partners will support during the cycle of a
particular Business Collaboration.
A Trading Partner Agreement MUST be able to reference any long running
commitments that MUST be monitored during the course of the Business Collaboration.
The Trading Partner Agreement SHALL be able to reference the Trading Partner Profile
used by each Trading Partner as the basis for creating the Trading Partner Agreement.
A Trading Partner Agreement is meant to be a static artifact. If it becomes necessary to
change of modify a Trading Partner Agreement, both Trading Partners should enter into
a new Trading Partner Agreement.
A Trading Partner Agreement MAY be referenced from a Registry however it SHALL
NOT be prescribed.
1103
9.4 Trading Partner Profile and Agreement Interfaces
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
Interface to Business Process
A Trading Partner Profile SHALL be capable of referencing and uniquely identifying
one or more Business Processes supported by the Trading Partner. The Trading Partner
Profile SHALL reference the roles within a Business Process that the user is capable of
assuming;examples of which include, a role could be the notion of a “Seller” and
“Buyer” within a “Purchasing” Business Process. There SHALL be a mechanism to
reference the role descriptions in the Trading Partner Profiles and Agreements with the
roles described in the Business Process Schema.
Both Trading Partner Profiles and Agreements SHALL be capable of being stored and
retrieved from a Registry hence an implied relationship with a Registry. Both Trading
Partner Profiles and Trading Partner Agreements SHALL be capable of pointing to other
artifacts via a reference to a Registry Managed Object.
A Trading Partner Agreement MUST contain information describing binding details that
are used to send and receive Business Message Payloads.
A Trading Partner Agreement governs the Business Service Interface used by a Trading
Partner by constraining a set of parameters to a subset agreed to by all Trading Partners,
who will then execute such an agreement.
Trading Partner Agreement’s have Interfaces to Trading Partner Profile’s in that the
profile is derived through a process of constraining the Trading Partners capabilities into
what the Trading Partner agree they “will” do. The physical detail of this interface
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 39 of 53
1129
1130
SHALL be via a mechanism to uniquely identify the Trading Partner Profile used as the
basis for creation of the Trading Partner Agreement.
1131
9.5 Non-Normative Implementation Details.
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
The OASIS CPP-A Technical Committees’ working specification(s) is the
RECOMMENDED candidate to meet the needs of this Architecture. The terminology
used to describe a Trading Partner Profile is “Collaborative Protocol Profile” or CPP
and the Trading Partner Agreement is called a “Collaborative Protocol Agreement” or
CPA.
1151
10.0 Registry
1152
10.1 Introduction
1153
1154
1155
1156
1157
1158
1159
The UEB Architecture makes extensive use of Registry systems. The Registry provides a
set of services that enable the managing and sharing of information. A Registry is a
component that maintains an interface to metadata for a registered item (called a
“RegistryObject”). Access to a Registry is provided through Interfaces (APIs) exposed by
Registry Services.
The process of formation, proposing and acceptance of a Trading Partner Agreement
SHOULD be formally described and constrained by normalizing rules for negotiations
and choosing options in instances where multiple choices are available.
Each Trading Partner SHOULD register their CPP(s) in a Registry Service, thus
providing a means for allowing other Trading Partners to discover details about them.
A Trading Partner Agreement is negotiated after the Discovery and Retrieval Phase and
is essentially a technical agreement of the Messaging Services and Business Process
Schema related information that two or more Trading Partners agree to use for
exchanging business information. If any parameters contained within an accepted
Trading Partner Agreement change after the agreement has been executed, a new
Agreement SHOULD be negotiated between Trading Partners.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 40 of 53
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
The Interfaces described by this architecture can generally be broken down into three
general categories:
1. The Object Manager – this Interface is a series of defined methods that allow
registry users to manage objects referenced by the Registry. This MAY include
classifying objects, declaring associations, updating, superceding or deleting
references to managed objects, and modifying any metadata associated with a
specific managed object through that objects lifecycle.
Note: A Registry Object’s location is not tightly bound to the Registry itself. A
Registry Object may physically reside in a separate location.
2. The Object Query Manager – this interface is a series of defined methods and
return types for querying the Registry metadata about Managed Objects.
3. The Administration Manager – this is an optional, RECOMMENDED collection
of methods that SHOULD BE defined for managing registry properties such as
permissions of Registry Users. It is generally reserved for a special type of
registry actor called a Registry Administrator or “RA”.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 41 of 53
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
The Registry is not tightly coupled to any specific Registry Client. Although Registries
may use any number of communication techniques and extend their functionality to
include other interfaces other than those defined herein, Registries must meet the minimal
functional requirements described herein in order to fit within this architecture.
The basic architecture of the Registry and Registry Client is shown below.
A Registry Client is a specialized software component used to send messages to, and
receive responses from. registries using known Registry Services. For purposes of
interoperability, registries operating within a specific infrastructure SHOULD use the
same set of Registry Services.
A Repository is a location where Registry Objects physically reside. A Registry may use
an internal Repository for this location, but no such relationship is mandated by this
specification.
Implementation Note: Generally, having a Repository and Registry on the same physical
server may impose limits of scalability. Implementers are strongly urged to consider the
maximum number of concurrent users when designing such systems.
1206
10.2 Formal Functionality
1207
1208
1209
1210
1211
1212
1213
A Registry SHALL be capable of referencing Registry Items expressed in syntax using
both multi-byte and single-byte character sets.
A Registry SHALL use a system for uniquely identifying all Registry Objects.
A Registry Object Query Manger Interface SHALL return either zero or one positive
matches in response to a contextual query for a unique identifier value. In such cases
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 42 of 53
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
where two or more positive results are displayed for such queries, an error message
MUST be reported to the Registry Authority.
A Registry MUST store persistent metadata about each Managed Object through that
managed objects’ lifecycle. This metadata is referred to as the Registry Information
Model (RIM).
The Registry Information Model SHALL be structured to allow information associations
that identify, name, description, administrative and access status, persistence and
mutability, classify, declare file representation type, and identify the submitting and
responsible organizations for each Registry Object.
A Registry SHALL allow one or more classification schemes to be used to classify each
registry object in line with the requirements of registry users.
A Registry SHALL allow one or more associations to be made between Registry Objects.
Such Associations SHALL be able to reference Registry Objects in other Registry
systems that adhere to this specification. Associations SHALL be capable of being bidirectional.
The Registry Interfaces serve as an application-to-registry access mechanism. This
introduces the concept of a Registry Client, a specialized application that is capable of
sending Messages that conform to the Registries API.
Human-to-registry interactions SHALL be built as a layer over the Registry Client (e.g. a
Web browser) using the standardized Registry Services. If another Human to Registry
communication mechanism is implemented (eg. Registry Service and Transport
mechanism) it shall exist in addition to and not as a replacement to the standardized
Registry Services.
The Registry Interface SHALL be designed to be independent of the underlying network
protocol stack (e.g. HTTP/SMTP over TCP/IP). Specific instructions on how to interact
with the Registry Interface MAY be contained in the payload of a Business Message.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 43 of 53
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
All Registries that conform to this architecture specification SHALL support one
standard communication protocol. This MAY be supplemented with other
communication protocols as long as the standard protocol is present.
Note – please see non normative implementation details (section 10.4) for
RECOMMENDED communication protocol.
Registry Services functionality SHALL also include:
 A standardized set of messages between the Registry and Registry Clients to
describe all messages and returns types, including errors, that occur between the
Registry Interfaces and the Registry Clients.
 A set of standard functional processes involving the Registry and Registry Clients.
 A set of error responses and conditions with remedial actions.
 A standardized error management system for recovering from errors.
Any of the Registry Interfaces used within this Architecture MAY generate error
messages in response to certain events. A Registry Client SHOULD be capable of
receiving and interpreting those error messages.
Registry Services MAY exist to create, modify, and delete Registry Objects and their
metadata.
Appropriate security protocols SHALL be available to offer authentication and protection
for the Registry access.
No methods MAY be part of a Registry Interface that are capable of any of the following:
a. Results in returns that are so large that it could result in a denial of service type
attack;
b. May use a large percentage of Registry Services for processing that the end effect
is rendering the Registry unavailable to other Registry Clients;
c. That may result in unsuspecting users waiting unreasonably long times for
network conveyance of the Return message.
It is up to individual Registry Operators to decide what constitutes “unreasonable” for
interpretation of the above.
Unique Identifiers (UIDs) SHALL be assigned to all items within an ebXML Registry
System. UID keys are REQUIRED references for all Registry content. Universally
Unique Identifiers (UUIDs) MAY be used in conjunction with a Registries URI to ensure
that Registry entries are truly globally unique, and thus when systems query a Registry
for a UUID, one and only one result SHALL be retrieved.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 44 of 53
1296
1297
1298
1299
1300
Components in ebXML MUST facilitate multilingual support. A UID reference is
particularly important here as it provides a language neutral reference mechanism. To
enable multilingual support, the ebXML specification SHALL be compliant with
Unicode and ISO/IEC 10646 for character set and UTF-8 or UTF-16 for character
encoding.
1301
10.3 Interfaces
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
Messaging:
1322
10.4 Non Normative Implementation Details
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
To facilitate the discovery process, browse and drill down queries MAY be used for
human interactions with a Registry (e.g. via a Web browser). A user SHOULD be able to
browse and traverse the content based on the available Registry classification schemes.
The query syntax used by the Registry access mechanisms is independent of the physical
implementation of the backend system.
It is RECOMMENDED that a Messaging Service Specification that meets the
requirements of the Messaging Service prescribed in section 11 herein, MAY serve as the
default transport mechanism for all communication into and out of the Registry.
Business Process:
Business Processes are published and retrieved via Registry Services.
Core Components:
Core Components are published and retrieved via Registry Services.
Any item with metadata: XML elements provide standard metadata about the item being
managed through Registry Services. Since this Architecture relies on distributed
Registries, each Registry MAY interact with and cross-reference another Registry.
The work of the ebXML Registry group [insert normative reference here] is HIGHLY
RECOMMENDED for use within this Architecture. That work has been specifically
designed for meeting the requirements of this architecture.
The work of UDDI [insert normative reference here] SHOULD be examined with a
perspective towards being used for the functionality described herein.
A Registry MAY support multiple concurrent classification schemes to meet the needs of
businesses.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 45 of 53
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
Registry Items and their metadata MAY also be addressable as XML based URI
references using only HTTP for direct access.
1353
11.0 Messaging
1354
11.1 Introduction
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
The Message Service mechanism provides a standard way to exchange business
Messages among Trading Partners. The Messaging Service MUST provide a reliable
means to exchange business Messages without relying on proprietary technologies and
solutions. A Message contains structures for a Message Header (necessary for routing
and delivery) and a Payload section.
Examples of extended Registry Services functionality may be deferred to a subsequent
phase of the ebXML initiative. This includes, but is not limited to transformation
services, workflow services, quality assurance services and extended security
mechanisms.
A Registry Service MAY have multiple deployment models as long as the Registry
Interfaces are compliant with this architecture.
The Business Process and Information Meta Model for an ebXML Registry Service may
be an extension of the existing OASIS Registry/Repository Technical Specification,
specifically tailored for the storage and retrieval of business information, whereas the
OASIS model is a superset designed for handling extended and generic information
content.
The Messaging Service is conceptually broken down into three parts: (1) an abstract
Service Interface, (2) functions provided by the Messaging Service Layer, and (3) the
mapping to underlying transport service(s). The relation of the abstract Interface,
Messaging Service Layer, and transport service(s) are shown in Figure 15 below.
Abstract ebXML Messaging Service Interface
EbXML Messaging Service Layer maps
the abstract interface to the underlying
transport service
Transport Service(s)
1366
1367
1368
1369
Figure 15 - Messaging Service Logical Breakdown
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 46 of 53
1370
1371
1372
1373
1374
1375
The following diagram depicts a logical arrangement of the functional modules that exist
within the ebXML Messaging Services architecture. These modules are arranged in a
manner to indicate their inter-relationships and dependencies. This architecture diagram
illustrates the flexibility of the ebXML Messaging Service, reflecting the broad spectrum
of services and functionality that may be implemented in an ebXML system.
ebXML Applications
Messaging Service Interface
Messaging Service
Authentication, authorization and
repudiation services
Header Processing
Encryption, Digital Signature
Message Packaging Module
Delivery Module
Send/Receive
Transport Mapping and Binding
HTTP
1376
1377
1378
1379
SMTP
IIOP
FTP
…
Figure 16 - The Messaging Service Architecture
11.2 Formal Functionality
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 47 of 53
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
The ebXML Messaging Service provides a secure, consistent and reliable mechanism to
exchange ebXML Messages between users of the ebXML infrastructure over various
transport Protocols (possible examples include SMTP, HTTP/S, FTP, etc.).
1416
11.3 Interfaces
1417
1418
1419
1420
1421
1422
1423
The ebXML Messaging Service provides ebXML with an abstract Interface whose
functions, at an abstract level, include:
The ebXML Messaging Service prescribes formats for all Messages between distributed
ebXML Components including Registry mechanisms and compliant user Applications.
The ebXML Messaging Service does not place any restrictions on the content of the
payload.
The ebXML Messaging Service supports simplex (one-way) and request/response (either
synchronous or asynchronous) Message exchanges.
The ebXML Messaging Service supports sequencing of payloads in instances where
multiple payloads or multiple Messages are exchanged between Trading Partners.
The ebXML Messaging Service Layer enforces the "rules of engagement" as defined by
two Trading Partners in a Collaboration Protocol Agreement (including, but not limited
to security and Business Process functions related to Message delivery). The
Collaboration Protocol Agreement defines the acceptable behavior by which each
Trading Partner agrees to abide. The definition of these ground rules can take many
forms including formal Collaboration Protocol Agreements, interactive agreements
established at the time a business transaction occurs (e.g. buying a book online), or other
forms of agreement. There are Messaging Service Layer functions that enforce these
ground rules. Any violation of the ground rules result in an error condition, which is
reported using the appropriate means.
The ebXML Messaging Service performs all security related functions including:
 Identification
 Authentication (verification of identity)
 Authorization (access controls)
 Privacy (encryption)
 Integrity (message signing)
 Non-repudiation
 Logging



Send – send an ebXML Message – values for the parameters are derived from the
ebXML Message Headers.
Receive – indicates willingness to receive an ebXML Message.
Notify – provides notification of expected and unexpected events.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 48 of 53
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438

Inquire – provides a method of querying the status of the particular ebXML
Message interchange.
The ebXML Messaging Service SHALL interface with internal systems including:
 Routing of received Messages to internal systems
 Error notification
The ebXML Messaging Service SHALL help facilitate the Interface to an ebXML
Registry.
11.4 Non-Normative Implementation Details
ebXML Message Structure and Packaging
Figure 17 below illustrates the logical structure of an ebXML Message.
Transport Envelope (SMTP, HTTP, etc.)
ebXML Message Envelope (MIME multipart/related)
ebXML Header Envelope
ebXML
Header
Container
ebXML Header Document
Manifest
Header
ebXML Payload Envelope
ebXML
Payload
Container
1439
1440
1441
1442
Payload Document(s)
Figure 17 - ebXML Message Structure
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 49 of 53
1443
1444
1445
1446
1447
1448
1449
1450
An ebXML Message consists of an optional transport Protocol specific outer
Communication Protocol Envelope and a Protocol independent ebXML Message
Envelope. The ebXML Message Envelope is packaged using the MIME multipart/related
content type. MIME is used as a packaging solution because of the diverse nature of
information exchanged between Partners in eBusiness environments. For example, a
complex Business Transaction between two or more Trading Partners might require a
payload that contains an array of business documents (XML or other document formats),
binary images, or other related Business Information.
1451
12. 0 References
1452
[EDITORS NOTE: Inquire to STC about reference section in template.]
1453
This section defines ...[used to outline more or all details of this specific specification].
1454
13 .0 Disclaimer
1455
1456
1457
1458
The views and specification expressed in this document are those of the authors and are
not necessarily those of their employers. The authors and their employers specifically
disclaim responsibility for any problems arising from correct or incorrect implementation
or use of this design.
1459
14.0 Contact Information
1460
eBTWG Chair - Klaus-Dieter Naujok, knaujok@home.com
1461
14.1 Project Team Membership
1462
1463
Project Team Leader - Duane Nickull, XML Global Technologies,
duane@xmlglobal.com
1464
Project Team Co-Leader - Marion Royal, GSA, marion.royal@gsa.gov
1465
1466
1467
Project Editor – Moshe Silverstein, iWay Software,
Moshe_Silverstein@iWaySoftware.com
1468
1469
1470
1471
1472
1473
1474
Project Team –Ted Osinski, UCC, tosinski@uc-council.org
Ho Beom Jang, KTNET, hbjang@ktnet.co.kr
Monica J. Martin, Certivo, mmartin@certivo.net
Aynur Unal, e2Open, aynur@2open.com
Kenji Itoh, JASTPRO, kenji.itoh@jastpro.or.jp
Jasmine Jang, KIEC, jasmine@kiec.or.kr
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 50 of 53
1475
1476
1477
1478
1479
1480
1481
1482
Kyle McNabb, Vignette
Art Krylovetski, Certivo
Hans H. Eriksen, Danish Standards Association, hhe@ds.dk
Per Hjartoy, Actius
John Yunker
Dave Welsch
Matt McKenzie, matt@xmlglobal.com
Doug Bunting, drb24@cornell.edu , dougb62@yahoo.com
1483
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 51 of 53
1484
Copyright Statement
1485
Copyright © [ebXML | UN/CEFACT] 2001. All Rights Reserved.
1486
1487
1488
1489
1490
1491
1492
1493
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or references to
[(ebXML, UN/CEFACT, or OASIS,) | UN/CEFACT,] except as required to translate it
into languages other than English.
1494
1495
The limited permissions granted above are perpetual and will not be revoked by [ebXML
| UN/CEFACT] or its successors or assigns.
1496
1497
1498
1499
1500
1501
1502
This document and the information contained herein is provided on an "AS IS" basis and
[ebXML | UN/CEFACT] DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 52 of 53
1503
1504
1505
1506
1507
1508
1509
1510
1511
Appendix “A”
UN/CEFACT ebTWG Project Teams and OASIS Technical Committees
relationships.
Figure 1 (below) shows high-level relationships between the project teams working on
components of this architecture. This model is provided to describe their relationships
that are necessary to facilitate the Working Requirements as described in this document.
1512
UN/CEFACT eBTWG Electronic Business Architecture Specification
Copyright © [ebXML | UN/CEFACT] 2002. All Rights Reserved.
Page 53 of 53