[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CORRECTION: Proposed Charter for OASIS SOA for Telecom TC - co-proposer list
The co-proposer list has been corrected. > -----Original Message----- > From: Mary McRae > Sent: Wednesday, October 22, 2008 11:26 PM > To: firstname.lastname@example.org; email@example.com > Cc: firstname.lastname@example.org > Subject: [members] Proposed Charter for OASIS SOA for Telecom TC > > To OASIS Members: > > A draft TC charter has been submitted to establish the SOA for > Telecom > Technical Committee (below). In accordance with the OASIS TC Process > Policy > section 2.2: > (http://www.oasis-open.org/committees/process-2008-06-19.php#formation) > the > proposed charter is hereby submitted for comment. The comment period > shall > remain open until 11:45 pm ET on 5 November 2008. > > OASIS maintains a mailing list for the purpose of submitting comments > on > proposed charters. Any OASIS member may post to this list by sending > email > to: > mailto:email@example.com. All messages will be > publicly archived at: > http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members > who > wish to receive emails must join the group by selecting "join group" on > the > group home page: > http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. > Employees of organizational members do not require primary > representative > approval to subscribe to the oasis-charter-discuss e-mail. > > A telephone conference will be held among the Convener, the OASIS TC > Administrator, and those proposers who wish to attend within four days > of > the close of the comment period. The announcement and call-in > information > will be noted on the OASIS Charter Discuss Group Calendar. > > We encourage member comment and ask that you note the name of the > proposed > TC (SOA-TEL) in the subject line of your email message. > > Regards, > > Mary > > --------------------------------------------------- > Mary P McRae > Director, Technical Committee Administration > OASIS: Advancing open standards for the information society > email: firstname.lastname@example.org > web: www.oasis-open.org > phone: 1.603.232.9090 > > =========== > PROPOSED CHARTER FOR REVIEW AND COMMENT > > OASIS SOA for Telecom (SOA-TEL) Technical Committee > > 1) The Charter of the TC, which includes only the following items: > (1)(a) The name of the TC > SOA for Telecom (SOA-TEL) Technical Committee > > (1)(b) A statement of purpose, including a definition of the problem to > be > solved. > This TC plans to identify gaps in standards coverage for using Service > Oriented Architecture (SOA) techniques in a telecom environment; > particularly for Telecom operators/providers. The combined term > "provider/operator" means a company that utilizes a telecoms network to > provide service to the subscriber community, and they may or may not > own the > network assets or services they are providing. > > Applicability of IT-based SOA techniques is much more complex in the > Telecom > world, where services and network features are often tightly coupled > and > vertically integrated. > > * Tight coupling tends to limit the ability of Telecom operators to > develop > new composite services that span heterogeneous telecommunications > networks. > These limitations include the use of Operational Support Systems (OSS) > and > Business Support Systems (BSS) services in particular when used to > support > information services, (and associated content types) of which IT > services > are a subset. > > * Vertical integration reduces visibility and access to services > management > functions making difficult the automation of operations and business > processes across stacks or organizations. Furthermore there are > difficulties > to integrate or support process automation across the OSS, BSS, > services and > network domain and the related challenges with customizing these > processes. > > As Telecom operators transform into broader-based service oriented > providers, the task of service management becomes more complicated, > involving: > * Legacy and next-generation telecommunications services, > * Information services, > * Associated in-house and third-party content, > * Diverse internal and external networks, > * A multitude of end-user device types, and > * Associated partner and supplier organizations. > > This complexity hinders the ability of Telecom operators/providers to > offer > their clients converged, identity based services that are available at > any > time and secure across any access network and that are operating > system, > device and location independent. > > Telecom providers/operators want to rapidly create and deploy new > services > that leverage their infrastructure and give them the ability to > generate new > revenue streams. Telecom providers/operators need to leverage their > infrastructure to better compete in a Web 2.0 environment and > service-oriented IT world. Current SOA technologies were designed > mostly for > IT use cases, and it is feared that they may not be able to support the > requirements of Telecom use cases. > > This work focuses on identifying gaps and generates requirements to > identify > how existing standards can help Telecom providers/operators better > compete > in this new environment. > > In Web 2.0 and SOA environments, there are mismatches between the > requirements of new kinds of experiences (whether enterprise/business > or > social/personal) and those of the Telecom world. The mismatches include > questions such as > * What is a service? > * How is a service defined? > * What is real-time service composition" > * What is security; > * What is raw performance? and > * What is service availability? > > Answers are needed to the above questions in order not to impede the > adoption and use of conventional SOA technologies in Telecoms. At a > minimum > there is a need to harmonize the "vocabulary" of telecoms (notably > around > raw performance requirements) with a more generic framework of service > description that leverages current SOA technologies. > > The adoption of service orientation also places a burden on Telecom > providers/operators to analyze the suitability of adopting such an IT > born > approach within Telecom providers. In general there may be mismatches > between information services developers' and IT technology requirements > and > capabilities and the Telecomm world as it relates to important > characteristic of Telecom services; such as Service Level Agreements > (SLAs) > where the Telecom service provider guarantees the customer a certain > level > of service in return for a specified payment. > > In OASIS, the Service Component Assembly (SCA) TC is working on the > componentization and assembly/composition of services, both from > functional > and management perspectives and the automation of operations and > business > processes. Telecom specific metadata, if and where required, may be > expressed as extensions to the policies associated to SCA assemblies > and > shall be considered as part of this TC work. > > Limitations exist in other areas also, for example in area such as: > > * SOA across administrative domains, > * Multiple interfaces for a service, and > * Traceability of service and components dependencies. > > The TC will focus on generating use cases that covers these topics as > well. > > It is important for the Telecom industry to identify where and why SOA > can > be applied in telecommunication, and the potential gaps and limitations > of > using Web 2.0, SOA, Web Services and/or REST in supporting the unique > requirements of integrating telecommunication services within business > applications. > > There is a need to understand and identify what SOA specifications can > meet > the many Telecom requirements. For example, for the Telecom service > layer: > o SOA is a possible way to develop many new IT/Web / web 2.0 > applications. > > o The Open Mobile Alliance (OMA) has standardized the service layer > with a > SOA blueprint (OMA Service Enablers (OSE)), for the service layer > * SOA and Policies become key service layer aspects (3rd party > exposure, > policy enforcement and management, even in network or edge of network > policies) > * Parlay (which started WS interest for Telecom's with Parlay X) > and the > 3rd Generation Partnership Project (3GPP) have now consolidated their > interest on SOA for Telecom's in OMA. > o Some industry products are evolving the Telecom programming model > closer > to SOA and Service Component Architecture (SCA). > o SOA for OSS/BSS/SDP integration: > * Telemanagement Forum (TM Forum) Service Delivery Framework (SDF) > work > in collaboration with OMA, OASIS and other bodies to standardize an end > to > end OSS/BSS/SDP integration based on SOA. > o SOA Telecom solutions on boarding authoring, deployment, execution > and > management as these are considered by Telecom providers/operators as > new > possible business opportunities and business models: > * IEEE NGSON focus on such SOA aspects > * TM Forum SDF targets among other things management of the > resulting > services > * SOA and Web 2.0 are the underlying approaches. > > (1)(c) The scope of the work of the TC. > The purpose of this TC is to identify the standards consistent with Web > 2.0 > and SOA principles that may be more useful to Telecom > providers/operators as > a means of leveraging Telecom Services in business applications, and to > assess whether there are inherent limitations in such use. > > The work will generate requirements that help to address any identified > limitations or gaps in current existing standards that the TC > identifies as > possible candidates in support of Telecom operators in terms of > testability, > scalability, Service Level Agreements (SLA), reliability, support for > session interactions, event based interactions, service ontologies, > service > failure modes, and the marrying of Web 2.0 and SOA technologies. Doing > so, > it will take inspiration from the work done in other telecom oriented > organizations (for example OMA and the TM Forum) to derive requirements > that > are generic and essential to the Telecom industry. > > The TC output will focus on the development of a use case document that > illustrates possible gaps of Web 2.0 and SOA technologies in support of > Telecom needs. The TC will develop a requirements document for > extending the > current core SOA enabling stack (Web Services and/or REST) in support > of > Telecom needs. > > Scope of the work > > 1. Analysis, Use Cases Gathering and Gap Document > > a. Collect use cases to pin point limitations and current mismatches > between > Telecom services technologies (including Parlay-X) and Web 2.0/SOA > implementation technologies. Example of uses cases include: > 1. Investigate needed enhancements that session oriented capabilities > to > be made available to business level services, using industry accepted > interfaces and techniques. > 2. Investigate the use and alignment with TM Forum specification > regarding > service management of composite services in order to incorporate > abstractions of composite services management models, covering such > aspects > as configuration, event collection, and performance monitoring. > Basically > provide Telecom the ability to create new services based on business > decisions. > 3. Illustrate needed information and behavior models that should be > expressed in WSDL to enable the formal expression of semantic > information > relating to a service. Investigate the mapping of semantic information > into > syntax using languages such as the Web Ontology Language (OWL). > 4. Investigate the need for extensions to WSDL to allow the testing > of > composite services. > 5. Investigate the need of a common modeling scheme to express > service > failure modes. The approach should also allow individual bodies (OASIS > in > the case of WSDL) the responsibility to map those in their domain > specific > languages. > 6. Investigate the need for extensions to BPEL to address specific > synchronous requirements for telecommunications. > 7. Investigate the need for extensions to UDDI to allow the discovery > of > services based on their semantics such as failure mode, testability, > reliability and composability. > 8. Investigate performance requirements, high availability, > predictable > and low latencies, and optimization schema domains. > 9. Investigate the need to extend standards for service contracts > with > consideration of the NGOSS contracts work in TM Forum. > 10. Investigate the needed enhancements and extensions to existing > identity management systems to interface Web 2.0 / SOA to Telecom > services > and networks including mobile networks and their SUM/USIM systems. Such > extensions need to encompass security and privacy concerns, and > exchange of > user profile data. > 11. Identification of gaps-use cases whose full implementation is not > covered by existing standards or models. > > 2. Develop a requirement document for recommended Web Services (and > REST) > extensions to address the Gaps that have been identified in the use > case and > Gap analysis document. The TC will also collect requirements through > liaisons with other SDO such as OMA, TM Forum, 3GPP and ITU-T in > addition to > the possible requirements that will emerge from item 1. > > 3. Perform an analysis of existing solutions with respect to the Gaps > identified in the previous steps. Identify what level of requirements > is > needed, and create a road map of needed requirements and extensions > including the best SDO for specifying these requirements and the > potential > extensions to address them. > > 4. Security, threats and Risk analysis > > * Perform Security Risk analysis and determine needed profiles for best > practice. Identify technology Gaps in this area. > > 5. Out of Scope > > Development of specific solutions to identified Gaps in this TC. > > > (1)(d) A list of deliverables, with projected completion dates. > > 1. Use Cases and Gap Analysis document; July 2009 > 2. Security, threats and Risk analysis; November 2009 > 3. Requirements document that addresses the issues that are identified > in > item 1; November 2009. > > (1)(e) Specification of the IPR Mode under which the TC will operate. > The TC shall operate under: RAND > > (1)(f) The anticipated audience or users of the work. > The output of this work will have direct benefits for the use of the > Web 2.0 > and SOA in Telecom. > > (1)(g) The language in which the TC shall conduct business. > This TC will use English as the language for conducting its operations. > > (2) Non-normative information regarding the startup of the TC: > (2)(a) Identification of similar or applicable work that is being done > in > other OASIS TCs or by other organizations, why there is a need for > another > effort in this area and how this proposed TC will be different, and > what > level of liaison will be pursued with these other organizations. > > The TC will be performing new work activities that are currently not > covered > by any other OASIS TC. > > The TC will coordinate closely with other bodies in order to inform > them > about the progress of the work and also in order to count on their > expertise > in the development of the work. > > (2)(b) The date, time, and location of the first meeting, whether it > will be > held in person or by phone, and who will sponsor this first meeting. > The > first meeting of a TC shall occur no less than 30 days after the > announcement of its formation in the case of a telephone or other > electronic > meeting, and no less than 45 days after the announcement of its > formation in > the case of a face-to-face meeting. > > The First meeting of this TC will occur on Monday, 12 January 2009 from > 9am > - 5pm. Meeting will be hosted by Nortel, 3500 Carling Avenue, Ottawa, > Ontario, Canada. Call-in information will be provided for those unable > to > attend in person. > > (2)(c) The projected on-going meeting schedule for the year following > the > formation of the TC, or until the projected date of the final > deliverable, > whichever comes first, and who will be expected to sponsor these > meetings. > > The TC will conduct its business via weekly teleconference call. The > time of > the call will be determined during the first meeting of the TC. The TC > will > conduct F2F meeting on as needed basis. Teleconference facilities and > F2F > meetings will initially be sponsored by Nortel. > > (2)(d) The names, electronic mail addresses and membership affiliations > of > at least Minimum Membership who support this proposal and are committed > to > the Charter and projected meeting schedule. > 1. Abbie Barbir, Nortel, email@example.com > 2. Enrico RONCO, Telecom Italia, firstname.lastname@example.org > 3. Hanane Becha, Nortel, Hanane.Becha@nortel.com > 4. Ian Jones, BT email@example.com > 5. Li Li, Avaya, firstname.lastname@example.org > 8. Marc Brandt, HP email@example.com > 9. Marco Carugi, Nortel firstname.lastname@example.org > 11. Orit Levin, Microsft, email@example.com > 12. Paul Fremantle, WSO2, firstname.lastname@example.org > 13. John Storrie, Nortel, STORRIE@nortel.com > 14. Piere Tane, Nortel, PTANE@nortel.com > 15. Bob Natale, MITRE, RNATALE@mitre.org > 16. Amardeo Sarma, NEC, Sarma@nw.neclab.eu > 18. Lucia Gradinariu, Lggsolutions.com, email@example.com > 19. Michael Giordano, Avaya, firstname.lastname@example.org > > (2)(e) The name of the Convener who must be an Eligible Person. > Abbie Barbir (email@example.com) Nortel > > (2)(f) The name of the Member Section with which the TC intends to > affiliate > with > The TC intends to affiliate with the Telecom Member Section. > > (2)(g) Optionally, a list of contributions of existing technical work > that > the proposers anticipate will be made to this TC. > None > > (2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document > regarding the planned scope of the TC, for posting on the TC's website. > None > > (2)(i) Optionally, a proposed working title and acronym for the > specification(s) to be developed by the TC. > None > > > > > > > --------------------------------------------------------------------- > > This email list is used solely by OASIS for official consortium > communications. > > Opt-out requests may be sent to firstname.lastname@example.org, > however, all members are strongly encouraged to maintain a subscription > to this list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]