[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] To Proceed - Best Practices
I wouldn't say that this will be our first deliverable, but
I certainly be would in favor of creating more structure around the
adoption blueprints. One option which I think might work well is to use the
Genrico or SOALogic blueprint and from that start to create the rest of the
framework, which we can use for subsequent blueprints.
Theo From: Reza Shafii [mailto:rshafii@bea.com] Sent: Tuesday, January 24, 2006 15:23 To: Beack, Theo; John Harby; soa-blueprints@lists.oasis-open.org; miko@infravio.com; flinn@alum.mit.edu; marchadr@wellsfargo.com; Jones, Steve G Subject: RE: [soa-blueprints] To Proceed - Best Practices Theo, Should our first
deliverable then be a “Blueprint Adoption Standard Guideline”? Containing
templates, notation, classification, etc…? I can see a significant amount of
effort required for this work alone. Cheers, Reza From: Beack,
Theo [mailto:Theo.Beack@softwareagusa.com] Reza,
I think during
yesterday's call and the resulting conversations on the list we
are exploring several different topics, which I think is related to your
comments below. I agree that we should have some standard guidelines (+
templates, classification system, etc.) which we use for the creation of the
adoption blueprints. However, I do not
think we need a repository of SOA best practices in order to create
blueprints. In fact I think that the reverse might be true. Best practices might
start to surface out of the details of the Adoption blueprints (and resulting
real-world implementations). It is my experience
that many best practices would be implementation specific, with resulting code,
models, technology related implementation information, etc. As an example you
could have a best practice of how to secure Web Services within an app server
such as WebLogic. Such a best practice would be very specific to a certain
vendor product and implementation, which wouldn't fit into the charter of the
TC. At the same time it might be difficult to replicate or reuse the same
best practice within another implementation where a different app server is
being used. I can
also describe various other examples of quite generic best practices
that are removed from physical implementation, but before exploring these in
more detail we should consider the question; what is a best practice? Before we
can decide whether to include best practices into the TC's work we need to
define best practice, the role it will play, relationship with adoption
blueprints, how it will be used and of what value it is to the larger SOA
community. Theo From: Reza
Shafii [mailto:rshafii@bea.com] Shouldn’t a blueprint
creation guideline that gives us a common methodology/notation, classification,
and a repository of best practices (some of which could be just pointers to
existing best practices) precede the creation of individual
blueprints? Reza From: John
Harby [mailto:jharby@gmail.com] I would be in favor of a repository of best
practices that are not necessarily tied to a single blueprint but can certainly
reference one or more blueprints. On 1/24/06, Beack, Theo <Theo.Beack@softwareagusa.com>
wrote: If we decide
to include best practices under the general Adoption Blueprint "umbrella",
it would be helpful to understand the relationship between the blueprint and
associated best practices. Immediate questions I have is whether we will create
"one off" best practices related to a specific blueprint or whether we would try
to make them generic enough to be used within other blueprints. If that is the
case, do the best practices deserve to stand on their own and should we create a
classes of best practices that can be reused within Adoption Blueprints (or even
separately). Theo From: John
Harby [mailto:jharby@gmail.com] Possibly although I
think there are loopholes within the charter that would allow us to specify best
practices. Firstly, the Generico blueprint has some treatment of best practices
therefore inclusion and advancement of those is included by this
statement:
On 1/24/06, Beack, Theo <Theo.Beack@softwareagusa.com> wrote:
Don, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]