Transcript A Device and Service Description Framework for Discovering and Reasoning in Autonomous P2P Environment N.

A Device and Service Description Framework
for Discovering and Reasoning
in Autonomous P2P Environment
N. Shimizu
[email protected]
Keio university
Talk outline

Goal of our project
–
–

Basic motivations
Assumptions
Our framework
–
–
–
Service model
Device model
XML syntax
Original motivation
Objectives

New functionality creation support

Ex.
–
–
–
Speaker + Amp. + CD player = speaker system
Scanner + Modem = FAX
Mpg encoder + Storage = Video
Autonomous P2P environment
• Established P2P connection
• No yellow pages
• Multi-user
• Device variety
– Capability
– Underlying APIs
E.g. IEEE1394, UPnP, Bluetooth etc.
To archive our objectives
Who has printing functionality?
I have it, send my information.
I have it, send my information.
Issues




Functionality abstraction
Resource competition
Dependency solution
Status notification
Description framework

Device description
–
–
–

Devices’ structure
Functionality information
Specifications
Service description
–
Capability information
Device description
<Device type=“device.specific.uri”>
<Specification>
SPEC information
</Specification>
<PrimitiveServiceList>
Primitive services which it provides
</PrimitiveServiceList>
<DeviceList>
Primitive devices which it has
</DeviceList>
</Device>
Status notification


Static status
Dynamic status
–
–
–
Failure
Occupied / released
Other status
SPEC information
<Specification>
<Item key=“aaa”>value_of_aaa</Item>
<Item key=“bbb”>value_of_bbb</Item>
</Specification>


Attribute – value list
“key”
–
–
attribute name
string
Primitive service



Abstracted device functionality
Resource in our P2P network
Atomic operation
I’m busy!
Composite service


New functionality composed with devices
Composition of primitive services
Converting service
Printing service
Image printing service
Primitive service description
<PrimitiveServiceList>
<PrimitiveService
type=“uri_to_indentify_it”
name=“human_readable_name”>
Capability information
</PrimitiveService>
…
</PrimitiveServiceList>
Commitment dependency
I can print PDF and
BMP file
I can print BMP file
I can convert png
into JPG or BMP
Primitive service capability
<PrimitiveService type=“…” name=“…”>
<InputParameterList>
parameter information
</InputParameterList>
<OutputParameterList>
parameter information
<OutputParameterList>
</PrimitiveService>
Parameter information
<Parameter name=“aaa” type=“string” />
<Parameter name=“bbb” type=“integer” />
<Parameter name=“ccc” type=“base64binary”>
<AcceptableFileType”>
img/jpg
</AcceptableFileType>
<AcceptableFileType>
img/png
</AcceptableFileType>
</Parameter>
Summary

Several issues for functionality composition
–
–
–
–

Functionality abstraction
Resource competition
Dependency solution
Status notification
Our framework
–
–
Primitive service
Dependency solution support
Future work


Formalization
Expand description framework
–
–
Service composition
Semantic description


–

Arguments: JPG, JPEG, jpeg, Jpeg, JpG ….
Service behavior
Dynamic status notification
Trust model
Thank you for your attention
And
Have Questions or Comments?