=Paper=
{{Paper
|id=Vol-404/paper-7
|storemode=property
|title=Business Documents in a Service Oriented Context
|pdfUrl=https://ceur-ws.org/Vol-404/Paper6.pdf
|volume=Vol-404
}}
==Business Documents in a Service Oriented Context==
https://ceur-ws.org/Vol-404/Paper6.pdf
Business documents in a service oriented context
∗
Philipp Liegl
Institute of Software Technology and Interactive Systems
Business Informatics Group
Favoritenstrasse 9-11/188
Vienna, Austria
liegl@big.tuwien.ac.at
ABSTRACT terprises have been replaced by loosely-coupled and service
In a SOA based inter-organizational business process differ- oriented ones. Service orientation allows for faster changes
ent business documents are exchanged in an agreed order in B2B processes and thus also in the exchanged business
between business partners. Although several standards for documents. The hard wired EDI approach is too inflexi-
the definition of a process choreography exist nowadays, the ble for these new ad-hoc business processes. Several ini-
precise and unambiguous definition of the exchanged busi- tiatives, mostly industry specific ones, have been found in
ness documents is still an open research task. However, if recent years - some with notable, others with almost no suc-
the business partners do not commonly agree on a business cess. Since almost all of these initiatives were focused on
document format, interoperability is unlikely to be achieved. a certain domain or industry, a broad cross-industry accep-
A solution can be provided by defining a UML profile, in- tance could not be reached. As part of the UN/CEFACT
tegrating concepts from UN/CEFACT’s Core Components (United Nations Center for Trade Facilitation and Electronic
standard and industry specific requirements and best prac- Business) initiative for document standardization the core
tices. The UML profile allows to define business document component [21] standard has been developed, consisting of
models on a conceptual level. These conceptual level models reusable building blocks for the definition of business docu-
can be used to exchange business document information be- ments. However, core components are a theoretical concept
tween software developers and more important to automat- and no integration into a modeling tool exists until today.
ically derive logical level models e.g. XML schema. These
logical level artifacts can be automatically deployed in IT In order to allow for a better understanding of the industry-
systems of a service oriented architecture. specific business document modeling requirements a precise
survey of the various business document standardization ef-
1. MOTIVATION forts is necessary. Thereby the specific advantages and dis-
With the introduction of Electronic Data Interchange (EDI) advantages in regard to a use in a service oriented context
initiatives the need for a standardization of the exchanged have to be examined. Using the results of the survey and the
information became apparent. One of the best known EDI concepts of the core component standardization, a common
standardization initiatives is the UN/EDIFACT [20] [1] stan- solution allowing for the integration into a UML modeling
dard. Typical EDI agreements involved a well defined set of tool has to be found. Eventually the business document
business partners collaborating with a predefined set of busi- modeler should be able to construct business documents on
ness documents over a longer time-frame. Thus adaptations a conceptual level with a UML modeling tool of choice. Fi-
of the exchanged business documents were rather rare and if nally another important question remains - how to uniquely
they occurred the changes were mostly minor ones. An early derive deployment artifacts from conceptual data models
and interesting survey on the determinants of EDI diffusion which may then be employed in a service oriented context
has been published in [16]. Since the first EDI initiatives in e.g. XML schema. Furthermore it must be examined how
the early sixties which were reserved for large companies and conceptual business document models can be integrated into
industries, the IT landscape has changed significantly. To- business process models.
day service oriented technologies enable small and medium
sized enterprises to participate in electronic collaborations
as well. The before rather hard-wired processes between en-
2. PROBLEM
If two businesses engage in an automated business process
∗2nd year PhD student at Vienna University of Technology two major agreements are necessary. First, the order of the
exchange of business documents has to be agreed upon -
the so called business choreography. Using the global busi-
ness document exchange choreography each business part-
ner can configure his own IT system. Second, the business
documents and their precise semantics have to be settled.
In figure 1 an example business process order from quote
between a buyer and a seller is shown. First the buyer re-
quests a quote from the seller and submits a purchase or-
der to the seller. The seller either replies with an order
acceptance or with an order rejection. In a service ori-
ented context the interfaces (WSDL) [26] and the messaging cess. Instead of exchanging e.g. XML schema definitions, a
(SOAP) [25] are well defined. However little or nothing is conceptual business document model is easier to understand
said about the actual workload being exchanged between the for the developers on each business partner’s side.
two companies.
To sum up, a new methodology for the definition of busi-
Buyer WSDL SSeller
ll WSDL ness documents is needed in particular to meet the needs of
Quote Request a service oriented context. A SOA context requires regular
Quote changes in the exchanged document structure and the auto-
matic derivation of deployment artifacts in order to quickly
Purchase Order meet the changed business document requirements.
Order Acceptance
/
/
Order Rejection
XOR
3. HYPOTHESIS
... ... In order to allow two companies to agree upon a common
document semantic a methodology for defining business doc-
/
/
uments is needed. UN/CEFACT’s Core Components [21] is
SOAP‐Message a methodology to uniquely define business documents. The
Header current core component version is 2.01 with the develop-
Body ment of 3.0 [24] currently going on. The development of
.... core components is backed up by the United Nations and can
therefore be seen as the most promising global approach for
business document standardization. However, several other
industry initiatives and standardization bodies have devel-
Figure 1: Business Documents in a SOA context oped business document standards as well. Nevertheless, the
different standards are largely incompatible to each other,
On the lower side of figure 1 an example SOAP message thus hampering a broad proliferation of business document
is shown. Whereas header and body of a SOAP message standardization.
are well defined, the actual document format carried in the
body remains undefined. However, in order to allow the two Hypothesis 1. It is necessary to find a common base be-
WSDL interfaces to be compliant the message types have to tween different industry specific requirements and the global
be defined as well. Standardization efforts in recent years core components initiative. Since core components are a
have brought up a multitude of different standards and ap- generic concept the different industry requirements can be
proaches for the definition of business data. Unfortunately reflected. However core components are a theoretical con-
the different standards have a set of shortcomings. cept and therefore no real integration into a modeling tool
is possible. Recent years have shown, that the Unified Mod-
First, the multiple initiatives being based on XML are mostly eling Language (UML) is becoming a very promising tech-
incompatible to each other. Since the different standards are nology for the modeling of structural and dynamic behavior.
not based on a common semantic base difficult mappings be- If the core components technology together with the identi-
tween different standards are necessary. However, data map- fied industry requirements could be integrated into a UML
pers are expensive to implement and inflexible to changes of modeling tool, the proliferation of the technology would be
the structure of the exchanged business documents. accelerated, thus leading to a broader acceptance. A UML
tool of choice could be used to model conceptual business
Second, a lot of the different standards aim at the inclusion document models. Therefore a solution for the integration
of every possible element in a business document. This re- of the core component concept into a UML modeling tool
sults in a strong overhead of a standard. Furthermore, such must be found [7].
an overhead makes a standard difficult to implement - in par-
ticular for small and medium sized enterprises. Whereas for Hypothesis 2. If core components are modeled using a UML
instance a regular invoice just requires a small set of elements tool of choice, the result would be conceptual business doc-
and attributes an invoice standardized by UN/EDIFACT ument models based on UML. These models can be used to
contains a multitude of possible elements not needed in a exchange structural business document information between
regular business transaction. business analysts, software developers and other stakehold-
ers. Although a conceptual model is appropriate for the
Third, most of the standards are transfer syntax specific. exchange of structural information, it cannot be used in a
Standards such as UN/EDIFACT are tightly bound to the real-world IT system. In order to allow for the integration
implementation syntax. Instead of defining a business docu- of a business document in a SOA context it must first be
ment on a conceptual level most of the standards are based represented on a logical level e.g. XML schema. Therefore
on a logical level e.g. XML schema. Changes in the transfer a solution for the derivation of logical level business docu-
syntax therefore require a complicated reengineering of the ments (e.g. XML schema) from their conceptual level core
entire standard. Thus future adaptations of the standard component representation must be found. However, not only
are difficult and time consuming to implement. the forward engineering (UML to XML) must be addressed,
but also the reverse engineering (XML to UML).
Finally the exchange of a logical level business document
definition between two business partners is complicated and Hypothesis 3. As already outlined in section 2 business pro-
error prone during the development phase of the B2B pro- cess modeling and business document modeling are strongly
interlinked. First, a business process model indentifying the tegration of domain and industry specific requirements is
exact exchange order of business document is constructed. easily feasible.
Second, a business document model defining the exact out-
line of the exchanged business documents is created. In re- UPCC - A UML Profile for Core Components. As outlined
cent years UN/CEFACT’s Modeling Methodology (UMM) before, core components are reusable building blocks for the
[22] has established itself as a very promising approach for definition of business documents. However, core components
the definition of inter-organizational business process model. are a theoretical concept and no integration into a UML
In order to allow for a seamless integration into business modeling tool is possible. In order to merge the industry spe-
process models, an integration approach for the core com- cific requirements identified in the step before and the core
ponents technology into the UMM has to be found. A UMM component technology a common solution based on UML
model defining the process perspective together with a core must be found. However, UML is a very generic concept
components model defining the document perspective pro- allowing the construction of a multitude of different struc-
vides a holistic B2B methodology for the definition of SOA tural and behavioral models. In order to restrict the UML
requirements. meta model to the specific needs of business document mod-
eling, a UML model will be defined. A UML profile tailors
the UML meta model using stereotypes, tagged values and
4. METHODOLOGY OCL constraints. The profile can be imported into any UML
In order to provide a solution to the current problems de-
modeling tool of choice and provides the business modeler
fined above a specific methodology will be employed which
with the necessary artifacts to define business documents. If
consists of five distinctive steps. Figure 2 gives an overview
both modelers use the same profile, the conceptual business
about the used approach.
document models are compatible to each other, overcoming
the interoperability limitations of the different standardiza-
Business tion initiatives. We have already started to address this
issue in [9] and also co-authored the first experimental UML
document vs. data
profile for the core components standard 2.01 [23]. With the
modeling advent of the new core components standard 3.0 [24] the old
profile is obsolete and a new profile has to be constructed.
The definition of a new profile, reflecting industry specfic
Business requirements will be an integral part of this dissertation.
Integration into
document
BPM approaches
modeling survey From conceptual models to deployment artifacts. A UML
profile for core components allows the definition of concep-
tual business document models. Since the core components
From conceputal standard is employed, the different business document mod-
els share the same semantic base, thus guaranteeing interop-
models to UPCC
erability. However, a conceptual model cannot be deployed
deployment in a real world IT system. Thus a derivation mechanism
will be developed, allowing the generation of deployment
Figure 2: Dissertation approach artifacts such as XML schema from conceptual business doc-
ument models. The logical level XML artifacts can be de-
ployed in a IT system of choice. However, the generation
Business document modeling vs. regular data modeling. In
of deployment artifacts must not necessarily be restricted to
the first step the specific differences between regular data
XML schema - the generation of UBL [14], Relax NG [13]
modeling techniques such as the ER-model [3] from the rela-
or any other appropriate artifacts is also possible since the
tional database management systems (RDBMS) design and
conceptual core component model does not mandate any
business document model requirements will be examined.
specific implementation technology. As a proof-of-concept
In particular the specific requirements necessary for busi-
a generation of deployment XML schema artifacts will be
ness document modeling are going to be revealed. Since
developed on top of the UML modeling tool Enterprise Ar-
the overall goal is to develop a holistic business document
chitect [18].
methodology a profound knowledge of the different model-
ing techniques is necessary. Furthermore it provides a good
Integration into BPM approaches. Since business documents
introduction into the domain of document modeling per se.
in a SOA context are exchanged in a collaborative process,
the exemplary integration of a conceptual business docu-
Business document modeling survey. The second step will
ment model into inter-organizational business process tech-
comprise a survey of current business document modeling
nologies will be subject to the last step of the thesis. As
approaches, their advantages, disadvantages and application
a process methodology of choice UN/CEFACT’s Modeling
scenarios. Using the survey a precise overview about cur-
Methodology (UMM), which we have co-authored, will be
rent industry approaches and best practices will be given.
chosen. UMM itself is also defined as a UML profile on top
Furthermore a classification of the business document ap-
of UML 2.0. Since the core component profile will also be
proaches in regard to their applicability in a service oriented
defined on top of UML 2.0, a seamless integration is feasi-
context will be defined. The specific requirements of the dif-
ble. Of particular interest will be the derivation of artifacts
ferent industry solutions will be reflected to the maximum
from both methodologies - UMM on the process side and
extend possible in the overall core component methodology.
core components on the business document side. Given this
Since core components provide a generic concept, the in-
holistic approach, the easy configuration of a SOA system has been conducted in the field of XML artifact generation
will be possible. out of UML artifacts. Generally a distinction is made be-
tween forward engineering (XML artifact generation from
5. GOAL UML models) and reverse engineering (UML model genera-
In figure 3 the overall goal of the dissertation is shown. First tion from XML artifacts). Whereas the first approach is of-
two business partners have to agree upon a common process ten straight-forward the second one contains some obstacles.
choreography. The process choreography defines in which or- E.g. a derivation by restriction cannot be modeled with the
der the different business documents are exchanged between Unified Modeling Language. A profound overview on the
the two business partners. In the context of the thesis the reverse engineering of XML schema to conceptual models is
global choreography will be defined using UN/CEFACT’s given in [27]. Thereby the authors examine several reverse
Modeling Methodology. After having found a common agree- engineering techniques and assess their applicability. In the
ment on the business document exchange order, the business field of forward engineering several research efforts can be
documents per se have to be defined. Using the UML Pro- named e.g. [17] and [5]. Several research efforts have also
file for core components, which will be developed in this been conducted in the field of business process and business
dissertation, the two business partners uniquely define the document modeling alignment e.g. [10] [11]. As outlined be-
document semantic. In the next step the common business fore core components define the semantics on a conceptual
document model is used in order to derive XML schema de- level and the semantics are transformed to the logical level
ployment artifacts. The XML schema is then fed into the IT XML schema by derivation. Several other research efforts
systems of the two business partners. Since both IT systems have already addressed the definition of semantics in XML
are configured on the same basis, a common agreement on schema e.g. [12] and [2]. Most of these approaches how-
the interface definitions of the respective WSDL is found. ever are missing a holistic approach for the specific needs in
regard to a use within a SOA context.
(1) Agree on Process Choreography
(2) Agree on Business Documents
7. CONCLUSION
Business Partner A Business Partner B Common modeling approaches for B2B scenarios often only
(3) results in reflect a particular part of a business collaboration e.g. only
the process perspective or only the data perspective. In or-
der to allow for a holistic view on a B2B collaboration a solu-
tion embracing all necessary views and technologies is neces-
sary. We have already actively developed the UN/CEFACT’s
Modeling Methodology, reflecting the process perspective of
a business collaboration. This thesis will close the gap to
a holistic B2B methodology by incorporating the business
document modeling perspective as well. Thereby different
business document modeling standards will be evaluated and
their advantages and disadvantages will be assessed.
C
Core Component
C t Model
M d l
(4) automatically derive
Based on these results and using UN/CEFACT’s core com-
ponents technology, a UML profile will be developed. The
on a common semantic basis. The conceptual business doc-
(5)deploy (5) deploy ument models will then serve as the basis for the derivation
Partner A's IT‐ Partner B's IT‐
of logical document models e.g. XML schema artifacts. The
System System XML schema artifacts can be fed into IT systems of partic-
ipating business partners and guarantee, that all partners
have the same understanding of the exchanged information.
Figure 3: From a conceptual model to deployment Finally the integration into the process modeling method-
ology UMM will be examined. After the finalization of the
By setting the business document semantic on a conceptual thesis a business modeler will be given a holistic methodol-
level using the core components semantic, a quick agreement ogy for the modeling of B2B scenarios.
between the two business partners is possible. Since the
derivation of the XML artifacts is done automatically, a fast
deployment is possible after the requirements of the business 8. REFERENCES
documents have changed. [1] J. Berge. The EDIFACT Standards. Blackwell
Publishers, Cambridge, MA, USA, 2 edition, 1994.
6. RELATED WORK [2] M. Bernauer, G. Kappel, and G. Kramler. Approaches
For the interested reader a general introduction into the to implementing active semantics with XML schema.
field of business document engineering is given in [6]. In the In Proceedings of the 14th International Workshop on
field of business document standardization several initiatives Database and Expert Systems Applications, pages
have been found in recent years. Mostly the efforts are in- 559–565. 2003.
dustry specific and bound to the XML standard. The most [3] P. P.-S. Chen. The Entity Relationship Model:
important standards include CIDX [4], SWIFT [19], HL7 Towards a unified view of data. 1:9–36, 1976.
[8], and PapiNet [15] just to name a few. A lot of research [4] CIDX. Chemical Industry Data Exchange Standard,
2007. on Information Technology and Applications ICITA
[5] C. Combi and B. Oliboni. Conceptual modeling of 2005, volume 2, pages 772–777. ICITA Proceedings,
XML data. In SAC ’06: Proceedings of the 2006 ACM Australia, 2005.
symposium on Applied computing, pages 467–473.
ACM, New York, NY, USA, 2006.
[6] R. Glushko and T. McGrath. Document Engineering.
Massachusetts Institute of Technology, United States,
2nd edition, 2005.
[7] A. R. Hevner, S. T. March, J. Park, and S. Ram.
Design Science in Information Systems Research.
28:75–105, 2004.
[8] HL7. Health Level Seven, 2007.
[9] C. Huemer and P. Liegl. A UML Profile for Core
Components and their Transformation to XSD. In
ICDE Workshops, pages 298–306, 2007.
[10] C. Janiesch, A. Dreiling, U. Greiner, and S. Lippe.
Configuring processes and business documents - an
integrated approach to enterprise systems
collaboration. In ICEBE, pages 516–521, 2006.
[11] C. Janiesch, A. Dreiling, U. Greiner, and S. Lippe.
Integrated configuration of enterprise systems for
interoperability – towards process model and business
document specification alignment. In EDOC, pages
445–448, 2006.
[12] J. B. Li and J. Miller. Testing the semantics of W3C
XML schema. In Proceedings of the 29th Annual
International Computer Software and Applications
Conference, pages 443–448. 2005.
[13] OASIS. RELAX NG Specification. OASIS, December
2001. Committee Specification.
[14] OASIS. Universal Business Language v2.0. OASIS,
2006.
[15] papiNet. papiNet, 2007.
[16] K. Ramamurthy and G. Premkumar. Determinants
and Outcomes of Electronic Data Interchange
Diffusion. 42:332–351, 1995.
[17] D. Skogan. UML a Schema Language for XML based
Data Interchange. In Proceedings of the Second
International Conference on the Unified Modeling
Language, volume 2, pages 211–220. Proceedings,
United States, 1999.
[18] Sparx Systems. Enterprise Architect, 2008.
[19] SWIFT. Society for Worldwide Interbank Financial
Telecommunication, 2007.
[20] UN/CEFACT. UN/EDIFACT D.07B, 2007.
[21] UN/CEFACT TMG. Core Components Technical
Specification - Part 8 of the ebXML Framework, 2003.
[22] UN/CEFACT TMG. UN/CEFACT’s Modeling
Methodology (UMM), UMM Meta Model - Foundation
Module, 2006.
[23] UN/CEFACT TMG. UPCC - UML Profile for Core
Components based on CCTS 2.01. United Nations
Center For Trade Facilitation and Electronic Business,
October 2006. Candidate for version 1.0.
[24] UN/CEFACT TMG. Core Components Technical
Specification 3.0 - draft, 2008.
[25] W3C. Simple Object Access Protocol, 2007.
[26] W3C. Web Services Description Language, 2007.
[27] A. Yu and R. Steele. An overview of research on
reverse engineering XML schemas into UML diagrams.
In Proceedings of the Third International Conference