37
© 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

© 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

Embed Size (px)

Citation preview

Page 1: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

© 2005-2006 The ATHENA Consortium.

Repository for Business

Documents and Protocols

Gerd Völksen, Siemens

Page 2: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

2© 2005-2006 The ATHENA Consortium.

Course Structure

1. Introduction

2. Business Document Repository

Page 3: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

© 2005-2006 The ATHENA Consortium.

Introductionto

Repositories

Page 4: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

4© 2005-2006 The ATHENA Consortium.

Repository Context

Related Systems:

• Database and Database Management Systems (DBMS)

– RDBMS

– OODBMS

• Content Management Systems (CMS)

– Enterprise Content Management System (ECMS)

– Web Content Management System

• Data Warehouse

• Institutional Repository

• Digital Repository / Digital Library

• Directory

• … and many more

Page 5: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

5© 2005-2006 The ATHENA Consortium.

What is a Repository?

A repository is a central place where data is stored and maintained. A repository can be […] a place where multiple databases or files are located for distribution over a network, (or) a computer location that is directly accessible to the user without having to travel across a network, (or) a place where anything is stored for probable reuse.

Wikipediahttp://en.wikipedia.org/wiki/Repository

Data storage and maintenance, distributed over a network, reuse

Page 6: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

6© 2005-2006 The ATHENA Consortium.

What is a Repository?

A repository is a collection of resources that can be accessed to retrieve information. Repositories often consist of several databases tied together by a common search engine.

M. Chapplehttp://databases.about.com/cs/administration/g/repository.htm

Data storage and maintenance, distributed over a network, reuseResources address information, search in database clusters

Page 7: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

7© 2005-2006 The ATHENA Consortium.

What is a Repository?

A repository is a shared database of information about engineered artifacts. […] Designing such engineered artifacts requires using software tools. The goal of a repository is to store models and contents of these artifacts to support these tools.

Ph. Bernsteinhttp://www.sigmod.org/record/issues/9803/bernstein.ps

Data storage and maintenance, distributed over a network, reuseResources address information, search in database clustersShared database, meta data / models of artifacts

Page 8: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

8© 2005-2006 The ATHENA Consortium.

What is a Repository?

Commercial repositories are often implemented on top of more traditional database, and even file system, technology. Therefore, repositories often serve as a layer between a data store, such as an RDBMS, and an application requiring access to persistent data.

F. Sommershttp://www.artima.com/lejava/articles/contentrepository.html

Data storage and maintenance, distributed over a network, reuseResources address information, search in database clustersShared database, meta data / models of artifactsBridge between application and data store

Page 9: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

9© 2005-2006 The ATHENA Consortium.

Repository Components

• A repository engine that manages the repository's content or repository objects.

• A repository information model that describes the repository contents.

• A repository API that allows applications to interact with the repository engine and provides for querying or altering the repository information model.

• Optionally, a repository includes an interface to a persistent store, or a persistence manager.

… according to Bernstein and Sommers

Page 10: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

10© 2005-2006 The ATHENA Consortium.

Repository Architecture

Persistent Data StorePersistent Data Store

Information Models Information Models

Repository APIRepository API

ApplicationApplication ToolTool GUIGUI

Repository EngineRepository Engine

Repository features• Access Management

• Object Management

• Version Management

• Notification

• Dynamic Extensibility

• Relationship Management

• Configuration management

Page 11: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

11© 2005-2006 The ATHENA Consortium.

Repository Features

Access Management• Enable access to the repository• Enable object access• Read and write object access• View object access (= read meta data)

Repository API

access

Page 12: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

12© 2005-2006 The ATHENA Consortium.

Repository Features

Object Management• Store the state of objects of the repository• Allow applications to manage objects via the repository

interface• Store, retrieve, update, remove

Repository API

storeretrieveupdateremove

Page 13: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

13© 2005-2006 The ATHENA Consortium.

Repository Features

Version Management• Keep track of versions of objects• Make versions available to applications

Repository API

store 1

1 2 3 4

234

Page 14: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

14© 2005-2006 The ATHENA Consortium.

Repository Features

Notification• Enable subscription for certain object registration, update, or

removal• Notification accordingly

Repository API

notifysubscribe

Repository API

store

Subscribe

Page 15: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

15© 2005-2006 The ATHENA Consortium.

Repository Features

Dynamic Extensibility• Add new types of objects / content dynamically at runtime

Repository API

store

Page 16: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

16© 2005-2006 The ATHENA Consortium.

Repository Features

Relationship Management• Allow the specification of object relationships• Data – meta-data – meta-meta-data – …

Repository API

Page 17: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

17© 2005-2006 The ATHENA Consortium.

Repository Features

Configuration management• One single repository for objects belonging to several users,

groups, or companies

Repository APIRepository API Repository API

Page 18: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

18© 2005-2006 The ATHENA Consortium.

Repository Requirements

• A repository needs to be independent from – Its content– Hardware, software, and network platforms– Logical structures– Specific applications– The number of users

• A repository needs to be – Easy to integrate– Of “indefinite” size– Fitting to various applications, tools, GUIs, …

Page 19: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

© 2005-2006 The ATHENA Consortium.

Repository for Business Documents

Page 20: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

20© 2005-2006 The ATHENA Consortium.

Persistent Data StorePersistent Data Store

Information Models Information Models

Repository APIRepository API

Repository EngineRepository Engine

The Content

What is so special about business documents…

… from the point of view of a repository?

ebXMLCPPA

Impl. Guide

VariantProblem

RosettaNetPIPs

STEP

EDI STAR OAGI WS-CDL

ebXMLBPSS

ebXMLCCTS

RosettaNetData

Dictionary

W3C transport protocols

(HTTP, SOAP, etc.)WSDL Discovery

IEEE FIPA

OGSAOGSI

UML UBLstandard product attributes

WS-BPEL XPDL

EDI STAR OAGI

• The huge number of different formats

• Various origins: bodies (e.g. W³C, IEEE), companies (e.g. Scheer)

• Domain-specifics as from automotive

• Applicability at different business levels: ICT, content, process,…

• Size of the data objects

Page 21: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

21© 2005-2006 The ATHENA Consortium.

Persistent Data StorePersistent Data Store

Information Models Information Models

Repository APIRepository API

Repository EngineRepository Engine

<?xml version="1.0" encoding="utf-8"?> <!-- ** OAGIS® Revision: 9.0 ** ** Date: 08 April 2005 ** ** Copyright 1998-2005, All Rights Reserved ** This is an OAGIS® BOD XML Schema (XSD) Definition. License information for this file is provided in the file **2005 OAGi License Agreement.txt** that is provided with this download package. For support, more information, or to report implementation bugs, please contact the Open Applications Group at [email protected]. XML Schema Name: \OAGIS\9.0\Resources\Components\Operational\LogisticsComponents.xsd --> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.openapplications.org/oagis/9" targetNamespace="http://www.openapplications.org/oagis/9" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:include schemaLocation="../Common/Components.xsd"/> <xsd:complexType name="ShipmentHeaderBaseType"> <xsd:annotation> <xsd:documentation>The Warehouse Location identifies the place from where the goods are shipped</xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="StatusEnabledHeaderType"> <xsd:sequence> <xsd:element ref="ShipUnitQuantity" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Contains the quantity of units or things shipped. This represents the container(s), not the product shipped. An example of this is "4 truck loads" or "2 wooden crates".</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="WarehouseLocation" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the storage facility for inventory.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the storage facility for inventory.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="CarrierRouteReference" minOccurs="0"/> <xsd:element ref="ActualShipDateTime" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the date that is used to identify the actual date and time a shipment occurs.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the date that is used to identify the actual date and time a shipment occurs.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="ScheduledDeliveryDateTime" minOccurs="0"/> <xsd:element ref="ActualDeliveryDateTime" minOccurs="0"/> <xsd:element ref="EstimatedWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9"> The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="LoadingWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">This is the net weight at loading time of the container in which the materials are being shipped.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:group ref="ShippingWeightandVolumeGroup"/> <xsd:element ref="HazardousMaterialCodes" minOccurs="0"/> <xsd:element ref="CountryOfOriginCode" minOccurs="0"/> <xsd:element ref="DistributionCenterCode" minOccurs="0"/> <xsd:element ref="TransportationMethodCode" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Identifies the general type of carrier transportation used to deliver goods.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="SpecialHandlingNote" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DockID" minOccurs="0"/> <xsd:element ref="ShipFromParty" minOccurs="0"/> <xsd:element ref="CarrierParty" minOccurs="0"/> <xsd:element ref="FreightTermCode" minOccurs="0"/> <xsd:element ref="Party" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DistributedCharge" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="ShipUnitBaseType"> <xsd:sequence> <xsd:group ref="TrackingIDGroup"/> <xsd:group ref="ContainerInstanceIDsGroup"/> <xsd:element ref="CarrierParty" minOccurs="0"/> <xsd:element ref="ShipFromParty" minOccurs="0"/> <xsd:element ref="DeclaredValueAmount" minOccurs="0"/> <xsd:element ref="ShipmentDateTime" minOccurs="0"/> <xsd:element ref="ExportLicenseRequiredIndicator" minOccurs="0"/> <xsd:element ref="ImportLicenseRequiredIndicator" minOccurs="0"/> <xsd:element ref="ScheduledDeliveryDateTime" minOccurs="0"/> <xsd:element ref="ActualDeliveryDateTime" minOccurs="0"/> <xsd:element ref="SpecialHandlingNote" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Status" minOccurs="0"/> <xsd:group ref="ShippingWeightandVolumeGroup"/> <xsd:element ref="DistributedCharge" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ShipItemBaseType"> <xsd:complexContent> <xsd:extension base="ItemInstanceBaseType"> <xsd:sequence> <xsd:element ref="CountryOfOriginCode" minOccurs="0"/> <xsd:element ref="ImportLicenseRequiredIndicator" minOccurs="0"/> <xsd:element ref="OrderQuantity" minOccurs="0"/> <xsd:element ref="ShippedQuantity" minOccurs="0"/> <xsd:element ref="OpenQuantity" minOccurs="0"/> <xsd:element ref="BackOrderedQuantity" minOccurs="0"/> <xsd:element ref="OwnershipCode" minOccurs="0"/> <xsd:element ref="EstimatedWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source= "http://www.openapplications.org/oagis/9">The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="LoadingWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">This is the net weight at loading time of the container in which the materials are being shipped.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="RequisitionReference" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="PurchaseOrderReference" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="SalesOrderReference" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DocumentReference" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="ItemSubLine" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="ContainerBaseType"> <xsd:sequence> <xsd:group ref="ContainerInstanceIDsGroup"/> <xsd:element ref="ContainerGroupID" minOccurs="0"/> <xsd:element ref="PackingMaterial" minOccurs="0"/> <xsd:element ref="ShippingMaterial" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="type" type="NormalizedStringType"> <xsd:annotation> <xsd:documentation>Indicates the type of container.</xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:complexType name="ContainerType"> <xsd:complexContent> <xsd:extension base="ContainerBaseType"> <xsd:sequence> <xsd:element ref="UserArea" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="ItemSubLineType"> <xsd:sequence> <xsd:group ref="ItemInstanceIDsGroup"/> <xsd:element ref="Quantity" minOccurs="0"/> <xsd:element ref="Status" minOccurs="0"/> <xsd:element ref="UserArea" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="ItemSubLine" type="ItemSubLineType"> <xsd:annotation> <xsd:documentation>Identifies the lot number and serial number details for a specific quantity of items. This can be used to identify either all the serial numbers within a given lot, or lot numbers and serial numbers independent of each other</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="Container" type="ContainerType"> <xsd:annotation> <xsd:documentation source= "http://www.openapplications.org/oagis/9"> Uniquely identifies a shipping container</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:group name="ContainerInstanceIDsGroup"> <xsd:sequence> <xsd:element ref="ContainerID" minOccurs="0"/> <xsd:element ref="RFID" minOccurs="0"/> <xsd:element ref="SealID" minOccurs="0"/> </xsd:sequence> </xsd:group> <xsd:complexType name="ShipmentUnitType"> <xsd:annotation> <xsd:documentation>The Amount contains the total sales price for the contents of the shipping unit. The TotalAmount contains the sum of the FreightCharges and the Sales price (Amount) for the shipping unit. If C.O.D. (Collect On Delivery) freight terms were specified for the transaction, this is monetary amount that the carrier is to collect as payment from the customer upon shipment of the shipping unit.</xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="ShipUnitBaseType"> <xsd:sequence> <xsd:element ref="EstimatedFreightChargeAmount" minOccurs="0"/> <xsd:element ref="FreightChargeAmount" minOccurs="0"/> <xsd:element ref="SalePriceAmount" minOccurs="0"/> <xsd:element ref="ShipmentTotalAmount" minOccurs="0"/> <xsd:element ref="LoadingDateTime" minOccurs="0"/> <xsd:element ref="EstimatedWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">The estimated weight of an item or container. An estimate is provided as a processing alternative when the actual weight of an item is not known or cannot be calculated exactly.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="LoadingWeightMeasure" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">This is the net weight at loading time of the container in which the materials are being shipped.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="Dimensions" minOccurs="0"/> <xsd:element ref="CountryOfOriginCode" minOccurs="0"/> <xsd:element ref="DestinationCountryCode" minOccurs="0"/> <xsd:element ref="TransportationMethodCode" minOccurs="0"/> <xsd:element ref="ShipmentServiceLevelCode" minOccurs="0"/> <xsd:element ref="PointOfStagingCode" minOccurs="0"/> <xsd:element ref="TransportationTerm" minOccurs="0"/> <xsd:element ref="ShipToLocation" minOccurs="0"/> <xsd:element ref="PackingMaterial" minOccurs="0"/> <xsd:element ref="ShippingMaterial" minOccurs="0"/> <xsd:element ref="ShipmentUnitContainer" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="ShipmentUnitItem" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="UserArea" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="ShipmentUnitItemType"> <xsd:complexContent> <xsd:extension base="ShipItemBaseType"> <xsd:sequence> <xsd:element ref="UnitSalePriceAmount" minOccurs="0"/> <xsd:element ref="ExtendedSalePriceAmount" minOccurs="0"/> <xsd:group ref="FreightItemGroup"/> <xsd:element ref="UserArea" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="ShipmentUnitContainerType"> <xsd:complexContent> <xsd:extension base="ContainerBaseType"> <xsd:sequence> <xsd:element ref="ParentContainerID" minOccurs="0"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the identifier of the container that physically holds other subordinate containers.</xsd:documentation> <xsd:documentation source="http://www.openapplications.org/oagis/9">Is the identifier of the container that physically holds other subordinate containers.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:group ref="FreeFormTextGroup"/> <xsd:element ref="ShipmentUnitItem" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="UserArea" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="ShipmentUnit" type="ShipmentUnitType"> <xsd:annotation> <xsd:documentation source="http://www.openapplications.org/oagis/9">The ShipmentUnit represents a single trackable, uniquely identifiable assembly or container containing a specific collection of goods inventory that is packaged by a supplier for carrier transportation to a customer business partner destination The ShipmentUnit component identifies and describes the physical shipping container(s) and internal packaging structure of the delivered goods. The ShipmentUnit component is typically constructed to describe the result of an inventory picking and packing operation. A ShipmentUnit is generally the smallest "thing" that can be individually moved and tracked throughout a carrier's transportation network. The physical size, inventory, content and internal nested container complexity within a ShipUnit is arbitrary. The ShipUnit component was specifically designed to be transportation mode independent. It may be used to represent any uniquely identifiable and trackable assembly, container or vessel including, but not limited to: a parcel express package; a pallet of identical or mixed items; a truck trailer, rail car or an ocean cargo container. The ShipmentUnit complements the line-item oriented summary information provided in the Shipment's ShipmentItem and InventoryDetail component with detailed information to accurately describe complex shipping unit assemblies and item packaging. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="ShipmentUnitItem" type="ShipmentUnitItemType"/> <xsd:element name="ShipmentUnitContainer" type="ShipmentUnitContainerType"> <xsd:annotation> <xsd:documentation>The ShipmentUnitContainer represents information about an intermediate packaging level within the shipping unit. A ShipmentUnitContainer may or may not have ShipmentUnitItem associated with it</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:group name="TrackingIDGroup"> <xsd:annotation> <xsd:documentation>Contains the TrackingID and the two optional elements that uniquely identify a ship unit</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element ref="TrackingID" minOccurs="0"/> <xsd:element ref="ShipUnitSequenceID" minOccurs="0"/> <xsd:element ref="ShipUnitTotalID" minOccurs="0"/> </xsd:sequence> </xsd:group> <xsd:group name="CatchWeightGroup"> <xsd:sequence> <xsd:element ref="CatchWeightQuantity" minOccurs="0"/> <xsd:element ref="CatchWeightConversionFactor" minOccurs="0"/> </xsd:sequence> </xsd:group> <xsd:group name="FreightItemGroup"> <xsd:sequence> <xsd:element ref="FreightItemID" minOccurs="0"/> <xsd:element ref="FreightClassificationCode" minOccurs="0"/> </xsd:sequence> </xsd:group> </xsd:schema>

The Content

However, it’s all written in a string ...

… mostly using some XML format.

Page 22: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

22© 2005-2006 The ATHENA Consortium.

Persistent Data StorePersistent Data Store

Information Models Information Models

Repository APIRepository API

Repository EngineRepository Engine

The Architecture

Implementation of the JSR 170 Content Repository API Standard

Integration of the Peer-to-Peer Platform BRMF as a data store

Implementation of an API-to-BRMF mapper

JSR 170 API

BRMFBRMF

Mapping JSR 170to BRMF

Page 23: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

23© 2005-2006 The ATHENA Consortium.

Peer-to-Peer Repository

Benefits of the JSR 170 API Standard:

• Several applications can address several different repositories

• Migrate applications among various Standard-compliant repositories

• Use one repository for a several different applications

• Connect Standard API to proprietary API to address proprietary repositories

Standard-compliantRepository

Standard-compliantRepository

Standard API JSR 170Standard API JSR 170

Standard-compliantApplication

Standard-compliantApplication

Standard-compliantApplication

Standard-compliantApplication

Standard-compliantApplication

Standard-compliantApplication

Standard-compliantRepository

Standard-compliantRepositoryStandard-compliant

Repository

Standard-compliantRepository

Proprietary APIProprietary API

API Mapping

Proprietary RepositoryProprietary Repository

Page 24: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

24© 2005-2006 The ATHENA Consortium.

JSR 170 Overview

Each user has credentials for logging in.

Each login is related to a session.

Each session is related to a workspace.

Each workspace has a root node.

Each node has several child nodes and/or property nodes.

Methods are available for• addNode, removeNode,

• Tree traversal: getNode( "/a/e/k" )

• Node access: getNodeByUUID(…)

• setProperty( name, value )

• Update and clone workspaces

• Define node types

• Define property value types

• And much much more…

[root]

-25“JSR 170 is a … “

true 3.14

a b

c

d e g h

i j k

node

property

Page 25: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

25© 2005-2006 The ATHENA Consortium.

JSR 170 Functional Levels

Level 1:

• Retrieval and traversal of nodes and properties

• Reading the values of properties

• Transient namespace remapping

• Export to XML/SAX

• Query facility with XPath syntax

• Discovery of available node types

• Discovery of access control permissions

Level 2:

• Adding and removing nodes and properties

• Writing the values of properties

• Persistent namespace changes

• Import from XML/SAX

• Assigning node types to nodes

For details see: http://jcp.org/en/jsr/detail?id=170Version 2 available since Nov 2006: hppt://jcp.org/en/jsr/detail?id=283

Optional:

• Transactions

• Versioning

• Observation (Events)

• Locking

• SQL syntax for query

Page 26: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

26© 2005-2006 The ATHENA Consortium.

JSR 170 Implementation

CRX• Commercial software• Day Software, Inc.• All levels implemented + WebDAV und LDAP• € 79.- (developer edition) – 7,200.- (standard edition) per year• 30 day trial version available• http://www.day.com/

Jackrabbit• Open source reference implementation• Apache Software License• All levels implemented• Download from http://jackrabbit.apache.org/

Page 27: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

27© 2005-2006 The ATHENA Consortium.

Benefits of the Peer-to-Peer Data Store BRMF• Highly robust and reliable• No single point of failure• Self-organizing overlay network in case of peer break-downs• Easy scaling• Data access without network flooding• Reduced Total Cost of Ownership

Peer-to-Peer Repository

JSR 170 API

BRMFBRMF

Mapping JSR 170to BRMF

Page 28: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

28© 2005-2006 The ATHENA Consortium.

BRMF Overview

Applies a DHT-based Peer-to-Peer protocol, currently Chord• Applies a hash function to keywords to determine peer IDs for

resource storage• Resource replication

Resource management functions• Register• Deregister• Update• Retrieve• Subscribe

Page 29: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

29© 2005-2006 The ATHENA Consortium.

BRMF Overview

Components of the BRMF:

• Registrar: registers resources received from other peers via the P2P communication

• Look-up: applies the P2P protocol to determine the IP address from a peer ID or hash value

• Stabilizer: manages peer replication, applies watchdogs to detect churn, keeps the number of replica constant

• P2P protocol: currently Chord, could be any other DHT-based protocol

• P2P communication: provides transfer of resources, messages, and events between peers, penetrates NATs of most common firewalls

Page 30: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

30© 2005-2006 The ATHENA Consortium.

BRMF Overview

Further BRMF features:

• Access management, access restrictions, group concept

• Visibility restrictions based on groups

• X Path queries

• Resource versioning

• Multi-site resource modification by managing chains of versions

• Distinction between

– Data: may reside in local file systemsreferenced from their meta data resources, accessible via SOAP

– Meta data: wrapped into resources, stored in the P2P network

• Monitored file system access from remote

• SOAP tunneling for calling remote web services

Page 31: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

31© 2005-2006 The ATHENA Consortium.

Peer-to-Peer Repository Architecture

Subdivision:

• One local repository sections – several work spaces

• One distributed P2P repository section – one shared workspace

Peer-to-PeerInformation

Space

Peer-to-PeerInformation

SpaceLocal File System

and Resource Store

Local File Systemand Resource Store

JSR 170 APIJSR 170 API

Repository CoreRepository Core

localRepositoryWorkspace

localRepositoryWorkspace

localRepositoryWorkspace

LocalRepositoryWorkspace Distributed

RepositoryWorkspace

JSR 170 API

BRMFBRMF

Mapping JSR 170to BRMF

Page 32: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

32© 2005-2006 The ATHENA Consortium.

Peer-to-Peer Repository Architecture

Full set of functions for the local workspaces of the repository

Restricted set of functions for the shared

Mapping of JSR 170 features into the BRMF P2P platform:

• Each workspace item (= node or property) is wrapped into one resource

• Keyword construction for properties:concatenation "<node UUID> + <property name>"

• For reading travers the workspace tree to navigate to nodes:

– getNode( <pathName> )

– Apply node iterator

– Apply property iterator

Page 33: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

33© 2005-2006 The ATHENA Consortium.

DistributedRepositoryWorkspace

Peer-to-Peer Repository Architecture

How to write the shared P2P repository workspace:

• Clone: moves a copy of a subtree of a (local) repository workspace to a node in the distributed repository workspace

• Update: moves a copy of a complete (local) repository workspace to a node in the distributed repository workspace

• Node.addNode(…)

• Node.setProperty(…)

• Session.save(), Session.logout()

• Use additionallysession.shutdown() to terminatethe local repository processand the P2P process

Peer-to-PeerInformation

Space

Peer-to-PeerInformation

SpaceLocal File System

and Resource Store

Local File Systemand Resource Store

JSR 170 APIJSR 170 API

Repository CoreRepository Core

localRepositoryWorkspace

Sub-Workspace

localRepositoryWorkspace

localRepositoryWorkspace

LocalRepositoryWorkspace

LocalRepositoryWorkspace

Page 34: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

34© 2005-2006 The ATHENA Consortium.

Peer-to-Peer Repository Conclusion

• Unique approach integrating– API Standard JSR 170

– Peer-to-Peer data store

• Useful for various kinds of applications• Applicable to all kind of content – not just business documents and

protocols• Supports major requirements of business computing:

– Access control

– Content placement

– Robustness, reliability

• Migration to JSR 283 ahead

Page 35: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

35© 2005-2006 The ATHENA Consortium.

Repository References

• ATHENA A7, Deliverable D.A7.2: "ATHENA Approach to Business Document and Protocol Management", 2006.

• ATHENA A7, Deliverable D.A7.1: "Analysis of Industry Best Practice in Business Documents and Protocols", 2006.

• ATHENA A6, Deliverable D.A6.4, Annex 2: "BRMF – Peer-to-peer business Resource Management Framework", 2006.

• Barik, T.: "Introducing the Java Content Repository API", in http://www-128.ibm.com/developerworks/java/library/j-jcr/, 2006.

• Bauer, B., Müller, J.P. and Roser, S.: "A Decentralized Broker Architecture for Collaborative Business Process Modeling and Enactment", to be published in Proceedings of the second I-ESA, Springer Berlin, 2006.

• Bernstein, P.A., Harry, B., Sanders, P.J., Shutt, D. and Zander, J.: "The Microsoft Repository", Invited Keynote Address, Proc. of 23rd International Conference on Very Large Data Bases, Athens, Greece, Morgan Kaufmann Publishers, San Francisco, 1997, pp. 3 12.

Page 36: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

36© 2005-2006 The ATHENA Consortium.

Repository References

• Bernstein, Ph.: "Repositories and Object Oriented Databases", in http://www.sigmod.org/record/issues/9803/bernstein.ps, 1997.

• Freisleben, B. et al.: "A Framework for Resource Management in Peer-to-Peer Networks", Net.Object Days 2002.

• JSR 170: "Content Repository API for Java™ Technology Specification", in Java Specification Request 170 Version 1.0, http://jcp.org/aboutJava/communityprocess/final/jsr170/index.html, May 11, 2005.

• Rusitschka, S. and Southall, A.: "The Resource Management Framework: A System for Managing Metadata in Decentralized Networks Using Peer to Peer Technology", Lecture Notes in Computer Science; Springer Heidelberg; Volume 2530 / 2003.

• Sommers, F.: "Catch Jackrabbit and the Java Content Repository API", in http://www.artima.com/lejava/articles/contentrepository.html, 2005.

Page 37: © 2005-2006 The ATHENA Consortium. Repository for Business Documents and Protocols Gerd Völksen, Siemens

37© 2005-2006 The ATHENA Consortium.

The End

Thanks for your attention!