Service-oriented computing (SOC) is a new paradigm that allows organizations to tailor their business processes, in such a way that efficiency and effectiveness goals will be achieved by outsourcing (parts of) business processes to web-based service-providers. In order to find the computing service-providers that provide the organizations with the biggest benefits, it is paramount that the service-requesting organization (SRO) has a precise description of the service it wants to have delivered by the service delivering organization (SDO). In this paper we will illustrate how enterprises that play the SDO and SRO roles can be conceptually integrated by creating conceptual models that share the definitions of the business processes within the service oriented architecture (SOA) framework.
In the service-oriented architecture (SOA) paradigm, a service requesting organization (SRO) basically outsources one or more organizational activities or even complete business processes to one or more service delivering organizations (SDOs). The way this is done currently, is that the SRO ‘outsources’a given computing service to a ‘third-party’ SDO for a relative long period of time (3 months, a year). The selection and contracting activities are performed by organizational actors, i.e. managers responsible for the business processes in which the service(s) is (are) contained. Most of the current SDO’s provide ‘internet substitutes’[1] for functions that used to be performed by an (integrated) SRO’s enterprise system, implying that the SRO’s that use these process services are shielded from the intrinsic complexities of these ‘substituted’functionalities [2, 3].
Current approaches for web services, have limitations on a semantic and ontological level (among others) [4]. The problem with current approaches is that they cannot handle the semantic and ontological complexities caused by flexible participants having flexible cooperation processes. Enterprise integration between participants (i.e. broker, SROs and SDOs) can only be achieved if the conceptual schema of the content, e.g. it’s ontology can be expressed formally and explicitly [5].
In most business organizations the function that is responsible for information and knowledge management will have some kind of repository, schema or knowledge map that (ideally) defines the information objects (business repository or business ontology) and the semantic relationships between these business concepts (conceptual schema or a DDL of some sort). At best (large) companies have a business glossary in which business concepts are defined precisely. When it comes to processes we must conclude that at best descriptions of procedural knowledge might be documented in some type of DFD’s or other process description logic (e.g. BPMN [6]). In most practical situations, however, the process logic is embedded in software code, and an explicit semantic description is lacking.
The application of the service-oriented paradigm that will lead to the most benefits for the SRO will be embedded in a semantic-web environment in which the ‘outsourcing’decision in principle, can be made in real-time every time a service is requested [7]. This real-time level of decision making implies that the service-processes that are requested should be defined in such a way that the negotiation, contracting and execution of the service can take place in ‘run-time’ without ‘design time’ human intervention. In fact-oriented terminology we can say that a process is a fact-generating activity [8].
There currently exist a number of generic standards for expressing web ontologies, e.g. OWL [9] and for modeling web service ontologies, e.g. WSML [10] and web services execution, e.g. WFSL 1.0 [11] and BPEL4WS [12].
In this paper we will apply the fact-oriented conceptual modeling language (e.g. as documented in several variations in [13-17]), that will enable businesses to define their platform independent models for their service-oriented requirements and that will allow for an ‘automatic’transformation from the platform independent model (PIM) to the platform specific model (PSM) levels [18, 19]. A well-written text-book on ORM is [20]. 2 2.1
In compliance with the emerging OMG standard on business rules: SBVR [21], we will consider a family of conceptual modeling approaches that traditionally have been used for the specification of relational databases [16] but have evolved into business rule modeling languages [22-26] and languages for subject matter modeling [27-30]. We will refer to this family of approaches as fact-oriented modeling approaches. The latest extensions of the fact-oriented modeling approaches cater for the declarative modeling of business processes [31-33] and business events [32, 34]. In an earlier article the application of factorientation for applying web ontologies has been discussed [35]
The (extended) fact-oriented approach structures verbalizable knowledge into the following elements [27]: 1. Knowledge domain sentences 2. Concept definitions and naming conventions for concepts used in domain sentences 3. Fact types 4. Fact type readings for the fact types 5. Population state (transition) constraints for the knowledge domain 6. Derivation rules that specify how specific domain sentences can be derived from other domain sentences. 7. Exchange rules that specify what fact instances can be inserted, updated or deleted. 8. Event rules that specify when a fact is derived from other facts or when (a) fact (s) must be inserted, updated or deleted.
The combined Knowledge Reference Model (KRM) consisting of elements 1 through 8 of the above captures a complete description of a domain- or application’s conceptual schema, including the domain- or application ontology (elements 2, 3 and 4).
A legend of the ORM-(I) notation used in this article is provided in the following. The ‘role-based’ORM notation makes it easy to define static constraints on the data structure and it enables the modeler to populate ORM schemas with example sentence instances for constraint validation purposes. In ORM (and other fact oriented approaches) the fact construct is used for encoding all semantic connections between entities. Figure 1 summarizes the symbols in the ORM modeling language that we have used in this paper.
B (A) B bnr (B) x /y (F)
B (bnr) ( C)
B ! (D)
A
Fig. 1. Main symbols in Object-Role Modeling (ORM). Atomic entities (figure 1A) or data values (figure 1B) are expressed in ORM as simple (hyphenated) circles. Instances of an entity type furthermore can exist independently (e.g. they are not enforced to participate in any relationship), which is shown by adding an exclamation point after the entity type’s name (figure 1D). Simple reference schemes in ORM are abbreviated by putting the value type or label type in parenthesis beneath the name of the entity type (figure 1C). Semantic connections between entities are depicted as combinations of boxes (figure 1E) and are called facts or fact types in ORM. Each box represents a role and must be connected to either an entity type, a value type or a nested object type (see figure 1F). A fact type can consist of one or more roles. The number of roles in a fact type is called the fact type arity. The semantics of the fact type are put in the fact predicate (this is the text string … x… y… in figure 1E). A nested object type (see figure 1G) is a non-atomic entity type that is connected to a fact type that specifies what the constituting entity types and/or values types are for the nested object type. Figures 1H through 1L illustrate the diagramming conventions for a number of static population constraint(s) (types) in ORM. A double-arrowed line (figure 1H) that covers one or more ‘boxes’of a fact type is the symbol for an internal uniqueness constraint. The symbol in figure 1K stands for an external uniqueness constraint. A(n) uniqueness constraint restricts the number of identical instances of a role combination ‘under’the uniqueness constraint to one. A mandatory role constraint (figure 1I) can be added to a role. It specifies that each possible instance of such an object type must play that designated role at all times. A disjunctive mandatory role constraint (figure 1J) is defined on two or more roles and specifies that each possible instance of the object type connected to these roles must at least play one of these roles at any time. In figure 1L an example of a value constraint is given that enforces that each instance of the object type B either has the value b1 or b2 2.2
The research on the process-oriented perspective in the information systems research community was prominent in the late seventies and has resulted in numerous processoriented information systems development methodologies like SADT [36] and SA/SD [37] that are still in use [38]. Although these development methodologies were processoriented they also contained modeling constructs for the data-oriented perspective. In the eighties a number of system development methodologies were proposed that covered both the data-oriented, process-oriented and behaviour-oriented perspectives [39-41]. In the nineties a research school on ‘workflow management’(see for a good literature review [42]). Around that time the business process reengineering ‘paradigm’ [43, 44] in combination with the increasing popularity of Enterprise Resource Planning packages (e.g. SAP, see [45]), lead to the development of domain-oriented analysis methods [46] of which the ARIS-based Business Process Modeling [47, 48] and BML [49] are good examples. A recent standard for expressing business processes is the business process modeling notation specification BPMN [6].
In addition to the body of work on process modeling in the above, there has been some considerable amount of research on process modeling in the fact-oriented community as well [8, 33, 50-52] [53, 54]. In figure 2 we have given the necessary documents for the three perspectives in the IFIP-CRIS architecture (based on [55]). In this paper we will focus on the documents in the middle column of figure 1 that represent the process-oriented perspective. In [54] the union of the meta process model and meta behaviour model is put into the architecure as ‘program grammar’.
Meta model fact oriented approach Enterprise data model Enterprise data base
Meta process model Enterprise Process Base
Meta behaviour model Enterprise Impulse Base In this paper we will focus on the ‘enterprise process base’from the architecture in figure 2 and we will built upon the 5 document architecture as presented in [54]. In [56] a SOA (service oriented architecture is provided). The basic elements from this service-oriented approach to distributed software design is given in figure 3.
Registry and Lookup Service
service description Discover Service Client
Publish
Service Service request/response Provider
service description In the SOA from figure 3, service delivering organizations (SDOs) or service providers use the registry service (or broker [5] or service repository [57]) to publish their identity and a description of services that they provide. When a service requesting organization (SRO), service requestor [57] or service client, needs a service, it queries the lookup service (service discovery [58]) which will initiate the communication between SRO and SDO to establish a commitment regarding the service delivery [58]. 2.4
The specific paradigm that is center of the discussion in this article is the structuring of businesses according to services that are provided or needed [59]. Research that integrates conceptual (meta)modeling and the SOA paradigm mostly relates to the meta level, especially the meta process model according to the 7-document architecture in figure 2, e.g. as in Piprani et al. [60] and the ontology part of the meta model, e.g. Terlouw [61]. Other researchers investigate, how business rule management can be extended to the service-oriented paradigm [62]. We will take the SOA architecture from figure 3 as a basis for our further application of conceptual modeling on the SOA domain. We will thereby, explicitly distinguish three universes of discourse (UoD’s): the client (SRO), the service provider (SDO) and the broker (or registry and look-up service). 3
We will extend the current modeling capabilities of the fact-oriented approach with modeling constructs for the modeling of business services in the context of the serviceoriented paradigm by extending the concepts definitions and derivation/exchange rule modeling constructs to cater for ‘business services’that can be provided by either the SRO itself or by one or more (external) SDO(s).
In order to use the semantic web for selecting and contracting SDO’s for any business function that needs to be outsourced, business organizations need conceptual modeling tools that define these functions or (parts of) business processes. The commonly used process modeling approaches lack the capabilities to be used for this purpose [33]. In this section we will extend the fact-oriented conceptual modeling approach to cater for the definition of business functions (or parts of business processes) during design time in such a way that in a semantic web environment in which SRO and SDO’s can interchange their domain ontologies and thereby in run-time can decide which of the relevant SDO’s will be partner to deliver the requested service for a given business transaction.
We will present the elements from the fact-oriented knowledge reference model (KRM) and see how they can be applied in the situation in which SDOs are involved in (interorganizational) business processes. We will use as a running example for the UoD of the SRO, the (fictitious) ABC company, and focus on the carrier selection process for customer shipments. 3.1
ABC is a business that operates a number of ‘brick-and-mortar’stores. Although the company does have an internet retail-website, it sometimes receives order request for deliveries via mail, e-mail or fax, outside the sales region it serves and in some cases even outside the country it operates in, and sometimes it receives ‘overseas’order requests. Especially for the latter order category, ABC can make an additional profit by shipping the order using the cheapest carrier at any given point in time. The shipping fee, they charge to their customer is a constant fee. The customer has the choice between standard shipping and express shipping. The ABC company, has a logistics department in which 1 person is responsible for the shipment of continental and overseas orders. Since this person, has also other logistics responsibilities, he/she can not afford to spend too much time trying to search for the best transportation deals. It might be beneficial for ABC, to ‘outsource’the carrier selection process to a third-party, in this case a service delivery organization (SDO).
We will start the presentation of our fact-oriented model by providing a list of structured concept definitions [23, 63]. This list of structured concept definitions, should facilitate the comprehension of knowledge domain sentences and comprise the business domain ontology [64]. 3.2
Size of [cargo] as length* width * height A name from the dimension code name class that can be used to identify a [dimension] among the set of [dimension]s Depicts the extent in meters of any of the three elements of a [dimension] A name from the two-decimal number name class that can be used to identify a [size] among the set of [size]s.
Depicts the extent in cubic meters of a three- [dimension]-al package A name from the two-decimal number name class that can be used to identify a [volume] among the set of [volume]s.
‘Per transaction’ contract base ‘Weekly renewal’ contract base is shipped by
Date code
A generally agreed upon type of delivery by a [service requesting organization] and a service registry organization or broker that is characterized by a maximum [dimension] A name from the delivery type code name class that can be used to identify a [delivery type] among the set of [delivery type]s. Type of commitment between a [service delivery organization] and a [SRO] A name from the contract base code name class that can be used to identify a [contract base] among the set of [contract base]s. A specific value for a [contract base code] that means that a contract between a [SDO] and a [SRO] change per transaction on the discretion of a [SRO].
A specific value for a [contract base code] that means that a contract between a [SDO] and a [SRO] can change per week on the discretion of a [SRO].
Depicts that a package is tranpsorted from an originator’s door to a receiver’s door A request to ship a package to a customer A name from the order code name class that can be used to identify a [order code] among the set of [order code]s.
A third party logistics organization that ships packages for an [order] from a [SRO] to a client of the [SRO] A name from the carrier name name class that can be used to identify a [carrier] among the set of [carriers]s that exist in the world. Depicts a specific day A name from the date code name class that can be used to identify a [date] among the set of [date]s.
In case a standard between the SDO’s and SRO’s and service broker has been implemented, in which it is agreed upon that: for any (predefined) delivery type at most one maximum dimension can exist, we can show this as a uniqueness constraint of fact type Ft1 that covers the role R1. A further formalization of the allowed communication within the SRO’s UoD’s is the convention that a given order by a given SRO must have exactly one dimension. The latter business rule is encoded in the ORM fact type model in figure 3 as a uniqueness constraint spanning role R1 of fact type Ft2 in combination with a mandatory role on the nested entity type SRO-order. Finally, in role R3 of fact type Ft3 we can define a value constraint in which the allowed and enumerable set of values can be listed. In addition to the business rules that can be expressed as population state constraints, we can add business rules that can derive ‘new’fact instances from ‘old’fact instances. An example of such a derivation rule can be applied for fact type Ft4. We assume that a volume is the multiplication of the three dimensions figures that are modeled in fact type Ft2/Ft5. This derivation rule can be modeled as a derivation rule in figure 4 in which formula: Ft4.R2 = Ft5.r1*Ft5.r2*Ft5.r3 is contained.
Define Order has Volume (cubic meters)as Order has cargo Dimension and There exist a dimension for which the width is Size1 and the length is Size2 and the heighth is Size3 and Volume= Size1 * Size2 * Size3 We note that in a service oriented architecture, derivation rules play an important role because SRO’s ‘outsource’the execution and management of these rules to SDO’s. It’s therefore, paramount to incorporate the definition of these derivation- and exchange processes into the list of concept definitions. If we inspect the conceptual schema for our example SRO we see that the process calculate volume is implemented within the sphere of influence of the organization itself. The process is made explicit in the form of derivation rule: Define order has Volume (cubic meters), that is listed at the bottom of figure 4. The process determine carrier for order, however is outsourced to some SDO. c1 Ft3 c10 ; [ per transcation, weekly renewal]
carrier for order
A process that has a a result: a rough indicator of the cubic [volume] of a package which is determined by multiplying its width, heighth and length. <Create(s) instance(s) of Ft4> A transaction in which the [order] and the [dimension] and [delivery date] of the [order] are added to the information system. <Create(s) instance(s) of Ft2 and Ft7> This process leads to the selection of a specific [SDO] for the shipment of an [order] under the best possible conditions for [delivery time] and [shipment price] <Create(s) instance(s) of Ft8> 4
In this section we will look at the Universe of Discourse of a web-service that provides carrier selection services for SRO’s. One of the main processes within this UoD’s is the up-to-date acquisition of carrier data regarding latest offers, in terms of shipment conditions, and prices for each delivery type and possibly delivery (sub)-types depending upon each individual carrier. This web-service organization has as objective to match SRO’s with carriers normally for a small fee per transaction. We will see that ontological commitments need to be established between SRO’s and SDO’s on a ‘design’-time level. This means that key concepts for web-based service transactions will be harmonized (as can be checked for example in the list of concept definitions in tables 1 and 2, for the concept delivery type and carrier). On the other hand, promotional concepts and other rating schemes can be introduced on the fly, at any time by a carrier. For many of these promotional campaigns and or new tariff schemes, it will not be feasible to establish ontology harmonization between the SDO and these carriers at all times. To cater for this, we need modeling constructs that allow us to deal with the runtime changes in domain concepts as used by SDO’s in their carrier selection processes on behalf of their SRO customers. We will show now in our example list of definitions and conceptual schema for the UoD of the SDO can be modeled for these short-term runtime definitions of domain concepts. We note that a ‘snaphot’of delivery types for every carrier that that is considered by a carrier-selection SDO will be modeled as a populations of fact type Ft1 in the conceptual schema of the carrier selection SDO in figure 5. We now see that the carrier selection broker service not only provides the best deal for a service requesting organization, but also performs the role of ‘ontological harmonizer’between the SRO’s and the carriers by introducing and defining the concepts of local delivery type and carrier delivery type.
In table 2 we have provided the extended list of concept definitions for this example UoD of a service delivery organization in which the definitions of the fact generating processes are incorporated.
A third party logistics organization that ships packages for an [order] from a [SRO] to a client of the [SRO] A name from the carrier name name class that can be used to identify a [carrier] among the set of [carriers]s that exist in the world.
A label to refer to a specific type of service provided by a specific [carrier] A [local delivery type] that is offered by a [carrier] A period or slice in time having a duration A name from the natural number name class that can be used to identify a [period length in days] among the set of [period length in days].
A specific quantity of money A name from the dollar name class that can be used to identify a [money amount] among the set of [money amount]s.
A price that is charged per kg for a delivery service during a number of [week]s in a promotional period A price that is charged in a [week] for which no [promotional price] is charged The maximum [size] for length * the maximum [size] for width * the maximum [size] for height of an [order] for which a given [delivery type] is still valid The maximum value for [Period length in days] it takes to deliver a package to a client of a [SRO] A period or slice in time consisting of 365 days according to the Roman calendar A name from the a.d. name class that can be used to identify a [year] among the set of [years] in the roman calendar.
A period or slice of time consisting of 7 days.
A name that can be used to identify a [week] within a given [year] A process that has a result a classification for a [local delivery type] offered by a [carrier] in terms of an instance [delivery type] that has been defined by a [SRO] and [SDO]. <Create(s) instance(s) of Ft108> A process that has a result that a maximum delivery length for a [carrier delivery type] is entered into the information base. <Create(s) instance(s) of Ft106> A process that has a result that a [standard price] for a [carrier delivery type] is entered into the information base <Create(s) instance(s) of Ft101> A process that has a result that a [promotional price] during one or more [weeks] for a [carrier delivery type] is entered into the information base <Create(s) instance(s) of Ft102 and Ft107> In figure 5 we have given the complete conceptual schema for the example carrier selection process within the UoD of the SDO.
Carrier (carrier code) c111 ....is classified as..
Ft108 So, if we inspect the conceptual schema for our fictitious example SDO in figure 4, we can say that one of the ’core business processes’ for the SDO, is the establishing, ontological harmonization, in ‘run-time’this means that the SDO will populate fact type Ft108 in figure 5, by continuously scanning for recent service offerings provided by existing and new carriers. This business process mainly scans and interprets these service offerings, and as a result will ‘label’these offerings and subsequently classify them, in the terminology, that was established between the SRO’s and SDO’s, via a broker or registry service. In the running example of this article, we have limited ourselves to only depict a few relevant fact types that will be used in practice. In a real-life conceptual schema 100’s of fact types might actually be used in the communication, between SDO, SRO and registry service. 5
In line with semantic web developments, the conceptual schema needs a communication part that contains ‘definition’instances to be shared with the potential agents in order for them to be able to communicate effectively and efficiently with a (‘web-based’) business application. Adding these semantic definitions of business processes is a requirement for achieving enterprise integration. This will significantly increase the quality and ease-ofuse of such a (web-based) application, since it has established a semantic bridge with the potential external users, allowing them to communicate in a direct way with the business application, by preventing semantic ambiguities from occurring in the first place. Another advantage of applying fact-orientation for capturing an application or a (relatively complex) domain’s ontology is in its flexibility to use it even to model communication between agents in which (explicit) ontological harmonization at a type or schema level is not possible or desirable. By adding ‘run-time’ concepts as populations of (typed) concepts for which an ontological harmonization already has been established.
Another advantage of using (extended) fact-oriented modeling languages is that a business organization is not forced to remodel the application or domain ontology every time a new ‘implementation’ standard has been defined. Business organizations can capitalize on the fact-oriented conceptual modeling investment, for the foreseeable future by applying the appropriate mappings between a fact-oriented application ontology and the implementation standard of the time. 9. 10. 11. 12. 13. 14. 15. 16. 44. 45. 46. 47. 48. 49.