OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] FW: [members] OASIS TC Call for Participation: OASIS SOA Adoption Blueprints Technical Committee


What we need is for both of these TCs to coordinate closely because I 
expect we will otherwise come to inconsistent descriptions and more confusion.

Is there a way to codify coordination in the charters?

Ken

At 10:23 AM 8/2/2005, Duane Nickull wrote:
>No worries.  Miko Matsumura is the proposed chair of this TC (he is 
>one of our members too).  I have talked to him about this TC as 
>early as New Orleans.
>
>We have talked about the content of the TC and it is closer to an RA 
>that our work, but quite complimentary.  While it is probably too 
>early to actually use the RM, I am sure that the work of the new TC 
>will be in alignment with it when done.
>
>Duane
>
>John Harby wrote:
>
>>+1
>>
>>On 8/2/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote:
>>
>>
>>>No and yes (respectively). If we think of usage patterns as being leveraged
>>>at the use case phase of a system lifecycle, the functional and technical
>>>architectures are dependent upon the usage patterns that are employed, and
>>>are further down in the chain - i.e. in general, use cases -->
>>>functional/technical requirements --> functional/technical architecture -->
>>>design --> etc. So the usage patterns determine, to some degree, the
>>>architecture.
>>>Joe
>>>
>>>________________________________
>>>From: Peter F Brown [mailto:peter@justbrown.net]
>>>Sent: Tue 8/2/2005 7:34 AM
>>>
>>>To: soa-rm@lists.oasis-open.org
>>>Subject: RE: [soa-rm] FW: [members] OASIS TC Call for Participation: OASIS
>>>SOA Adoption Blueprints Technical Committee
>>>
>>>
>>>But isn't there still a danger of divergence from the RM? The value gain is
>>>only there to be had if there is an RM in place, surely? Can a *useful*
>>>usage pattern be derived from something that does not use the RM or RA?
>>>Peter
>>>________________________________
>>>From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: 02 
>>>August 2005 13:16
>>>To: soa-rm@lists.oasis-open.org
>>>Subject: RE: [soa-rm] FW: [members] OASIS TC Call for Participation: OASIS
>>>SOA Adoption Blueprints Technical Committee
>>>
>>>
>>>I believe these blueprints are about usage patterns, independent of
>>>architecture or an RM. There should be value gained when they are combined
>>>with architecture and/or our RM, but do not depend on either.
>>>Joe
>>>
>>>________________________________
>>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
>>>Sent: Tue 8/2/2005 4:55 AM
>>>To: peter@justbrown.net
>>>Cc: soa-rm@lists.oasis-open.org
>>>Subject: Re: [soa-rm] FW: [members] OASIS TC Call for Participation: OASIS
>>>SOA Adoption Blueprints Technical Committee
>>>
>>>
>>>
>>>Does anyone know the people involved in this proposal? I would be
>>>curious to understand their motives.  Do they think the SOA-RM work
>>>is too abstract?  Why are they proposing a separate TC for work which
>>>would one could categorize as belonging to a sub-TC of the SOA-RM.
>>>Does it make sense for them to start their work before the SOA-RM is
>>>finished?  If they do, they might produce blueprints which are at odds
>>>with the RM produced by this TC.  How will their work effect the plans
>>>of this TC to (eventually) create a sum-TC for the purpose of producing
>>>a reference Architecture?
>>>
>>>
>>>-- Greg
>>>
>>>Peter F Brown wrote:
>>>
>>>
>>>>Isn't this an SOA RA by another name?...
>>>>
>>>>Peter
>>>>
>>>>-----Original Message-----
>>>>From: James Bryce Clark
>>>>
>>>[mailto:jamie.clark@oasis-open.org]
>>>
>>>
>>>>Sent: 02 August 2005 00:18
>>>>To: members@lists.oasis-open.org;
>>>>
>>>tc-announce@lists.oasis-open.org
>>>
>>>
>>>>Subject: [members] OASIS TC Call for Participation: OASIS SOA Adoption
>>>>Blueprints Technical Committee
>>>>
>>>>
>>>>      A new OASIS technical committee is being formed. The OASIS
>>>>Service-Oriented Architecture Adoption Blueprints Technical Committee has
>>>>been proposed by the members of OASIS listed below.  The proposal (below)
>>>>meets the requirements of the OASIS TC Process [1].  The TC name,
>>>>
>>>statement
>>>
>>>
>>>>of purpose, scope, list of deliverables, audience, and language specified
>>>>
>>>in
>>>
>>>
>>>>the proposal will constitute the TC's official charter. Submissions of
>>>>technology for consideration by the TC, and the beginning of technical
>>>>discussions, may occur no sooner than the TC's first meeting.
>>>>
>>>>      This TC will operate under our 2005 IPR Policy.[2]  The eligibility
>>>>requirements for becoming a participant in the TC at the first meeting
>>>>
>>>(see
>>>
>>>
>>>>details below) are that:
>>>>      (a) you must be an employee of an OASIS member organization or an
>>>>individual member of OASIS;
>>>>      (b) the OASIS member must sign the OASIS membership agreement (see
>>>>[3]);
>>>>      (c) you must notify the TC chair of your intent to participate at
>>>>least 15 days prior to the first meeting, which members may do by using
>>>>
>>>the
>>>
>>>
>>>>"Join this TC" button on the TC's public page at [4]; and
>>>>      (d) you must attend the first meeting of the TC, at the time and
>>>>
>>>date
>>>
>>>
>>>>fixed below.
>>>>      Of course, it also will be possible to join the TC at a later time.
>>>>
>>>>      Standards always are improved by broad participation.  Non-OASIS
>>>>members who wish to participate may contact us about joining 
>>>>OASIS [3].
>>>Our
>>>
>>>
>>>>rules and structure are designed to promote inclusiveness. We look forward
>>>>to assisting parties interested in joining the community of implementers,
>>>>technologists, academics and end-users working on OASIS standardization
>>>>projects.  All also are welcome to take advantage of the public resources
>>>>maintained for each TC: a mail list archive, document repository and
>>>>
>>>public
>>>
>>>
>>>>comments facility, all of which will be available via the TC's public home
>>>>page at [4]. Archives of the TC's mail list and public comment lists, as
>>>>with all OASIS TCs, will be visible at [5].
>>>>
>>>>      Further information generally related to the topic may be found on
>>>>
>>>the
>>>
>>>
>>>>Cover Pages at
>>>>
>>>http://xml.coverpages.org/soa.html#SOA-Blueprints.
>>>
>>>
>>>>      Please feel free to forward this announcement to any other
>>>>
>>>appropriate
>>>
>>>
>>>>lists.  OASIS is an open standards organization; we encourage your
>>>>
>>>feedback.
>>>
>>>
>>>>JBC
>>>>
>>>>~ James Bryce Clark
>>>>~ Director, Standards Development, OASIS ~ jamie.clark@oasis-open.org
>>>>
>>>>[1] http://oasis-open.org/committees/process.shtml
>>>>[2]
>>>>
>>>http://www.oasis-open.org/who/intellectualproperty.php
>>>
>>>
>>>>[3] See http://www.oasis-open.org/join/
>>>>[4]
>>>>
>>>>
>>>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-blueprints
>>>
>>>
>>>>[5] http://lists.oasis-open.org/archives/
>>>>
>>>>OASIS SOA ADOPTION BLUEPRINTS TC
>>>>
>>>>a. Name
>>>>
>>>>     OASIS Service Oriented Architecture Adoption Blueprints Technical
>>>>Committee
>>>>
>>>>b. Statement of purpose
>>>>
>>>>     Problem to be solved:  In planning and building Service Oriented
>>>>Architectures (SOA), concrete examples often are useful.  SOA designers,
>>>>vendors and users can reference a wealth of abstract guidelines,
>>>>descriptions of functional layers and sets of specific standards or
>>>>
>>>software
>>>
>>>
>>>>that fulfill SOA requirements.
>>>>     However, often there is a shortage of clear, demonstrable examples of
>>>>working implementations based on real needs and requirements that can be
>>>>used as best practices reference, to kickstart implementation projects and
>>>>to compare implementations.  One way to encourage these examples is to
>>>>supply an archetypal "blueprint" set of business requirements and
>>>>
>>>functions
>>>
>>>
>>>>that can be fulfilled by SOA methods.
>>>>     Purpose:  The SOA Adoption Blueprints TC will develop, circulate,
>>>>maintain and update a set of example business profiles or "adoption
>>>>blueprints" to illustrate the practical deployment of services using SOA
>>>>methods.  Each adoption blueprint will provide a (a) business problem
>>>>statement, (b) a set of business requirements, and (c) a normative set of
>>>>functions to be fulfilled, all on a vendor- and specification-neutral
>>>>
>>>basis.
>>>
>>>
>>>>The TC anticipates starting with the original "blueprint" scenario created
>>>>by the project's host, The Middleware Company and its expert group, to be
>>>>contributed to OASIS.  This scenario, the "Generico" core application set,
>>>>will serve as a basic Adoption Blueprint.  It is expected that additional
>>>>blueprints will be developed to address other business requirement sets.
>>>>Additional Adoption Blueprints may interoperate with the basic Generico
>>>>blueprint, or may describe a new separate scenario.
>>>>
>>>>c. Scope
>>>>
>>>>     The TC will:
>>>>     -- Circulate, improve, maintain and standardize the existing
>>>>
>>>"Generico"
>>>
>>>
>>>>blueprint to be contributed, in the form of a basic Adoption Blueprint.
>>>>     -- Accept contributions of data that may be circulated regarding
>>>>permutations of specifications and methods that fulfill the blueprints.
>>>>This data may include sets of standards, specifications, source code or
>>>>other illustrative lists of methods used to implement the requirements and
>>>>functions of an Adoption Blueprint.
>>>>     -- Provide perspectives and events designed to help implementers
>>>>
>>>assess
>>>
>>>
>>>>interoperability between Adoption Blueprints as well as between specific
>>>>implementation examples.
>>>>     -- Consider the creation of additional supporting material for the
>>>>Adoption Blueprints, to make the reference value of each blueprint more
>>>>robust.  These may include additional specified functions, additional
>>>>feedback and business requirement information obtained from relevant
>>>>
>>>actors
>>>
>>>
>>>>in the subject space of the scenario, and additional methods of
>>>>representing, modeling or formalizing requirement statements.
>>>>     -- Consider the creation of additional Adoption Blueprint scenarios
>>>>based on end-user requirements, such as an occasionally connected
>>>>
>>>blueprint,
>>>
>>>
>>>>a policy management blueprint or a business-to-business blueprint.
>>>>     -- Consider the creation of descriptions of sets of open standards
>>>>
>>>that
>>>
>>>
>>>>could fulfill various Adoption Blueprints, when their use demonstrates
>>>>
>>>best
>>>
>>>
>>>>practices in SOA.
>>>>
>>>>d.  Deliverables
>>>>
>>>>     1. A final draft of a reviewed and updated version of the basic
>>>>Adoption Blueprint, to be issued 4 months from formation of this TC.
>>>>     2. (Optionally) Additional adoption blueprint profiles, and/or
>>>>extensions of existing blueprints, to fulfill expressed needs to
>>>>demonstrate new functionalities or evolving user requirements.
>>>>     3.  (Optionally) Descriptions or profiles of sets of open standards
>>>>that could be used in combinations to fulfill the requirements of Adoption
>>>>Blueprints.
>>>>
>>>>e. IPR Mode
>>>>
>>>>     RF on Limited Terms (as specified in the OASIS IPR Policy)
>>>>
>>>>f.  Anticipated audience
>>>>
>>>>     Anyone involved in the design, documentation or implementation of
>>>>Service Oriented Architectures (SOAs) or components thereof.
>>>>
>>>>g.  Language
>>>>
>>>>     English. The TC may elect to form subcommittees that produce
>>>>
>>>localized
>>>
>>>
>>>>documentation of the TC's work in additional languages.
>>>>
>>>>==
>>>>
>>>>The following is non-normative information for the purposes of starting
>>>>
>>>the
>>>
>>>
>>>>TC, and will not be part of the TC's charter.
>>>>
>>>>a.  Similar and applicable work
>>>>
>>>>     There is some relevant work that has been done by the OASIS ebSOA TC
>>>>[*1] that we intend to explore.  The OASIS SOA Reference Model TC [*2]
>>>>appears to be distinct, in that it seeks to develop reference models for
>>>>SOA at an abstract functional level, rather than specific functional
>>>>examples, although it's possible that those abstracts models may be of
>>>>
>>>some
>>>
>>>
>>>>descriptive use to this TC.   A variety of other standards projects
>>>>including the OASIS FWSI TC [*3] have defined or provided specific
>>>>functional web service or SOA elements that might populate or guide a
>>>>specific Adoption Blueprint.  The TC anticipates seeking liaison with
>>>>
>>>those
>>>
>>>
>>>>TCs, and any others that may have relevant work that can be deployed to
>>>>fulfill Adoption Blueprints.
>>>>      The TC may also seek to establish liaisons with industry groups in
>>>>specific user domains that can contribute actual SOA use scenarios and
>>>>provide or elaborate business requirements.
>>>>
>>>>[*1] http://www.oasis-open.org/committees/ebsoa/
>>>>[*2] http://www.oasis-open.org/committees/soa-rm/
>>>>[*3] http://www.oasis-open.org/committees/fwsi/
>>>>
>>>>b.  Anticipated contributions
>>>>
>>>>      SOA_Blueprints_Initiative_Definition_v0.5
>>>>      SOA_Blueprints_Concepts_v0.5
>>>>      SOA Adoption
>>>>
>>>Blueprints_Requirements_Specification_v0.5
>>>
>>>
>>>>      SOA Adoption Blueprints Occasionally Connected Profile draft v0.1
>>>>       http://www.soacenter.com
>>>>
>>>>
>>>http://www.middlewareresearch.com/soa-blueprints/index.jsp
>>>
>>>
>>>>c.  First meeting
>>>>
>>>>      Date: Thursday September 1, 2005
>>>>      Time: 9:00 am Pacific US
>>>>      Face to Face or Conference Call: Conference Call
>>>>      If F2F, location: N/A
>>>>      Meeting Sponsor:  Infravio
>>>>
>>>>d.  On-going meeting schedule
>>>>
>>>>     Planned meeting schedule will be monthly conference calls, with Face
>>>>to Face meetings quarterly or as otherwise approved by the TC.  Sponsors
>>>>for meetings will be solicited from the proposing members.
>>>>
>>>>e.  Proposers
>>>>
>>>>Gopalakrishna Bylahalli,
>>>>
>>>gopalakrishna.bylahalli@wipro.com, Wipro
>>>
>>>
>>>>Technologies
>>>>Mark Cowan, mark.cowan@adobe.com, Adobe Systems
>>>>Mark Little, mark.little@arjuna.com, Arjuna Technologies
>>>>Miko Matsumura, mmatsumura@infravio.com, Infravio
>>>>Oleg Mikulinsky, oleg.mikulinsky@weblayers.com, WebLayers
>>>>Mike Morris, mmorris@mw2consulting.com, MW2 Consulting
>>>>Jyoti Namjoshi, Jyoti.Namjoshi@patni.com, Patni
>>>>Ash Parikh, ash.parikh@rainingdata.com, Raining Data
>>>>June Park, june.park@samsung.com, Samsung SDS
>>>>Gunendra Patil, gunendra.patil@wipro.com, Wipro Technologies
>>>>Seema Patil, seema.patil@wipro.com, Wipro Technologies
>>>>Sadagopan Singam, Sadagopan_S@satyam.com, Satyam Data Systems
>>>>
>>>>f.   TC Convener
>>>>Miko Matsumura, mailbox@gmail.com
>>>>
>>>>g.  Proposed TC chair
>>>>Miko Matsumura, mailbox@gmail.com
>>>>
>>>>==
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>>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.
>>>>
>>>>
>>>>
>>>>

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ---------------------------------------------------------------------------------- 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]