Views
3 years ago

Contract: 027617 SPICE WP 2 Deliverable 2.5 Exposure ... - ist-spice

Contract: 027617 SPICE WP 2 Deliverable 2.5 Exposure ... - ist-spice

Contract: 027617Deliverable ReportPeriod covered: M00 – M18external interfaceservice3rd partyEEwrapperSPICEEEenabler1cookbook functionsenabler2Figure 12: Introduction of a wrapper componentFigure 12 shows that a component is introduced in the SPICE platform that ‘wraps’ theexternal component. The wrapper fulfils the requirements of the cookbook to representthe external component as an own SPICE component.Further investigation is needed to see whether this is really necessary for enablers with acall back, or that a subset of the Cookbook functions can be sufficient.5.4 Impact from the Exposure mechanism and Access ControlAs described in chapter 3 the main requirement for the Exposure mechanism is that thethird party service uses the Discovery Facility [12].The impact for the Access Control is described in section 4.3 Requirements for Third-Party AccessID: SPICE_D2.5_Ericsson Date: 28/06/2007Revision: d0.16Security: CONFIDENTIAL – Consortium onlyPage 32/34

Contract: 027617Deliverable ReportPeriod covered: M00 – M186 Conclusion and outlookIn order to be able to allow third party access, a number of new mechanisms have beeninvestigated, or extensions of existing mechanisms have been considered.For exposure, an alternative dynamic adaptation mechanism has been investigated, onethat does not use a broker. Still, the broker-based adaptation mechanism is the preferredone, because it offers an easy implementation of application-awareness and globaladaptation decisions. Broker-less adaptation systems have an advantage when it isnecessary to turn existing non-adaptive applications into adaptive ones. If this latterconsideration is important, adaptation features can be best integrated into the DiscoveryFacility.For access, the notion of a Security Gateway has been introduced, both on the SPICEside and on the third party application side. The conclusion is that for SPICE trusted thirdpartyaccess is not much different from inter-SPICE access and “untrusted third-partyaccess” is equivalent with public access. A small collection of high-level requirements fortrusted third-party has been formulated. More detailed requirements can be given onlyafter the final concepts and specifications for service access control [8] has beendelivered.Looking at what the third party services needs to do when wanting to use a SPICEcomponent, a number of impacts have been identified. The third party needs to accessthe Discovery Facility, and needs to take measures for access control. That additionalimpact is now assumed for the case in which the SPICE enabler uses call backs, needsnew discussion.7 References[1] SPICE D2.1, Cookbook and Interface Specification of Service EnablerComponents. December 2006.[2] [SPICE D2.3] SPICE D2.3, Service broker architecture for service enabler access.April 2007.[3] Jyotishman Pathak, Doina Caragea, and Vasant G Honavar, Ontology-ExtendedComponent-Based Workflows : A Framework for Constructing ComplexWorkflows from Semantically Heterogeneous Software Components, 2ndWorkshop on Semantic Web and Databases, Toronto, Canada, August 29-30,2004[4] CORBA-WSDL/SOAP Interworking,http://www.omg.org/technology/documents/formal/CORBA_WSDL.htm[5] Jeffrey Hau, William Lee, Steven Newhouse, Autonomic Service Adaptation inICENI using Ontological AnnotationID: SPICE_D2.5_Ericsson Date: 28/06/2007Revision: d0.16Security: CONFIDENTIAL – Consortium onlyPage 33/34

SPICE WP N°: 1 Deliverable N°: 1.6 Title: Legal and ... - Bad Request
D1.7 Title: Revised business analysis and models - ist-spice
Addressing the challenges of Beyond 3G service delivery ... - ist-spice
Deliverable 2.1b, TAMES-2, IST Project 2001-34283 Version 1.0 ...