Reading this and the emails that followed, I think we need to
differentiate whether we are building blueprints that are reusable
skeletons or generating random examples. I see a framework into
which the steps of buyProduct can be assembled as being a framework but
this is the intent of BPEL. I see the specifics of buyProduct as
being an example that will be quite different for every company.
While one can argue that the former should find its way to a standard,
the latter belongs in a how-to book.
Ken
At 01:05 PM 11/29/2005, Jones, Steve G wrote:
I’ll try and add more confusion into the equation….
An example
Service “Sales” has a method “buyProduct” which takes as parameters a
Product ID and quantity (WS-Security is used to identify the
customer), this is built as a BPEL process in the following way
1)
Perform Credit Check (calls
CreditService with the customer details) – short life process
2)
Place Order with Logistics (calls the
LogisticsService with the order, returns a lead time)
3)
Return Lead time back to customer
(end of initial customer interaction)
4)
Receive notification of delivery to
Customer (event back from the LogisticsService)
5)
Invoice Customer (fires off to
FinanceService for the cash handling.
Thus the high level process (steps 1-5) is a long running process (order
of days), which acts initially to the customer as a short life process
(returning the information to the customer, before waiting for an event
to complete the full transaction by triggering another long running
process (inside FinanceService) this later element being irrelevant to
the Sales Service as it completes when it fires the event (doesn’t need
to wait for payment).
Long v short is really about user notification and state management IMO
(users need to know “DON’T WAIT IT WILL TAKE FIVE DAYS” and you don’t
want 1m state objects hanging around in memory.
Steve
From: John Harby
[
mailto:]
Sent: 29 November 2005 17:00
To:
Cc: ; Jones, Steve G; ;
Subject: Re: [soa-blueprints] Primer
I'm not very clear on this one. Suppose I have a simple scenario where an
item is scheduled for processing in a factory by assigning someone a task
in an orchestration. The processing takes several days to complete so the
process is long running temporally but the actual BPEL representing the
orchestration could be very brief. How is this long running process the
same as short processes or have I misunderstood the term "long"
here?
On 11/29/05,
<
> 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:]
Sent: Tuesday, November 29, 2005 7:15 AM
To: Marchant, Dan R.;
;
;
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,
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
<>
>To: Jones, Steve G
<
>; Marchant, Dan R.
><
>;
><
>;
><
>
>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:
]
> > > Sent: 23 November 2005 15:40
> > > To:
;
; soa-
> > >
> > > 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,
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:
[mailto:
]
> > > >Sent: Tuesday, November 22, 2005 7:58 PM
> > > >To:
> > > >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:
> > > >
> > > >
> > > >
> > > >
> > >
>
<marchadr@wellsf
> > > >
> > >
>
argo.com
>
To:
> > > >
<>
> > >
>
cc:
> > > >
<
>, (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:]
> > > > Sent: Tuesday,
November 22, 2005 12:07 PM
> > > > To: Marchant, Dan
R.
> > > > Cc:
> > > > Subject: Re:
[soa-blueprints] Primer
> > > >
> > > > At 09:50 AM
11/22/2005,
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
<>
> > >
>
To: Marchant, Dan R.
<
>
> > >
>
CC:
> > >
>
<
>
> > >
>
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,
<
>
> > >
>
<
> 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
/
----------------------------------------------------------------------------------
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
/
----------------------------------------------------------------------------------
