[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Primer
Steve,
Good luck on the head cold :-)
The key is modularity. You can't reuse pieces if one piece is the
entire process. You can't effectively modify your process if every
change requires a rewrite of your stovepipe software.
This gets back to the question of what we mean by blueprint and what
we are writing it/them for. Do we write a detailed POS
blueprint? How reusable is that for someone not interested in
POS? Can we lay out a few generic blueprints for things like
long-running processes with structure that says, "Your company
specific piece fits here."?
So I think we mostly agree.
Ken
At 04:48 AM 11/29/2005, Jones, Steve G wrote:
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: 23 November 2005 15:40
> > To: marchadr@wellsfargo.com; jinu.joseph@polaris.co.in; soa-
> > blueprints@lists.oasis-open.org
> > Subject: RE: [soa-blueprints] Primer
> >
>
> > OK, now we're getting to some meaty issues :-)
> >
>
> > It would seem that a useful pattern would be a long-running business
> > process, where the "business" could as likely be technical as
> > commercial. What are the requirements of such a process? What
> > assumptions do we make about the process? What are the notional
> > pieces of a solution? How do these pieces notionally work
> > together? Where are there alternatives? Finally, what combination
> > of completed standards, specifications within standards committees,
> > and private specifications will likely enable such a blueprint?
>[Jones, Steve G]
>
>
>Depending on what you mean here by process I'll either massively agree or
>throw my hands up in despair :)
>
>Unfortunately I'm in Q4 Crunch at the moment so time is stretched, but on
>the Soalogic (Google aware in 3 days Dan!) business I'm looking to define
>(help would be great) the hierarchy of order to cash processes. Most IT
>efforts at the business level that I've seen fail, and which have been the
>hardest to clean up, is when IT tries to map an end to end process in its
>entirety. This fails for many reasons
>1) The process is too large and unmanageable
>2) It's the first time the business has seen its process codified, they'll
>want to change it
>3) Different parts of the organisation want to change the process in
>different ways
>
>This is why structure is (IMO) 100% required to have a successful and
>effective SOA. Taking the loan decisioning example....
>
>This is long running from the CUSTOMERS perspective but for several
>departments it's a short-lived process, and one which they want to optimise
>(e.g. credit check and scoring) on a regular basis. Thus there is a
>high-level process for tracking progression (long lived), within which each
>step is probably in itself a process, some long lived (confirmation of paper
>work), but mostly short-lived. This is where service really comes into its
>own as it provides the boundaries for both the high-level process (normally
>fairly static) and the lower level processes (often required to be dynamic)
>this differing rates of change in different parts of the organisation is a
>massive challenge if you view this as a single process.
>
>Each process step should be a service invocation therefore that has its own
>associated control and rate of change, which has a clear boundary from the
>main process, which is itself just a service offered to the customer. There
>is an interesting challenge here on how interactive processes are exposed
>and managed from a service, does the process "request" interaction with the
>user, or does it have its own contained user interface?
>
>I agree with the principle of taking a "thread" through an organisation, but
>I'd argue we should treat it more as a series of service invocations than a
>CICS transaction.
>
>
>The example below from Dan is a great one, in theory you could view the POS
>transaction as being a process that includes stock-reordering, warehouse
>management, back to manufacturing, back to the supplier etc etc. But its
>not, it's a process that has an effect that could result in other processes
>being triggered. Equally strategic budgeting effects everything in the
>business, but its an "information in", "information out" high-level command
>process.
>
>In terms of standards WS-Contract (pre,post,invariant) would be a welcome
>addition!
>
>Steve (with a massive head cold)
>
>
>
> >
>
> > Note, part of the output of this thought process could be feedback to
> > existing committees on what is needed from their specs or how the
> > process needs to be curtailed to fit the current and evolving standards.
> >
>
> > Ken
> >
>
> > At 10:24 AM 11/23/2005, marchadr@wellsfargo.com wrote:
> > >Jinu these are good points.
> > >
> > >Something I would say to this would be that in most implementations
> > >of SOA there are basic structures that could be followed with the
> > >variation being the actual business logic.
> > >
> > >Even within a certain space there are multiple blueprint needs.
> > >
> > >For instance,
> > >
> > >- Fulfilling a loan may be a long running process that might take
> > >into account a workflow with certain security requirements etc...
> > >
> > >- While making a wires transfer would have to be highly available
> > >and have routing based on fraud and security rules without the need
> > >of long running process
> > >
> > >
> > >To apply them to some of the cases within the soalogic approach you
> > >could see the following:
> > >1. Based on the process of developing a product within soalogic they
> > >need a managed long running process. This pattern without the
> > >specific business logic could be applied to the loan case. Or could
> > >even be applied to strategic budget planning, etc...
> > >
> > >2. The retail store is using a pos process that needs to be secure
> > >and have fraud detection for purchases made by the customer this
> > >could be applied without the specific business logic to a wire transfer
> > case.
> > >
> > >The actual blueprints could be extracted for 1 that state:
> > >- WS-BPEL - manage the long running process
> > >- Transport types that could apply (HTTP/HTTPS/MQ)
> > >- WS-Security - for managing who is able to update from a client
> > >auth perspective
> > >- WS-Coordination - to coordinate with different SORs
> > >- WS-Notification - to alert either an operation or customer service
> > >agent of an issue within the process through an intermediary service
> > >- WS-Profile - for indentify the service
> > >- WS-CAF - to provide context around who the requestor is
> > >- Fault Management - how and what type of responses would happen,
> > >sending an WSN event?
> > >- XACML - for determining the rights of the user invoking the service
> > >- etc...
> > >
> > >So what you end up doing is creating a stack of patterns that could
> > >be applied to a problem area that involves long running operations
> > >or short fast operations, etc...
> > >
> > >Of course the specific technology may not be decided upon within the
> > >blueprint but the concepts within WS-BPEL will be abstracted with an
> > >example implementation of how WS-BPEL fulfills the specific request.
> > >Essentially think of the types of services you have ever created and
> > >think about a lot of the common problems you had to solve along the
> > >way to get specific business logic to be invoked within a service
> > >context. There are a lot of problems that are common across
> > >implementations such as security, event management, auditing, even
> > >in some cases accounting to chargeback for a service invocation to a
> > >specific customer or internal client. Some of these could be in a
> > >ESB or some could reside with the service and it may be worthwhile
> > >to come up with a sample deployment for each blueprint that may
> > >determine the type of system needs associated with the blueprint.
> > >
> > >I'll try and come up with an example at the end of the week or next
> > >week so you don't think I am crazy :)
> > >
> > >- Dan
> > >
> > >
> > >-----Original Message-----
> > >From: jinu.joseph@polaris.co.in [mailto:jinu.joseph@polaris.co.in]
> > >Sent: Tuesday, November 22, 2005 7:58 PM
> > >To: soa-blueprints@lists.oasis-open.org
> > >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
> > >System.
> > >
> > >- 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 ??
> > >
> > >Regards
> > >Jinu Joseph
> > >Polaris Software Lab Ltd
> > >e-mail: jinu.joseph@polaris.co.in
> > >
> > >
> > >
> > >
> > > <marchadr@wellsf
> > >
> > > 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
> > > AM
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >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?
> > >
> > > 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
> > > /
> > >
> > >
> > >-------------------------------------------------------------------------
> > ---------
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >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
> >
>
> > --
> > --------------------------------------------------------------------
> > -------------
> > / Ken
> > Laskey \
> > | MITRE Corporation, M/S H305 phone: 703-983-7934 |
> > | 7515 Colshire Drive fax: 703-983-1379 |
> > \ McLean VA 22102-7508 /
> > ---------------------------------------------------------------------
> > -------------
> >
>
>
>
>This message contains information that may be privileged or
>confidential and is the property of the Capgemini Group. It is
>intended only for the person to whom it is addressed. If you are not
>the intended recipient, you are not authorized to read, print,
>retain, copy, disseminate, distribute, or use this message or any
>part thereof. If you receive this message in error, please notify
>the sender immediately and delete all copies of this message.
--
---------------------------------------------------------------------------------
/ 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]