A Device and Service Description Framework for Discovering and Reasoning in Autonomous P2P Environment N.
Download
Report
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?