RE: [soa-blueprints] Primer

["Miko Matsumura" <mmatsumura@infravio.com>]

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