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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

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


Subject: RE: [soa-blueprints] Primer


Reading the charter chunk and Dan's Blackberry scribbles (well done, 
BTW), my first question is how specific a blueprint is supposed to 
be.  Is a blueprint an example solution off a specific scenario or is 
it a factored solution to a set of scenarios?  The former gives a set 
of examples that is foremost in the minds of the TC but may be 
limited in scope to immediate interests of TC members.  The latter 
requires more analysis but can show interesting patterns where a 
priori it was not obvious that similarities exist.  Indeed, it can 
demonstrate an extent to which such patterns (hopefully) do exist.

None of this really goes out of the scope of the charter but 
decisions on what is a blueprint and a clear presentation of our 
decisions will affect the clarity and usefulness of our final product.

Ken

At 01:51 PM 11/22/2005, Miko Matsumura wrote:
>Yes and there is the charter to consider:
>
>This essentially defines a blueprint as a business problem statement,
>set of requirements and a set of functions. Perhaps not a terribly well
>specified definition, but a reasonable start point for my purposes...
>
>Text from the charter follows...
>-------------
>
>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.
>
>-----Original Message-----
>From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com]
>Sent: Tuesday, November 22, 2005 6:50 AM
>To: klaskey@mitre.org
>Cc: soa-blueprints@lists.oasis-open.org
>Subject: Re: [soa-blueprints] Primer
>
>Ken these are questions that I am sure with be concretely established by
>this tc. Here is my take (keep in mind I am on a blackberry so it might
>be more terse than normal).
>
>1. A blueprint in my mind is to establish a structure to an other wise
>disorganized approach to developing software. I have typically called
>blueprints a reference architecture (not to be confused w/reference
>model).
>
>2. Think of the scenario of buying building blueprints from a house
>designer and than having though blueprints tweaked by a local architect
>of the house. Maybe for your requirements you need the kitchen closer to
>the family room or a water closet turned into a walk in closet. Whatever
>the changes the basic structure is defined for what you need to
>accomplish building a house with N number of rooms that each have a
>function.
>
>3. To establish direction or rudder the ship. You need to establish the
>pie in the sky and a blueprint can help get a handle on that pie.
>
>4. There is a type of tracability that can be accomplished through
>following a blueprint. Also it may be important to use a third-party
>blueprint to establish a motive for changing the way a business does
>things, not sure if this applicable for everyone but there is definely
>value in having something to refer too.
>
>My take is this on the blueprint roadmap so to speak.
>
>1. Establish a couple different scenarios where services would help and
>how the service would be structured within that context and including
>supporting services.
>
>2. Take the scenarios and generalize them into patterns with some
>technology choices as and example of implementing pattern.
>
>3. Establish an overview of how all the supporting services could be
>structure to support the various patterns.
>
>It would essentially turn into a type of framework, a service could
>follow and establish the need for supporting services in a formal way.
>
>I could see it on the same lines of developing anything spring or a
>portal. You have a set of facilities that are applicable for certain
>scenarios that than could be implemented of configured appropriately.
>
>The great unknown being what business logic is performed but most of it
>could be generalized into some type of pattern. For example, transaction
>based, inquiry based, aggregation, or even everyone's favorite semantic
>service.
>
>Thoughts from the group?
>
>Dan
>
>
>
>
>-----Original Message-----
>From: Ken Laskey <klaskey@mitre.org>
>To: Marchant, Dan R. <marchadr@imc.wellsfargo.com>
>CC: soa-blueprints@lists.oasis-open.org
><soa-blueprints@lists.oasis-open.org>
>Sent: Mon Nov 21 22:42:48 2005
>Subject: Re: [soa-blueprints] Primer
>
>I have not been following the email carefully enough, so forgive me if
>this has already been established but
>
>1. Exactly what is a blueprint?
>2. What purpose does it serve?
>3. Why should I think one will be generally applicable?
>4. Why do I care?
>
>Do we expect that a blueprint will be a sort of turnkey formula?  How do
>we determine the limits of applicability for a given blueprint?  Are
>there underlying assumptions that all blueprints have in common, or is
>each blueprint fundamentally different (a very possible construction),
>or are there fundamental groupings with multiple non-redundant examples
>in each group?
>
>I think agreeing on a clear strawman definition of blueprint is
>essential.  It can be modified as we learn more but we need a clear
>starting point.
>
>Ken
>
>On Nov 21, 2005, at 9:12 PM, <marchadr@wellsfargo.com>
><marchadr@wellsfargo.com> wrote:
>
>
>
>One question to pose to the group is maybe the case study actually
>becomes a type of primer for the blueprints once the blueprints are
>defined.
>
>Thoughts?
>
>Dan
>
>
>
>
>
>---
>Ken Laskey
>MITRE Corporation, M/S H305     phone:  703-983-7934
>7515 Colshire Drive                        fax:        703-983-1379
>McLean VA 22102-7508

--
      ---------------------------------------------------------------------------------
   /   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]