I
guess the question is:
Is
state the entity that is being performed upon or is it the coordination effort
attached to an entity that establishes the processes in which to
execute?
In
either situation the state is an entity that could be used by a service which
will not have the state.
Thoughts?
Dan
-----Original Message-----
From: John Harby
[mailto:]
Sent: Tuesday, November 29, 2005 10:13
AM
To:
Subject: Re:
[soa-blueprints] Primer
There is an assumption that a lead
time can be approximated. Also, where you say " you
don't want 1m state objects hanging around in memory" there are products such
as the Oracle (formerly Collaxa) offering that support "context dehydration"
which handles persistence and reincarnation of the state of long running
flows.
On 11/29/05, 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.
