CORRECTION: Proposed Charter for OASIS SOA for Telecom TC - co-proposer list

["Mary McRae" <marypmcrae@gmail.com>]

The co-proposer list has been corrected.

> -----Original Message-----
> From: Mary McRae 
> Sent: Wednesday, October 22, 2008 11:26 PM
> To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
> Cc: oasis-charter-discuss@lists.oasis-open.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:oasis-charter-discuss@lists.oasis-open.org. 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: mary.mcrae@oasis-open.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, abbieb@nortel.com
> 2. Enrico RONCO, Telecom Italia, enrico.ronco@telecomitalia.it
> 3. Hanane Becha, Nortel, Hanane.Becha@nortel.com
> 4. Ian Jones, BT ian.c.jones@bt.com
> 5. Li Li, Avaya, lli5@avaya.com
> 8. Marc Brandt, HP marc.brandt@hp.com
> 9. Marco Carugi, Nortel marco.carugi@nortel.com
> 11. Orit Levin, Microsft, oritl@microsoft.com
> 12. Paul Fremantle, WSO2, paul@wso2.com
> 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, lucia.gradinariu@lggsolutions.com
> 19. Michael Giordano, Avaya, giordano@avaya.com
> 
> (2)(e) The name of the Convener who must be an Eligible Person.
> Abbie Barbir (abbieb@nortel.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 member-services@oasis-open.org,
> however, all members are strongly encouraged to maintain a subscription
> to this list.