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

[John Harby <jharby@gmail.com>]

+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.
> >
> >
> >
>