[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Primer
at first glance, yes, but needs further consideration. At 10:49 AM 11/29/2005, marchadr@wellsfargo.com wrote: >Blackberry typo: > >If a process can trigger other processes it seems in an abstract sense >the same as a long running process. > >Since a long running process is essentially short processes >completing triggering the next process to run on a long term entity. > >Does this make a bit more sense? > >- Dan > > >-----Original Message----- >From: Ken Laskey [mailto:klaskey@mitre.org] >Sent: Tuesday, November 29, 2005 7:15 AM >To: Marchant, Dan R.; steve.g.jones@capgemini.com; >jinu.joseph@polaris.co.in; soa-blueprints@lists.oasis-open.org >Subject: Re: [soa-blueprints] Primer > > >Not sure what meant by > >If processes can trigger other processes that seems at and abstract >since the same as what a long running process is doing. > >but generally +1 > >Ken > >At 09:25 AM 11/29/2005, marchadr@wellsfargo.com wrote: > > >It seems you guys are pretty much in a greement. To sum up: > > > >1. Long running process in reality are short processes that are > >executed at different intervals > >2. Processes can trigger other processes to happen > > > >If processes can trigger other processes that seems at and abstract > >since the same as what a long running process is doing. What is > >stateful on the long running process is the entity which is acted > >upon not necessarily the process itself. > > > >Agree? > > > >- dan > > > > > > > > > >-----Original Message----- > >From: Ken Laskey <klaskey@mitre.org> > >To: Jones, Steve G <steve.g.jones@capgemini.com>; Marchant, Dan R. > ><marchadr@imc.wellsfargo.com>; jinu.joseph@polaris.co.in > ><jinu.joseph@polaris.co.in>; soa-blueprints@lists.oasis-open.org > ><soa-blueprints@lists.oasis-open.org> > >Sent: Tue Nov 29 07:31:34 2005 > >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 / > > > >------------------------------------------------------------------- > --------------- > > > >-- > >--------------------------------------------------------------------------------- > / 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]