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

Hi Folks
I am just thinking aloud here.  I feel that while a blueprint does give a
kind of basic map while moving into uncharted territory, it still has the
following limitations

- Blueprints as discussed are limited to a category of contexts. Going by
the house analogy the blueprint i need for the house will be dependent on
who I am and where I want to build the house. If I am the President of the
United States, then I cannot build the house using the same blueprint that
you and me would use, Similarly if I would use different blueprints to
build my house in the Sahara Dessert  and my house in Antarctica. What I am
trying to say is that the Blueprint might applicable for a type of system
and may not be useable for all software systems wanting to go the SOA way.
The SOA blueprint for the Financial Services Systems used by Banks would be
different from that used by Corporates for their Inventory Management

- Trying to make a generalized blueprint will lead to such a high level of
abstraction that the blueprint itself might not be of much use. Going back
to the house analogy trying to make a generalized blueprint might lead to
the blueprint only containing guidelines like, there should be a
foundation, there should be a ceiling, there should be windows etc...

- What I feel is that we should have SOA blueprints based on software
segments such BFSI segment, ERP segment, Services like Utilities etc.

What do you say ??

Jinu Joseph
Polaris Software Lab Ltd
e-mail: jinu.joseph@polaris.co.in

                      argo.com>                To:      <klaskey@mitre.org>                                                       
                                               cc:      <soa-blueprints@lists.oasis-open.org>, (bcc: jinu.joseph/Polaris)         
                      23-11-05 03:53           Subject: RE: [soa-blueprints] Primer                                               

See comments below. Good feedback Ken.
      -----Original Message-----
      From: Ken Laskey [mailto:klaskey@mitre.org]
      Sent: Tuesday, November 22, 2005 12:07 PM
      To: Marchant, Dan R.
      Cc: soa-blueprints@lists.oasis-open.org
      Subject: Re: [soa-blueprints] Primer

      At 09:50 AM 11/22/2005, marchadr@wellsfargo.com wrote:
            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.

      You might find this analogy interesting:

      > Go back to our house analogy. The RM captures concepts related to
      > what makes up a house, e.g. room, window, door. It might include
      > the concepts of food preparation area and personal hygiene area and

      > the relationship that there should be physical separation between
      > the two. Note that this provides a very North American/western
      > Europe reference and not necessarily one that covers a tent. So a
      > given RM already provides a perspective.
      > Given RM concepts, various RAs show how these concepts can be
      > arranged in a useful pattern. So RA examples would be (sorry for
      > the American terms) a colonial, a split-level, a rambler, etc. You
      > can play with the pattern but one can say that any given pattern
      > serves a particular set of purposes (e.g. a rambler is on one level

      > for those who want/need to avoid stairs).
      > An architecture is then a specific plan to build a house or set of
      > houses. There can still be some variations but you don't do things
      > like moving fireplaces or structural walls, else you have a new
      > architecture.
      [Marchant, Dan R.] Sounds a lot like the movie "Kitchen Stories"
      about the period of time where sweden was conducting studies on the
      usability of a kitchen to identify patterns of usage. In some ways
      the development of a blueprint is similar in nature to the kitchen
      studies in the 50s.

      Is a rambler a ranch style house? I agree with the structural
      statement creating a bit of constraints that take care of the
      reduntant nature of developing an SOA. Everyone in the US probably
      has a water closet (bathroom) in the master bedroom a pattern that is
      identified based on the experience of the architects in finding the
      needs of the consumer of the house. Likewise the blueprints can
      evolve by building on the reference model.

            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.

      If you have a ship without a rudder, you are likely beyond being
      saved by a blueprint :-)

            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.

      Good points.  Now can someone craft those into a paragraph or two
      that any of us can present to a client and they would feel they know
      something they didn't know before?
      [Marchant, Dan R.]  Wiki ?

            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.

      Step 2 after you define a blueprint is to lay out how you would
      create one.  Your roadmap looks like a good initial approach, both
      for motivating a blueprint and showing how one blueprint
      can/should/might support more than one scenario.

            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?


            -----Original Message-----
            From: Ken Laskey <klaskey@mitre.org>
            To: Marchant, Dan R. <marchadr@imc.wellsfargo.com>
            CC: 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.


            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.



            Ken Laskey
            MITRE Corporation, M/S H305     phone:  703-983-7934
            7515 Colshire Drive                        fax:
            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


This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. 
If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately.
You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit Us at http://www.polaris.co.in

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