Entity

EbXML-BP Description

eCo Entity and Description

Agreement

TermsAndConditions for a Business is defined as:
"a pointer to a document that contains information on the terms and conditions under which this Business trades. Any legal information that this Business wishes to communicate to its potential trading partners should be presented here." [eCoSpec]

Agreement Type

An agreement type is the abstract classification of different types of agreements. Examples might include front-end agreements and yearly contracts.

eCo entity: None.

Business Document

See Information Entity.

Documents are used as information item containers and represent a physical encapsulation of information items. Documents are in the form of XML (with DTD's) and XML Schemas (DTD's as instances with other information) according to the W3C recommendations.

Business Event

A business event is an activity that a business decision-maker needs to monitor or evaluate. In most cases, a business event is performed with the objective of making progress toward a specific business goal within the context of a business process. However, some business events simply exchange or synchronize information between parties. Business event examples might include "obtain a quote" or "make an engineering change."

In the eCo model, it appears that you can query a eCo Service's ServiceChoreography and it's next Step(s). However, it does not appear that business events (as defined) are modeled. The ebXML-BP Business Event appears to be more at the business process level and (I think) has its roots in the REA modeling.

Business Process

[Brian Hayes] It is my [current] observation that eCo models the multi-party business process that occurs as a result of services exchanging and processing documents through Services. I'm speculating that you can have a "virtual" Service that specifies a business process that has no Service implementation (The Service's choreography may reference other Services that may have implementations).

Business Process Definition

A business process definition specifies the choreography of business transactions needed to complete a business process. A business process is a collection of business events that are required to achieve a business goal. Normally, such objectives imply the execution of a business transaction or a related set of business transactions that are intended to accomplish a value-added entrepreneurial purpose.

[Brian Hayes] Also see my comment under Business Process.

Business Service Interface

[Terry Allen] [This is] incorrectly defined. An interface is not a definition of an interface. What is defined is a BP Interface Definition.

[Brian Hayes] Note that eCo does not model "partner role."

Business Service

Services create their value by grouping Interactions and other Services together. The logic that governs the order of execution of the Interactions and Services contained within a Service is called the Service Choreography. The definition of a Service Choreography can be explicitly communicated using a formal Business Process Definition Language or it can be implicitly communicated through the natural flow of the Service.

Business Service Interface

A business service interface is the definition of how to interact with one partner role in order to make him/her perform a desired service. For example, a partner role can expose a business process interface for 'quotation service'. It will describe precisely what kind of business signal (i.e. message) you need to send, what you will get back, and what you may expect to have happen as a result of the exchange.

The "Interactions" layer describes the types of interactions behind each service, and the types of messages that are exchanged during each interaction. In one sense, this layer describes a "choreography" of interactions that may take place when a service is invoked. The exact sequence of events in this choreography may be pre-determined, or it may be event-driven by the user's selection of specific options offered by the service.

Business Signal

[Brian Hayes] eCo does not model a "business signal" directly. Instead the information flow is described in terms of an Interaction and Documents. An Interaction specifies Input Documents, Output Documents, and Error Documents.

Business Transaction

A business transaction is a logical unit of business conducted by two or more parties. The community, the partners, and the process, are all in a definable, and self-reliant state prior to the business transaction, and in a new definable, and self-reliant state after the business transaction. In other words if you are still 'waiting' for your business partner's response or reaction, the business transaction has not completed. A business transaction in our model is reflected as the required exchange or series of exchanges of information between two (or more) partner roles in order to complete the transaction. For example the exchange could consist of a request for quote and the return either of the actual quote, or of the confirmation that the request had been received. It would not make sense to have the transaction (interaction) consist of the request only.

[Brian Hayes] It is difficult to map the MetaModel entities Business Transaction, Information Exchange, and Information Flow to the eCo model. I believe this is due the MetaModel's approach on decomposing the process rather than eCo's apparent approach on identifying what is needed to perform e-business. It is my [current] observation that eCo does not model the multi-party business process that occurs as a result of services exchanging and processing documents. eCo defines the business service as encapsulating (providing an interface to) a business process. This definition differs from the ebXML-BP Meta-Model.

Commitment

[Brian Hayes] Based on my current understand of eCo, commitments or service level agreements are not explicitly modeled.

Contract

A contract is a mutual arrangement between parties that some actual economic exchanges will occur in the future. Contracts can have recursive relationships with other contracts, for example, yearly contracts with monthly releases and weekly or daily shipping schedules. Contracts are containers for collections of commitments. For example, a purchase order is a contract wherein the line items are commitments.

eCo entity: None.

Contract type

As in other type objects, contract types are not just categories, they can also define the rules and processes governing contracts of the type.

eCo entity: None.

Dictionary

[Terry Allen] Note that eCo envisions putting in a repository schemas (here "type definitions") and documents (not mentioned here but evident from the element name). They don't have to be the same repositories, and meta-data needs to be defined for both. The "two sets of type definitions" is not too useful a distinction, as a document schema is just another compound data element, distinguished by the author's desire that it be used as a document element (root element).

Duality

Duality is a relationship between Economic Events, where one is the legal or economic consideration of the other. Examples include a payment for a product or service

eCo entity: Not Applicable.

Economic Event

An economic event is the transfer of control of an Economic Resource from one party to another party. Examples would include sale, cash-payment, shipment, and lease.

eCo entity: Not Applicable.

Economic Resource

An economic resource is a quantity of something of value that is under the control of an enterprise. Examples: cash, inventory, and labor and machine services.

eCo entity: Not Applicable.

Economic Resource Type

An economic resource type is the abstract classification or definition of an Economic Resource. For example, in an ERP system, ItemMaster or ProductMaster would represent the Economic Resource Type that abstractly defines an Inventory Item or Product. Economic Resource Types may have recursive relationships, so that for example broad classifications like "product" could group smaller classifications like "product family", which in turn could have as members the specific "product masters" with SKU numbers

eCo entity: Not Applicable.

Fundamental Information Entity

The category that a Data Element is classified in according to the definitions in the Document and Information Item Registry.

Information Entity

Note: We haven't defined this yet, but it may be that the difference between a data structure and an information entity is that the information entity also contains business rules about the data.

Through the registry, documents and document structures can be understood.

Information Exchange

An Interaction consists of a request and a response. The request and the response can consist of zero or more Documents.

Information Flow

[Brian Hayes] This definition is a bit too abstract. Based on the model, I don't see why "business activities" is mentioned in the first sentence. In the second sentence, is not the "particular business document to be exchanged" also an information flow? What is the significance of mentioning this sentence as worded? The definition should also mention how information flow relates to Documents.

[Brian Hayes] Note that eCo does not model "partner role."

Market

A market is a 'meeting place' where organizations and individuals can exchange services or products. A market is defined in terms of the types of services and products that are likely to be exchanged. The "Yellow Pages" in our phonebook is a good example of classifications of products and services, e.g. 'Legal Services', or 'Air condition products'. A person can then anticipate the existence of a 'Legal Services' market and an 'Air Conditioning' market.

Through the use of a Registry, Markets can define new types of Roles to meet their own requirements.

Market Role

[Brian Hayes] I'm not sure if Business Role maps to MarketRoleType or MarketRole.

Market Role Type

[Brian Hayes] I chose this mapping to eCo because the ebXML-BP Meta-Model shows that the Market defines the MarketRoleType, which Classifies the MarketRole.

Ordering Rule

This method of gaining an understanding of Service Choreography is intended as a simple alternative to using a formal process definition language [ECOSPEC:ServiceGetFirstStep].

Partner Role

A partner role is the role a party plays in a specific business transaction.

Markets define an abstract concept of a "Role". Roles define a conceptual grouping of Services that a business can provide in the Market. All eCo Markets must use two default Roles - "Market Maker" and "Market Operator". The Market Maker Role is played by those businesses that are responsible for the inception and high-level administration of the Market. There may be any number of Market Makers in a Market. Market Operators provide the day-to-day operation of a Market. Market Operators typically provide the administrative Services required to run the Market. Each Market only has one Market Operator.

Party

A party is any organization or individual that needs to participate in exchange of products or services in one or more markets. A party is established first as an absolute entity and then in terms of the roles it plays in a market.

The eCo Business Layer encompasses that part of an e-commerce system that represents a single entity in a trading relationship, its formal identification and the services it offers or consumes. While the name "eCo Business Layer" is used to label this concept, this Layer can represent a business, a single individual, or a business unit within a larger organization.

Party type

A party type is a broad classification of the kind of organization or individual. Examples would be 'University', 'Corporation', 'Individual', and 'Government'.

Note: A Business Registry is a hierarchical database that provides a set of type definitions for the eCo Business Layer. The Business Registry contains the information needed to classify eCo Businesses. As such, the Business Registry is most often used when multiple businesses are grouped together in an eCo Market although stand-alone Businesses can still classify themselves using a common Business Registry.

Process Category

A process category is a broad classification of business processes. At a macro level this classification could be like the "Yellow Pages" classification of services. At a finer level processes could be classified to more functional groupings such as 'quotation', 'scheduling', The meta-model does not constrain the kinds of classification of processes.

[Brian Hayes] eCo specifies the need for registries at each layer of the eCo model. There is a MarketRegistry, BusinessRegistry, ServiceRegistry, InteractionRegistry, and DocumentAndInformationItemRegistry.

Resource Catalog

A resource catalog is basically a navigable guide to offered products and services (Economic Resource Types). It is the market equivalence of a company's product catalog. It would be intended for narrowing down the particular kind of product or service you are looking for, hopefully leaving you with multiple possible sources for that product or service.

[Brian Hayes] The Published Interface offered by an eCo Layer, such as Market, can be extended to include queries over and above the base set defined by the standard eCo Published Interface. These are called "Interface Extensions." The standard Market class can be queried for its businesses, business types, and businesses by type. A Market can be queried by products and services if it supported an appropriate an interface extension. The QueryInterface query (part of Published Interface) allows an interested party to find out what queries are supported.

Step Definition

A step definition defines the steps in a business process. Step definition allows for the decomposition (and reuse) of steps and makes the interdependencies between steps explicit. Step interdependencies include predetermined step sequencing, and (implicit) business rules. A step definition always defines either an action taken by a single partner role or an interaction among partner roles.

This method of gaining an understanding of Service Choreography is intended as a simple alternative to using a formal process definition language.