200 likes | 222 Views
A Device and Service Description Framework for Discovering and Reasoning in Autonomous P2P Environment. N. Shimizu chiko@tom.sfc.keio.ac.jp Keio university. Talk outline. Goal of our project Basic motivations Assumptions Our framework Service model Device model XML syntax.
E N D
A Device and Service Description Framework for Discovering and Reasoning in Autonomous P2P Environment N. Shimizu chiko@tom.sfc.keio.ac.jp Keio university
Talk outline • Goal of our project • Basic motivations • Assumptions • Our framework • Service model • Device model • XML syntax
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>
I can print PDF and BMP file I can convert png into JPG or BMP I can print BMP file Commitment dependency
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?