"Ginny" <techni***@peoplewareindia.com> wrote in message
news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
> In a service oriented architecture, an application can call an external
> servie. an alternate approach is to use message based technique. following
> are the points that need calrifications??
>
> 1. how does message based approach help?
> 2. the .net application architecture guide says that, the message based
> approcah can make the design of you business logic independent of the
> underlying transport protocol used between services. HOW?
> 3. In a message based approach you need to take care of special
> considerations as message correlation, optimistic data concurrency
> management,business process compensation, and external service
> unavailability. What r all these ??
>
> --
> Regards
> Ginny
>
>

"Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
> Hello Ginny,
> You appear to be a little confused.  SOA is a high level architectural
> approach to distributed systems design.  What you appear to be referring
> to as 'message based approach' is a subset of the SOA approach that uses
> long running transactions.  It is still SOA.
>
>> 1. how does message based approach help?
>
> Long running transactions and messaging solve a particularly difficult
> design problem: how to simplify the code around the state machine and
> seperate it from the rest of the system for easy modification.  The state
> machine is traditionally a problem.  In the early days of Computer
> Science, greats like Djikstra and Turing recognized the immense power of
> state machines.  The Turing Machine is, itself, a state machine that is
> able to simulate the computational capabilities of any modern computer.
> The problem is twofold: 1) our declarative programming languages are lousy
> for describing and maintaining state machines. There are a great deal of
> practical considerations to take into account that are not built in to the
> error handling structures, branching structures, and even data type
> declarations.  2) state machines change a lot.  When done properly, a
> large portion of the business rules end up embedded in a state machine.
> Therefore they need to be encapsulated from the rest of the system.
>
> In many cases, developers who know little about state machines avoid the
> problem.  You don't have to use a state machine.  Most problems can be
> solved without state machines, by adding a ten-fold increase in code and
> complexity.  But hey, if you only have a hammer, every problem is a nail.
> Those of us who understood the power of the state machine have always
> sought out ways to reduce code, and increase elegance, by implementing
> state machines in our systems.  Nice thing: in the age of the web and
> stateless transaction models, this has required developers to place all of
> the stateful aspects of the system in one place... which has done more to
> drive the sophistication of state machine tools than any amount of
> salesmanship or marketing could ever have.  It's a golden time.
>
> Message based approaches are the way you can understand how to drive a
> state machine.  A message is input to a state.
>
> Message oriented middleware tools have increased in sophistication
> steadily in the past four years.  Look at the huge efforts being spent to
> improve ESB tools and Biztalk.  Look at the efforts to describe temporal
> relationships in the WS_* standards.
>
>> 2. the .net application architecture guide says that, the message based
>> approcah can make the design of you business logic independent of the
>> underlying transport protocol used between services. HOW?
>
> If you take a message based approach, in your service oriented
> architecture, it means that you start by isolating your state machine into
> a service component.  In a normal scenario, that state machine does not
> need to actually implement the business logic.  It implements that state
> transitions and temporal error handling.  By 'temporal error handling',
> I'm not referring to an episode of Star Trek or Dr. Who.  I'm talking
> about the fact that messages drive state machines, so they have an
> inherent order to them. In a banking system, a message to open an account
> needs to arrive before the message that asks for the balance on the
> account.  Being able to say: this message makes sense now, but didn't make
> sense a minute ago, is a temporal consideration because of the time
> relationship with another message.
>
> None of this has anything at all to do with the transport protocol.  If I
> send a message using SOAP or REST or by dropping commands into a SQL Queue
> or even in a file system, the state machine is the logic that understands
> the message and responds, not the logic that finds and transmits the
> message. That is what is meant by this independence.  Sticking with
> standards helps.
>
>> 3. In a message based approach you need to take care of special
>> considerations as message correlation, optimistic data concurrency
>> management,business process compensation, and external service
>> unavailability. What r all these ??
>
> * Message correlation - two messages arrive seperately, but they drive a
> single state machine.  Find the machine.  Then apply the message.  It is
> like understanding the difference between a class and an instance of an
> object.  A class defines the machine, but the instance is the machine.
> When a message comes in, you have to find the instance that it applies to.
> Therefore, you need some kind of ID that you pass in the messages, and
> that all asynchronous collaborators agree to pass back to you, allowing
> you to correlate.
>
> It's not as esoteric as it sounds.  Your insurance card is a message
> correlation id.  You get sick.  You go to the doctor.  She pulls your
> chart and examines you.  She draws blood.  She sends the blood to a lab
> for analysis.  You go home and await your results.  The doctors office
> puts the file back in the filing cabinet.  The lab gets the blood.  It has
> your ID on it.  They test the blood.  You are going to be fine.  They send
> back the results with your ID.  The doctor's office gets the result, and
> pulls your chart back out of the filing cabinet.  They see that you are
> waiting for a call, so they ask the doctor to call you.  [when they looked
> at the id and decided to pull your chart, they were doing message
> correlation.  The lab is stateless].
>
> * optimistic data concurrency management - In a long running transaction,
> you cannot lock DB records.  Two-phase commit mechanisms assume
> synchronous communication mechanisms, so you cannot use them either... at
> least not in the pure sense.  So you have to take data transformation into
> account, often by understanding the effect of messages on data.  It is a
> design activity as much as it is a runtime algorithm.
>
> Let's say that an employee requests a week of vacation.  The company has a
> policy that reads like this: "The employee can request time off if they
> have already accumulated it.  Check accumulation first.  If there is
> sufficient accumulation to allow the request, then send it to the manager
> for approval".  Great.  Now Joe has six days built up.  He wants to take
> off either the last week of November or the last week of December.  So he
> sends two requests, each for a week.
>
> His first request goes through just fine.  It is sent to his manager.
> What about the second?  Do we introduce a way of saying that the first
> five days of vacation are "committed to an inflight transaction" with the
> ability to roll it back if the manager doesn't approve it?  In other
> words, do we deny the second request before it gets to the manager?  An
> alternate approach may be to do a simple check and send the second request
> to the manager as well. If the manager approves one, but not the other, no
> problems... because only one will be marked as 'planned and approved time
> off' while the other request disappears.  What happens if the manager
> approves both?  Does the first one in the door win?  How do you coordinate
> informing the manager that he approved two but only one went through the
> system?  This is optimistic data concurrency management.
>
> * Compensation.  I mentioned an compensation scenario above.  Let's say
> that we choose the first alternative.  We have a seperate counter for the
> number of hours requested but not yet approved.  This means the second
> request is rejected by the system without going to the manager.  Now,
> let's say that the manager decides to reject the request.  We cannot roll
> back the original transaction.  That would be silly.  It may be days have
> passed.  No, we deduct the requested hours from the seperate counter.
> Now, if the employee submits the second request, it will go through to the
> manager for consideration.  This whole notion of having a seperate
> counter, and then removing hours from it, is a compensation design.  It is
> there to handle 'rollback' of a request that didn't make it through the
> system.
>
> * External service unavailability:  As I mentioned above, the state
> machine doesn't do more than simply coordinate things.  So if a customer
> requests to buy 1500 units of a really complex part from a manufacturing
> company, there's a lot of coordinating to do.  What is the bill of
> materials?  Are all the parts ready to ship or do some need to be built?
> How long will it take to manufacture and deliver parts?  Once delivered,
> what's the manufacturing backlog on constructing the finished part?  Does
> this timeline meet the PO requirements?  All this logic can be pulled into
> the state machine.  (We sometimes refer to this as the 'orchestration' or
> the 'workflow').  However, the logic to decide if all the parts are ready
> to ship can be complicated and may require queries to multiple systems.
> Let's say that your bill of materials is managed in one legacy system,
> while your inventory is managed in another.  Now, let's say that a PO
> arrives and the inventory system is down for scheduled maintenance (you
> are swapping out the network cards to upgrade to a 1GB backbone in that
> data center).  The orchestration asks for inventory data.  No response
> comes back.  What do you do?
>
> Your messaging system has to know how to hold a transaction request until
> the receiving system is back up, and then to resume the flow.  Biztalk
> allows for retry and automatic dehydration.  Other systems queue the
> message and wait for a signal that the receiver is back online.  It's a
> distinction that becomes important if you don't want to lose that message.
> This is a huge deal.  If you don't have these mechanisms, then the failure
> rate of the orchestration is the maximum overlap of the failures of the
> remote systems. WIth this mechanism, the failure rate of the orchestration
> is the minimum overlap between retry policy and the remote systems...
> often very near to zero.  You go from a very unreliable machine to a very
> reliable one.
>
> I hope this helps.  Final word: message based processing is not outside
> SOA. It is part of it.  In the SOA I am working in, we have message based
> services as part of the infrastructure.
> --
> --- Nick Malik [Microsoft]
>    MCSD, CFPS, Certified Scrummaster
>    http://blogs.msdn.com/nickmalik
>
> Disclaimer: Opinions expressed in this forum are my own, and not
> representative of my employer.
>   I do not answer questions on behalf of my employer.  I'm just a
> programmer helping programmers.
> --
> "Ginny" <techni***@peoplewareindia.com> wrote in message
> news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
>> In a service oriented architecture, an application can call an external
>> servie. an alternate approach is to use message based technique.
>> following
>> are the points that need calrifications??
>>
>> 1. how does message based approach help?
>> 2. the .net application architecture guide says that, the message based
>> approcah can make the design of you business logic independent of the
>> underlying transport protocol used between services. HOW?
>> 3. In a message based approach you need to take care of special
>> considerations as message correlation, optimistic data concurrency
>> management,business process compensation, and external service
>> unavailability. What r all these ??
>>
>> --
>> Regards
>> Ginny
>>
>>
>
>

"Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
> Hello Ginny,
> You appear to be a little confused.  SOA is a high level architectural
> approach to distributed systems design.  What you appear to be referring
to
> as 'message based approach' is a subset of the SOA approach that uses long
> running transactions.  It is still SOA.
>
> > 1. how does message based approach help?
>
> Long running transactions and messaging solve a particularly difficult
> design problem: how to simplify the code around the state machine and
> seperate it from the rest of the system for easy modification.  The state
> machine is traditionally a problem.  In the early days of Computer
Science,
> greats like Djikstra and Turing recognized the immense power of state
> machines.  The Turing Machine is, itself, a state machine that is able to
> simulate the computational capabilities of any modern computer.  The
problem
> is twofold: 1) our declarative programming languages are lousy for
> describing and maintaining state machines. There are a great deal of
> practical considerations to take into account that are not built in to the
> error handling structures, branching structures, and even data type
> declarations.  2) state machines change a lot.  When done properly, a
large
> portion of the business rules end up embedded in a state machine.
Therefore
> they need to be encapsulated from the rest of the system.
>
> In many cases, developers who know little about state machines avoid the
> problem.  You don't have to use a state machine.  Most problems can be
> solved without state machines, by adding a ten-fold increase in code and
> complexity.  But hey, if you only have a hammer, every problem is a nail.
> Those of us who understood the power of the state machine have always
sought
> out ways to reduce code, and increase elegance, by implementing state
> machines in our systems.  Nice thing: in the age of the web and stateless
> transaction models, this has required developers to place all of the
> stateful aspects of the system in one place... which has done more to
drive
> the sophistication of state machine tools than any amount of salesmanship
or
> marketing could ever have.  It's a golden time.
>
> Message based approaches are the way you can understand how to drive a
state
> machine.  A message is input to a state.
>
> Message oriented middleware tools have increased in sophistication
steadily
> in the past four years.  Look at the huge efforts being spent to improve
ESB
> tools and Biztalk.  Look at the efforts to describe temporal relationships
> in the WS_* standards.
>
> > 2. the .net application architecture guide says that, the message based
> > approcah can make the design of you business logic independent of the
> > underlying transport protocol used between services. HOW?
>
> If you take a message based approach, in your service oriented
architecture,
> it means that you start by isolating your state machine into a service
> component.  In a normal scenario, that state machine does not need to
> actually implement the business logic.  It implements that state
transitions
> and temporal error handling.  By 'temporal error handling', I'm not
> referring to an episode of Star Trek or Dr. Who.  I'm talking about the
fact
> that messages drive state machines, so they have an inherent order to
them.
> In a banking system, a message to open an account needs to arrive before
the
> message that asks for the balance on the account.  Being able to say: this
> message makes sense now, but didn't make sense a minute ago, is a temporal
> consideration because of the time relationship with another message.
>
> None of this has anything at all to do with the transport protocol.  If I
> send a message using SOAP or REST or by dropping commands into a SQL Queue
> or even in a file system, the state machine is the logic that understands
> the message and responds, not the logic that finds and transmits the
> message. That is what is meant by this independence.  Sticking with
> standards helps.
>
> > 3. In a message based approach you need to take care of special
> > considerations as message correlation, optimistic data concurrency
> > management,business process compensation, and external service
> > unavailability. What r all these ??
>
> * Message correlation - two messages arrive seperately, but they drive a
> single state machine.  Find the machine.  Then apply the message.  It is
> like understanding the difference between a class and an instance of an
> object.  A class defines the machine, but the instance is the machine.
When
> a message comes in, you have to find the instance that it applies to.
> Therefore, you need some kind of ID that you pass in the messages, and
that
> all asynchronous collaborators agree to pass back to you, allowing you to
> correlate.
>
> It's not as esoteric as it sounds.  Your insurance card is a message
> correlation id.  You get sick.  You go to the doctor.  She pulls your
chart
> and examines you.  She draws blood.  She sends the blood to a lab for
> analysis.  You go home and await your results.  The doctors office puts
the
> file back in the filing cabinet.  The lab gets the blood.  It has your ID
on
> it.  They test the blood.  You are going to be fine.  They send back the
> results with your ID.  The doctor's office gets the result, and pulls your
> chart back out of the filing cabinet.  They see that you are waiting for a
> call, so they ask the doctor to call you.  [when they looked at the id and
> decided to pull your chart, they were doing message correlation.  The lab
is
> stateless].
>
> * optimistic data concurrency management - In a long running transaction,
> you cannot lock DB records.  Two-phase commit mechanisms assume
synchronous
> communication mechanisms, so you cannot use them either... at least not in
> the pure sense.  So you have to take data transformation into account,
often
> by understanding the effect of messages on data.  It is a design activity
as
> much as it is a runtime algorithm.
>
> Let's say that an employee requests a week of vacation.  The company has a
> policy that reads like this: "The employee can request time off if they
have
> already accumulated it.  Check accumulation first.  If there is sufficient
> accumulation to allow the request, then send it to the manager for
> approval".  Great.  Now Joe has six days built up.  He wants to take off
> either the last week of November or the last week of December.  So he
sends
> two requests, each for a week.
>
> His first request goes through just fine.  It is sent to his manager.
What
> about the second?  Do we introduce a way of saying that the first five
days
> of vacation are "committed to an inflight transaction" with the ability to
> roll it back if the manager doesn't approve it?  In other words, do we
deny
> the second request before it gets to the manager?  An alternate approach
may
> be to do a simple check and send the second request to the manager as
well.
> If the manager approves one, but not the other, no problems... because
only
> one will be marked as 'planned and approved time off' while the other
> request disappears.  What happens if the manager approves both?  Does the
> first one in the door win?  How do you coordinate informing the manager
that
> he approved two but only one went through the system?  This is optimistic
> data concurrency management.
>
> * Compensation.  I mentioned an compensation scenario above.  Let's say
that
> we choose the first alternative.  We have a seperate counter for the
number
> of hours requested but not yet approved.  This means the second request is
> rejected by the system without going to the manager.  Now, let's say that
> the manager decides to reject the request.  We cannot roll back the
original
> transaction.  That would be silly.  It may be days have passed.  No, we
> deduct the requested hours from the seperate counter.  Now, if the
employee
> submits the second request, it will go through to the manager for
> consideration.  This whole notion of having a seperate counter, and then
> removing hours from it, is a compensation design.  It is there to handle
> 'rollback' of a request that didn't make it through the system.
>
> * External service unavailability:  As I mentioned above, the state
machine
> doesn't do more than simply coordinate things.  So if a customer requests
to
> buy 1500 units of a really complex part from a manufacturing company,
> there's a lot of coordinating to do.  What is the bill of materials?  Are
> all the parts ready to ship or do some need to be built?  How long will it
> take to manufacture and deliver parts?  Once delivered, what's the
> manufacturing backlog on constructing the finished part?  Does this
timeline
> meet the PO requirements?  All this logic can be pulled into the state
> machine.  (We sometimes refer to this as the 'orchestration' or the
> 'workflow').  However, the logic to decide if all the parts are ready to
> ship can be complicated and may require queries to multiple systems. Let's
> say that your bill of materials is managed in one legacy system, while
your
> inventory is managed in another.  Now, let's say that a PO arrives and the
> inventory system is down for scheduled maintenance (you are swapping out
the
> network cards to upgrade to a 1GB backbone in that data center).  The
> orchestration asks for inventory data.  No response comes back.  What do
you
> do?
>
> Your messaging system has to know how to hold a transaction request until
> the receiving system is back up, and then to resume the flow.  Biztalk
> allows for retry and automatic dehydration.  Other systems queue the
message
> and wait for a signal that the receiver is back online.  It's a
distinction
> that becomes important if you don't want to lose that message.  This is a
> huge deal.  If you don't have these mechanisms, then the failure rate of
the
> orchestration is the maximum overlap of the failures of the remote
systems.
> WIth this mechanism, the failure rate of the orchestration is the minimum
> overlap between retry policy and the remote systems... often very near to
> zero.  You go from a very unreliable machine to a very reliable one.
>
> I hope this helps.  Final word: message based processing is not outside
SOA.
> It is part of it.  In the SOA I am working in, we have message based
> services as part of the infrastructure.
> --
> --- Nick Malik [Microsoft]
>     MCSD, CFPS, Certified Scrummaster
>     http://blogs.msdn.com/nickmalik
>
> Disclaimer: Opinions expressed in this forum are my own, and not
> representative of my employer.
>    I do not answer questions on behalf of my employer.  I'm just a
> programmer helping programmers.
> --
> "Ginny" <techni***@peoplewareindia.com> wrote in message
> news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
> > In a service oriented architecture, an application can call an external
> > servie. an alternate approach is to use message based technique.
following
> > are the points that need calrifications??
> >
> > 1. how does message based approach help?
> > 2. the .net application architecture guide says that, the message based
> > approcah can make the design of you business logic independent of the
> > underlying transport protocol used between services. HOW?
> > 3. In a message based approach you need to take care of special
> > considerations as message correlation, optimistic data concurrency
> > management,business process compensation, and external service
> > unavailability. What r all these ??
> >
> > --
> > Regards
> > Ginny
> >
> >
>
>

"Ginny" <techni***@peoplewareindia.com> wrote in message
news:eQ0G7$PuGHA.4336@TK2MSFTNGP06.phx.gbl...
> Dear Nick,
> Thanks a lot for your efforts. I am reading more on SOA to understand your
> answer as well :) I have some small questions, if you can assist again:
> 1. What is coarse-grained interfaces compared to chatty interfaces for
> remote communication
> 2. What is meant by loose coupling and high cohesion?
> 3. Can you send me a link of a good article on SOA?
>
> Regards
> Ginny
> "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
> news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
>> Hello Ginny,
>> You appear to be a little confused.  SOA is a high level architectural
>> approach to distributed systems design.  What you appear to be referring
> to
>> as 'message based approach' is a subset of the SOA approach that uses
>> long
>> running transactions.  It is still SOA.
>>
>> > 1. how does message based approach help?
>>
>> Long running transactions and messaging solve a particularly difficult
>> design problem: how to simplify the code around the state machine and
>> seperate it from the rest of the system for easy modification.  The state
>> machine is traditionally a problem.  In the early days of Computer
> Science,
>> greats like Djikstra and Turing recognized the immense power of state
>> machines.  The Turing Machine is, itself, a state machine that is able to
>> simulate the computational capabilities of any modern computer.  The
> problem
>> is twofold: 1) our declarative programming languages are lousy for
>> describing and maintaining state machines. There are a great deal of
>> practical considerations to take into account that are not built in to
>> the
>> error handling structures, branching structures, and even data type
>> declarations.  2) state machines change a lot.  When done properly, a
> large
>> portion of the business rules end up embedded in a state machine.
> Therefore
>> they need to be encapsulated from the rest of the system.
>>
>> In many cases, developers who know little about state machines avoid the
>> problem.  You don't have to use a state machine.  Most problems can be
>> solved without state machines, by adding a ten-fold increase in code and
>> complexity.  But hey, if you only have a hammer, every problem is a nail.
>> Those of us who understood the power of the state machine have always
> sought
>> out ways to reduce code, and increase elegance, by implementing state
>> machines in our systems.  Nice thing: in the age of the web and stateless
>> transaction models, this has required developers to place all of the
>> stateful aspects of the system in one place... which has done more to
> drive
>> the sophistication of state machine tools than any amount of salesmanship
> or
>> marketing could ever have.  It's a golden time.
>>
>> Message based approaches are the way you can understand how to drive a
> state
>> machine.  A message is input to a state.
>>
>> Message oriented middleware tools have increased in sophistication
> steadily
>> in the past four years.  Look at the huge efforts being spent to improve
> ESB
>> tools and Biztalk.  Look at the efforts to describe temporal
>> relationships
>> in the WS_* standards.
>>
>> > 2. the .net application architecture guide says that, the message based
>> > approcah can make the design of you business logic independent of the
>> > underlying transport protocol used between services. HOW?
>>
>> If you take a message based approach, in your service oriented
> architecture,
>> it means that you start by isolating your state machine into a service
>> component.  In a normal scenario, that state machine does not need to
>> actually implement the business logic.  It implements that state
> transitions
>> and temporal error handling.  By 'temporal error handling', I'm not
>> referring to an episode of Star Trek or Dr. Who.  I'm talking about the
> fact
>> that messages drive state machines, so they have an inherent order to
> them.
>> In a banking system, a message to open an account needs to arrive before
> the
>> message that asks for the balance on the account.  Being able to say:
>> this
>> message makes sense now, but didn't make sense a minute ago, is a
>> temporal
>> consideration because of the time relationship with another message.
>>
>> None of this has anything at all to do with the transport protocol.  If I
>> send a message using SOAP or REST or by dropping commands into a SQL
>> Queue
>> or even in a file system, the state machine is the logic that understands
>> the message and responds, not the logic that finds and transmits the
>> message. That is what is meant by this independence.  Sticking with
>> standards helps.
>>
>> > 3. In a message based approach you need to take care of special
>> > considerations as message correlation, optimistic data concurrency
>> > management,business process compensation, and external service
>> > unavailability. What r all these ??
>>
>> * Message correlation - two messages arrive seperately, but they drive a
>> single state machine.  Find the machine.  Then apply the message.  It is
>> like understanding the difference between a class and an instance of an
>> object.  A class defines the machine, but the instance is the machine.
> When
>> a message comes in, you have to find the instance that it applies to.
>> Therefore, you need some kind of ID that you pass in the messages, and
> that
>> all asynchronous collaborators agree to pass back to you, allowing you to
>> correlate.
>>
>> It's not as esoteric as it sounds.  Your insurance card is a message
>> correlation id.  You get sick.  You go to the doctor.  She pulls your
> chart
>> and examines you.  She draws blood.  She sends the blood to a lab for
>> analysis.  You go home and await your results.  The doctors office puts
> the
>> file back in the filing cabinet.  The lab gets the blood.  It has your ID
> on
>> it.  They test the blood.  You are going to be fine.  They send back the
>> results with your ID.  The doctor's office gets the result, and pulls
>> your
>> chart back out of the filing cabinet.  They see that you are waiting for
>> a
>> call, so they ask the doctor to call you.  [when they looked at the id
>> and
>> decided to pull your chart, they were doing message correlation.  The lab
> is
>> stateless].
>>
>> * optimistic data concurrency management - In a long running transaction,
>> you cannot lock DB records.  Two-phase commit mechanisms assume
> synchronous
>> communication mechanisms, so you cannot use them either... at least not
>> in
>> the pure sense.  So you have to take data transformation into account,
> often
>> by understanding the effect of messages on data.  It is a design activity
> as
>> much as it is a runtime algorithm.
>>
>> Let's say that an employee requests a week of vacation.  The company has
>> a
>> policy that reads like this: "The employee can request time off if they
> have
>> already accumulated it.  Check accumulation first.  If there is
>> sufficient
>> accumulation to allow the request, then send it to the manager for
>> approval".  Great.  Now Joe has six days built up.  He wants to take off
>> either the last week of November or the last week of December.  So he
> sends
>> two requests, each for a week.
>>
>> His first request goes through just fine.  It is sent to his manager.
> What
>> about the second?  Do we introduce a way of saying that the first five
> days
>> of vacation are "committed to an inflight transaction" with the ability
>> to
>> roll it back if the manager doesn't approve it?  In other words, do we
> deny
>> the second request before it gets to the manager?  An alternate approach
> may
>> be to do a simple check and send the second request to the manager as
> well.
>> If the manager approves one, but not the other, no problems... because
> only
>> one will be marked as 'planned and approved time off' while the other
>> request disappears.  What happens if the manager approves both?  Does the
>> first one in the door win?  How do you coordinate informing the manager
> that
>> he approved two but only one went through the system?  This is optimistic
>> data concurrency management.
>>
>> * Compensation.  I mentioned an compensation scenario above.  Let's say
> that
>> we choose the first alternative.  We have a seperate counter for the
> number
>> of hours requested but not yet approved.  This means the second request
>> is
>> rejected by the system without going to the manager.  Now, let's say that
>> the manager decides to reject the request.  We cannot roll back the
> original
>> transaction.  That would be silly.  It may be days have passed.  No, we
>> deduct the requested hours from the seperate counter.  Now, if the
> employee
>> submits the second request, it will go through to the manager for
>> consideration.  This whole notion of having a seperate counter, and then
>> removing hours from it, is a compensation design.  It is there to handle
>> 'rollback' of a request that didn't make it through the system.
>>
>> * External service unavailability:  As I mentioned above, the state
> machine
>> doesn't do more than simply coordinate things.  So if a customer requests
> to
>> buy 1500 units of a really complex part from a manufacturing company,
>> there's a lot of coordinating to do.  What is the bill of materials?  Are
>> all the parts ready to ship or do some need to be built?  How long will
>> it
>> take to manufacture and deliver parts?  Once delivered, what's the
>> manufacturing backlog on constructing the finished part?  Does this
> timeline
>> meet the PO requirements?  All this logic can be pulled into the state
>> machine.  (We sometimes refer to this as the 'orchestration' or the
>> 'workflow').  However, the logic to decide if all the parts are ready to
>> ship can be complicated and may require queries to multiple systems.
>> Let's
>> say that your bill of materials is managed in one legacy system, while
> your
>> inventory is managed in another.  Now, let's say that a PO arrives and
>> the
>> inventory system is down for scheduled maintenance (you are swapping out
> the
>> network cards to upgrade to a 1GB backbone in that data center).  The
>> orchestration asks for inventory data.  No response comes back.  What do
> you
>> do?
>>
>> Your messaging system has to know how to hold a transaction request until
>> the receiving system is back up, and then to resume the flow.  Biztalk
>> allows for retry and automatic dehydration.  Other systems queue the
> message
>> and wait for a signal that the receiver is back online.  It's a
> distinction
>> that becomes important if you don't want to lose that message.  This is a
>> huge deal.  If you don't have these mechanisms, then the failure rate of
> the
>> orchestration is the maximum overlap of the failures of the remote
> systems.
>> WIth this mechanism, the failure rate of the orchestration is the minimum
>> overlap between retry policy and the remote systems... often very near to
>> zero.  You go from a very unreliable machine to a very reliable one.
>>
>> I hope this helps.  Final word: message based processing is not outside
> SOA.
>> It is part of it.  In the SOA I am working in, we have message based
>> services as part of the infrastructure.
>> --
>> --- Nick Malik [Microsoft]
>>     MCSD, CFPS, Certified Scrummaster
>>     http://blogs.msdn.com/nickmalik
>>
>> Disclaimer: Opinions expressed in this forum are my own, and not
>> representative of my employer.
>>    I do not answer questions on behalf of my employer.  I'm just a
>> programmer helping programmers.
>> --
>> "Ginny" <techni***@peoplewareindia.com> wrote in message
>> news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
>> > In a service oriented architecture, an application can call an external
>> > servie. an alternate approach is to use message based technique.
> following
>> > are the points that need calrifications??
>> >
>> > 1. how does message based approach help?
>> > 2. the .net application architecture guide says that, the message based
>> > approcah can make the design of you business logic independent of the
>> > underlying transport protocol used between services. HOW?
>> > 3. In a message based approach you need to take care of special
>> > considerations as message correlation, optimistic data concurrency
>> > management,business process compensation, and external service
>> > unavailability. What r all these ??
>> >
>> > --
>> > Regards
>> > Ginny
>> >
>> >
>>
>>
>
>

"Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message
news:O7c68VRuGHA.2036@TK2MSFTNGP05.phx.gbl...
> Ginny,
>
> #1 It is the difference between sending one big message verse many small
> messages.
>
>  I believe #2 was alrady answerred for you in another post
>
> with http://en.wikipedia.org/wiki/Loose_coupling and
> http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
>
> for #3 there are alot of goob books/articles on SOA I would personally
> recommend
>

> Service-Oriented Architecture (SOA): Concepts, Technology, and Design,
> Thomas Erl
>
>
> "Ginny" <techni***@peoplewareindia.com> wrote in message
> news:eQ0G7$PuGHA.4336@TK2MSFTNGP06.phx.gbl...
> > Dear Nick,
> > Thanks a lot for your efforts. I am reading more on SOA to understand
your
> > answer as well :) I have some small questions, if you can assist again:
> > 1. What is coarse-grained interfaces compared to chatty interfaces for
> > remote communication
> > 2. What is meant by loose coupling and high cohesion?
> > 3. Can you send me a link of a good article on SOA?
> >
> > Regards
> > Ginny
> > "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message
> > news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
> >> Hello Ginny,
> >> You appear to be a little confused.  SOA is a high level architectural
> >> approach to distributed systems design.  What you appear to be
referring
> > to
> >> as 'message based approach' is a subset of the SOA approach that uses
> >> long
> >> running transactions.  It is still SOA.
> >>
> >> > 1. how does message based approach help?
> >>
> >> Long running transactions and messaging solve a particularly difficult
> >> design problem: how to simplify the code around the state machine and
> >> seperate it from the rest of the system for easy modification.  The
state
> >> machine is traditionally a problem.  In the early days of Computer
> > Science,
> >> greats like Djikstra and Turing recognized the immense power of state
> >> machines.  The Turing Machine is, itself, a state machine that is able
to
> >> simulate the computational capabilities of any modern computer.  The
> > problem
> >> is twofold: 1) our declarative programming languages are lousy for
> >> describing and maintaining state machines. There are a great deal of
> >> practical considerations to take into account that are not built in to
> >> the
> >> error handling structures, branching structures, and even data type
> >> declarations.  2) state machines change a lot.  When done properly, a
> > large
> >> portion of the business rules end up embedded in a state machine.
> > Therefore
> >> they need to be encapsulated from the rest of the system.
> >>
> >> In many cases, developers who know little about state machines avoid
the
> >> problem.  You don't have to use a state machine.  Most problems can be
> >> solved without state machines, by adding a ten-fold increase in code
and
> >> complexity.  But hey, if you only have a hammer, every problem is a
nail.
> >> Those of us who understood the power of the state machine have always
> > sought
> >> out ways to reduce code, and increase elegance, by implementing state
> >> machines in our systems.  Nice thing: in the age of the web and
stateless
> >> transaction models, this has required developers to place all of the
> >> stateful aspects of the system in one place... which has done more to
> > drive
> >> the sophistication of state machine tools than any amount of
salesmanship
> > or
> >> marketing could ever have.  It's a golden time.
> >>
> >> Message based approaches are the way you can understand how to drive a
> > state
> >> machine.  A message is input to a state.
> >>
> >> Message oriented middleware tools have increased in sophistication
> > steadily
> >> in the past four years.  Look at the huge efforts being spent to
improve
> > ESB
> >> tools and Biztalk.  Look at the efforts to describe temporal
> >> relationships
> >> in the WS_* standards.
> >>
> >> > 2. the .net application architecture guide says that, the message
based
> >> > approcah can make the design of you business logic independent of the
> >> > underlying transport protocol used between services. HOW?
> >>
> >> If you take a message based approach, in your service oriented
> > architecture,
> >> it means that you start by isolating your state machine into a service
> >> component.  In a normal scenario, that state machine does not need to
> >> actually implement the business logic.  It implements that state
> > transitions
> >> and temporal error handling.  By 'temporal error handling', I'm not
> >> referring to an episode of Star Trek or Dr. Who.  I'm talking about the
> > fact
> >> that messages drive state machines, so they have an inherent order to
> > them.
> >> In a banking system, a message to open an account needs to arrive
before
> > the
> >> message that asks for the balance on the account.  Being able to say:
> >> this
> >> message makes sense now, but didn't make sense a minute ago, is a
> >> temporal
> >> consideration because of the time relationship with another message.
> >>
> >> None of this has anything at all to do with the transport protocol.  If
I
> >> send a message using SOAP or REST or by dropping commands into a SQL
> >> Queue
> >> or even in a file system, the state machine is the logic that
understands
> >> the message and responds, not the logic that finds and transmits the
> >> message. That is what is meant by this independence.  Sticking with
> >> standards helps.
> >>
> >> > 3. In a message based approach you need to take care of special
> >> > considerations as message correlation, optimistic data concurrency
> >> > management,business process compensation, and external service
> >> > unavailability. What r all these ??
> >>
> >> * Message correlation - two messages arrive seperately, but they drive
a
> >> single state machine.  Find the machine.  Then apply the message.  It
is
> >> like understanding the difference between a class and an instance of an
> >> object.  A class defines the machine, but the instance is the machine.
> > When
> >> a message comes in, you have to find the instance that it applies to.
> >> Therefore, you need some kind of ID that you pass in the messages, and
> > that
> >> all asynchronous collaborators agree to pass back to you, allowing you
to
> >> correlate.
> >>
> >> It's not as esoteric as it sounds.  Your insurance card is a message
> >> correlation id.  You get sick.  You go to the doctor.  She pulls your
> > chart
> >> and examines you.  She draws blood.  She sends the blood to a lab for
> >> analysis.  You go home and await your results.  The doctors office puts
> > the
> >> file back in the filing cabinet.  The lab gets the blood.  It has your
ID
> > on
> >> it.  They test the blood.  You are going to be fine.  They send back
the
> >> results with your ID.  The doctor's office gets the result, and pulls
> >> your
> >> chart back out of the filing cabinet.  They see that you are waiting
for
> >> a
> >> call, so they ask the doctor to call you.  [when they looked at the id
> >> and
> >> decided to pull your chart, they were doing message correlation.  The
lab
> > is
> >> stateless].
> >>
> >> * optimistic data concurrency management - In a long running
transaction,
> >> you cannot lock DB records.  Two-phase commit mechanisms assume
> > synchronous
> >> communication mechanisms, so you cannot use them either... at least not
> >> in
> >> the pure sense.  So you have to take data transformation into account,
> > often
> >> by understanding the effect of messages on data.  It is a design
activity
> > as
> >> much as it is a runtime algorithm.
> >>
> >> Let's say that an employee requests a week of vacation.  The company
has
> >> a
> >> policy that reads like this: "The employee can request time off if they
> > have
> >> already accumulated it.  Check accumulation first.  If there is
> >> sufficient
> >> accumulation to allow the request, then send it to the manager for
> >> approval".  Great.  Now Joe has six days built up.  He wants to take
off
> >> either the last week of November or the last week of December.  So he
> > sends
> >> two requests, each for a week.
> >>
> >> His first request goes through just fine.  It is sent to his manager.
> > What
> >> about the second?  Do we introduce a way of saying that the first five
> > days
> >> of vacation are "committed to an inflight transaction" with the ability
> >> to
> >> roll it back if the manager doesn't approve it?  In other words, do we
> > deny
> >> the second request before it gets to the manager?  An alternate
approach
> > may
> >> be to do a simple check and send the second request to the manager as
> > well.
> >> If the manager approves one, but not the other, no problems... because
> > only
> >> one will be marked as 'planned and approved time off' while the other
> >> request disappears.  What happens if the manager approves both?  Does
the
> >> first one in the door win?  How do you coordinate informing the manager
> > that
> >> he approved two but only one went through the system?  This is
optimistic
> >> data concurrency management.
> >>
> >> * Compensation.  I mentioned an compensation scenario above.  Let's say
> > that
> >> we choose the first alternative.  We have a seperate counter for the
> > number
> >> of hours requested but not yet approved.  This means the second request
> >> is
> >> rejected by the system without going to the manager.  Now, let's say
that
> >> the manager decides to reject the request.  We cannot roll back the
> > original
> >> transaction.  That would be silly.  It may be days have passed.  No, we
> >> deduct the requested hours from the seperate counter.  Now, if the
> > employee
> >> submits the second request, it will go through to the manager for
> >> consideration.  This whole notion of having a seperate counter, and
then
> >> removing hours from it, is a compensation design.  It is there to
handle
> >> 'rollback' of a request that didn't make it through the system.
> >>
> >> * External service unavailability:  As I mentioned above, the state
> > machine
> >> doesn't do more than simply coordinate things.  So if a customer
requests
> > to
> >> buy 1500 units of a really complex part from a manufacturing company,
> >> there's a lot of coordinating to do.  What is the bill of materials?
Are
> >> all the parts ready to ship or do some need to be built?  How long will
> >> it
> >> take to manufacture and deliver parts?  Once delivered, what's the
> >> manufacturing backlog on constructing the finished part?  Does this
> > timeline
> >> meet the PO requirements?  All this logic can be pulled into the state
> >> machine.  (We sometimes refer to this as the 'orchestration' or the
> >> 'workflow').  However, the logic to decide if all the parts are ready
to
> >> ship can be complicated and may require queries to multiple systems.
> >> Let's
> >> say that your bill of materials is managed in one legacy system, while
> > your
> >> inventory is managed in another.  Now, let's say that a PO arrives and
> >> the
> >> inventory system is down for scheduled maintenance (you are swapping
out
> > the
> >> network cards to upgrade to a 1GB backbone in that data center).  The
> >> orchestration asks for inventory data.  No response comes back.  What
do
> > you
> >> do?
> >>
> >> Your messaging system has to know how to hold a transaction request
until
> >> the receiving system is back up, and then to resume the flow.  Biztalk
> >> allows for retry and automatic dehydration.  Other systems queue the
> > message
> >> and wait for a signal that the receiver is back online.  It's a
> > distinction
> >> that becomes important if you don't want to lose that message.  This is
a
> >> huge deal.  If you don't have these mechanisms, then the failure rate
of
> > the
> >> orchestration is the maximum overlap of the failures of the remote
> > systems.
> >> WIth this mechanism, the failure rate of the orchestration is the
minimum
> >> overlap between retry policy and the remote systems... often very near
to
> >> zero.  You go from a very unreliable machine to a very reliable one.
> >>
> >> I hope this helps.  Final word: message based processing is not outside
> > SOA.
> >> It is part of it.  In the SOA I am working in, we have message based
> >> services as part of the infrastructure.
> >> --
> >> --- Nick Malik [Microsoft]
> >>     MCSD, CFPS, Certified Scrummaster
> >>     http://blogs.msdn.com/nickmalik
> >>
> >> Disclaimer: Opinions expressed in this forum are my own, and not
> >> representative of my employer.
> >>    I do not answer questions on behalf of my employer.  I'm just a
> >> programmer helping programmers.
> >> --
> >> "Ginny" <techni***@peoplewareindia.com> wrote in message
> >> news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
> >> > In a service oriented architecture, an application can call an
external
> >> > servie. an alternate approach is to use message based technique.
> > following
> >> > are the points that need calrifications??
> >> >
> >> > 1. how does message based approach help?
> >> > 2. the .net application architecture guide says that, the message
based
> >> > approcah can make the design of you business logic independent of the
> >> > underlying transport protocol used between services. HOW?
> >> > 3. In a message based approach you need to take care of special
> >> > considerations as message correlation, optimistic data concurrency
> >> > management,business process compensation, and external service
> >> > unavailability. What r all these ??
> >> >
> >> > --
> >> > Regards
> >> > Ginny
> >> >
> >> >
> >>
> >>
> >
> >
>
>

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:%23jfJSXWuGHA.452@TK2MSFTNGP05.phx.gbl...
> Ginny wrote:
> > Hi Greg,
> > There are no examples of loose coupling and high cohesion. The links
> > only talk about the definition. With the definition, its a little clear
to
> > me. But i was looking for an example, probably on .net realted to
> > loose coupling and high cohesion, to get the concepts throughly clear.
> > Like for exapmple, you mentioned that coarse grained means a number
> > of small messages and chatty-interfaces means a big message,
>
> No, you got that backwards:  Coarse grained means a few large messages
while
> chatty means a large number of small messages.
>
> > now how does it actually affect the
> > remote communication. What are the advantages of coarse grained over
> > chatty-interfaces. MS has used these jargons in their guides but with no
> > explanation at all. Furthermore, nothing much is available on net
> > also with  examples. Definitions are everywhere. So I was looking for
> > some practical examples to get the concepts clear.
>
> Here's an example, still conceptual.
>
> Imagine that you need to enter a sales order into a remote system.  A
chatty
> solution would be to expose a remote API (via web services or whatever)
with
> functions like:
>
> CreateCustomer
> CreateSalesOrder
> CreateLineItem
> SetSalesOrderAddress
> SetSalesOrderBillingInfo
> ...
>
> while a coarse-grained approach would expose just a single function:
>
> CreateSalesOrder
>
> which would take a number of aggregates as parameters (e.g. a struct with
> customer info, an array of structs with address info, an array of structs
> with line-item info, etc).   Internally, this function would likely
delegate
> the work to a fine-grained API like the one above.
>
> The impact for a remoting scenario is that fewer round-trips are made
across
> the network.  This generally results in three desirable outcomes.
>
> First, the total amount of network traffic is reduced, since you incur the
> basic overhead of a single round-trip only once.
>
> Second, the overall latency of the process is reduced, since when a client
> is using the "chatty" interface, the steps are generally interlocked, so
one
> operation cannot begin before the previous one finishes - so the network
> latency of a round-trip is effectively inserted between each pair of
> consequtive operations.
>
> Third, a coarse-grained API like this is more ammenable to asynchronous
> invocation.  Since the request contains all of the information to complete
> the job in a single chunk, a client can wait asynchronously for the result
> without having to build any complex asynchronous state machine - which
would
> be necessary to call the chatty version of the interface asynchronously.
>
> HTH
>
> -cd
>
>

"Ginny" <techni***@peoplewareindia.com> wrote in message
news:e2LhFVXuGHA.4852@TK2MSFTNGP02.phx.gbl...
> Thanks Carl, thats real clear. Can you also help me to understand loose
> coupling and high cohesion with a smilar example?
>
> regards
>
> "Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
> wrote in message news:%23jfJSXWuGHA.452@TK2MSFTNGP05.phx.gbl...
>> Ginny wrote:
>> > Hi Greg,
>> > There are no examples of loose coupling and high cohesion. The links
>> > only talk about the definition. With the definition, its a little clear
> to
>> > me. But i was looking for an example, probably on .net realted to
>> > loose coupling and high cohesion, to get the concepts throughly clear.
>> > Like for exapmple, you mentioned that coarse grained means a number
>> > of small messages and chatty-interfaces means a big message,
>>
>> No, you got that backwards:  Coarse grained means a few large messages
> while
>> chatty means a large number of small messages.
>>
>> > now how does it actually affect the
>> > remote communication. What are the advantages of coarse grained over
>> > chatty-interfaces. MS has used these jargons in their guides but with
>> > no
>> > explanation at all. Furthermore, nothing much is available on net
>> > also with  examples. Definitions are everywhere. So I was looking for
>> > some practical examples to get the concepts clear.
>>
>> Here's an example, still conceptual.
>>
>> Imagine that you need to enter a sales order into a remote system.  A
> chatty
>> solution would be to expose a remote API (via web services or whatever)
> with
>> functions like:
>>
>> CreateCustomer
>> CreateSalesOrder
>> CreateLineItem
>> SetSalesOrderAddress
>> SetSalesOrderBillingInfo
>> ...
>>
>> while a coarse-grained approach would expose just a single function:
>>
>> CreateSalesOrder
>>
>> which would take a number of aggregates as parameters (e.g. a struct with
>> customer info, an array of structs with address info, an array of structs
>> with line-item info, etc).   Internally, this function would likely
> delegate
>> the work to a fine-grained API like the one above.
>>
>> The impact for a remoting scenario is that fewer round-trips are made
> across
>> the network.  This generally results in three desirable outcomes.
>>
>> First, the total amount of network traffic is reduced, since you incur
>> the
>> basic overhead of a single round-trip only once.
>>
>> Second, the overall latency of the process is reduced, since when a
>> client
>> is using the "chatty" interface, the steps are generally interlocked, so
> one
>> operation cannot begin before the previous one finishes - so the network
>> latency of a round-trip is effectively inserted between each pair of
>> consequtive operations.
>>
>> Third, a coarse-grained API like this is more ammenable to asynchronous
>> invocation.  Since the request contains all of the information to
>> complete
>> the job in a single chunk, a client can wait asynchronously for the
>> result
>> without having to build any complex asynchronous state machine - which
> would
>> be necessary to call the chatty version of the interface asynchronously.
>>
>> HTH
>>
>> -cd
>>
>>
>
>

"Ginny" <techni***@peoplewareindia.com> wrote in message
news:%2304AbzTuGHA.4160@TK2MSFTNGP06.phx.gbl...
> Hi Greg,
> There are no examples of loose coupling and high cohesion. The links only
> talk about the definition. With the definition, its a little clear to me.
> But i was looking for an example, probably on .net realted to loose
> coupling
> and high cohesion, to get the concepts throughly clear. Like for exapmple,
> you mentioned that coarse grained means a number of small messages and
> chatty-interfaces means a big message, now how does it actually affect the
> remote communication. What are the advantages of coarse grained over
> chatty-interfaces. MS has used these jargons in their guides but with no
> explanation at all. Furthermore, nothing much is available on net also
> with
> examples. Definitions are everywhere. So I was looking for some practical
> examples to get the concepts clear.
>
> Regards
>
> "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message
> news:O7c68VRuGHA.2036@TK2MSFTNGP05.phx.gbl...
>> Ginny,
>>
>> #1 It is the difference between sending one big message verse many small
>> messages.
>>
>>  I believe #2 was alrady answerred for you in another post
>>
>> with http://en.wikipedia.org/wiki/Loose_coupling and
>> http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
>>
>> for #3 there are alot of goob books/articles on SOA I would personally
>> recommend
>>
> http://www.amazon.com/gp/product/0131858580/sr=8-1/qid=1154840472/ref=pd_bbs_1/104-4532018-6004701?ie=UTF8
>> Service-Oriented Architecture (SOA): Concepts, Technology, and Design,
>> Thomas Erl
>>
>>
>> "Ginny" <techni***@peoplewareindia.com> wrote in message
>> news:eQ0G7$PuGHA.4336@TK2MSFTNGP06.phx.gbl...
>> > Dear Nick,
>> > Thanks a lot for your efforts. I am reading more on SOA to understand
> your
>> > answer as well :) I have some small questions, if you can assist again:
>> > 1. What is coarse-grained interfaces compared to chatty interfaces for
>> > remote communication
>> > 2. What is meant by loose coupling and high cohesion?
>> > 3. Can you send me a link of a good article on SOA?
>> >
>> > Regards
>> > Ginny
>> > "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in
>> > message
>> > news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
>> >> Hello Ginny,
>> >> You appear to be a little confused.  SOA is a high level architectural
>> >> approach to distributed systems design.  What you appear to be
> referring
>> > to
>> >> as 'message based approach' is a subset of the SOA approach that uses
>> >> long
>> >> running transactions.  It is still SOA.
>> >>
>> >> > 1. how does message based approach help?
>> >>
>> >> Long running transactions and messaging solve a particularly difficult
>> >> design problem: how to simplify the code around the state machine and
>> >> seperate it from the rest of the system for easy modification.  The
> state
>> >> machine is traditionally a problem.  In the early days of Computer
>> > Science,
>> >> greats like Djikstra and Turing recognized the immense power of state
>> >> machines.  The Turing Machine is, itself, a state machine that is able
> to
>> >> simulate the computational capabilities of any modern computer.  The
>> > problem
>> >> is twofold: 1) our declarative programming languages are lousy for
>> >> describing and maintaining state machines. There are a great deal of
>> >> practical considerations to take into account that are not built in to
>> >> the
>> >> error handling structures, branching structures, and even data type
>> >> declarations.  2) state machines change a lot.  When done properly, a
>> > large
>> >> portion of the business rules end up embedded in a state machine.
>> > Therefore
>> >> they need to be encapsulated from the rest of the system.
>> >>
>> >> In many cases, developers who know little about state machines avoid
> the
>> >> problem.  You don't have to use a state machine.  Most problems can be
>> >> solved without state machines, by adding a ten-fold increase in code
> and
>> >> complexity.  But hey, if you only have a hammer, every problem is a
> nail.
>> >> Those of us who understood the power of the state machine have always
>> > sought
>> >> out ways to reduce code, and increase elegance, by implementing state
>> >> machines in our systems.  Nice thing: in the age of the web and
> stateless
>> >> transaction models, this has required developers to place all of the
>> >> stateful aspects of the system in one place... which has done more to
>> > drive
>> >> the sophistication of state machine tools than any amount of
> salesmanship
>> > or
>> >> marketing could ever have.  It's a golden time.
>> >>
>> >> Message based approaches are the way you can understand how to drive a
>> > state
>> >> machine.  A message is input to a state.
>> >>
>> >> Message oriented middleware tools have increased in sophistication
>> > steadily
>> >> in the past four years.  Look at the huge efforts being spent to
> improve
>> > ESB
>> >> tools and Biztalk.  Look at the efforts to describe temporal
>> >> relationships
>> >> in the WS_* standards.
>> >>
>> >> > 2. the .net application architecture guide says that, the message
> based
>> >> > approcah can make the design of you business logic independent of
>> >> > the
>> >> > underlying transport protocol used between services. HOW?
>> >>
>> >> If you take a message based approach, in your service oriented
>> > architecture,
>> >> it means that you start by isolating your state machine into a service
>> >> component.  In a normal scenario, that state machine does not need to
>> >> actually implement the business logic.  It implements that state
>> > transitions
>> >> and temporal error handling.  By 'temporal error handling', I'm not
>> >> referring to an episode of Star Trek or Dr. Who.  I'm talking about
>> >> the
>> > fact
>> >> that messages drive state machines, so they have an inherent order to
>> > them.
>> >> In a banking system, a message to open an account needs to arrive
> before
>> > the
>> >> message that asks for the balance on the account.  Being able to say:
>> >> this
>> >> message makes sense now, but didn't make sense a minute ago, is a
>> >> temporal
>> >> consideration because of the time relationship with another message.
>> >>
>> >> None of this has anything at all to do with the transport protocol.
>> >> If
> I
>> >> send a message using SOAP or REST or by dropping commands into a SQL
>> >> Queue
>> >> or even in a file system, the state machine is the logic that
> understands
>> >> the message and responds, not the logic that finds and transmits the
>> >> message. That is what is meant by this independence.  Sticking with
>> >> standards helps.
>> >>
>> >> > 3. In a message based approach you need to take care of special
>> >> > considerations as message correlation, optimistic data concurrency
>> >> > management,business process compensation, and external service
>> >> > unavailability. What r all these ??
>> >>
>> >> * Message correlation - two messages arrive seperately, but they drive
> a
>> >> single state machine.  Find the machine.  Then apply the message.  It
> is
>> >> like understanding the difference between a class and an instance of
>> >> an
>> >> object.  A class defines the machine, but the instance is the machine.
>> > When
>> >> a message comes in, you have to find the instance that it applies to.
>> >> Therefore, you need some kind of ID that you pass in the messages, and
>> > that
>> >> all asynchronous collaborators agree to pass back to you, allowing you
> to
>> >> correlate.
>> >>
>> >> It's not as esoteric as it sounds.  Your insurance card is a message
>> >> correlation id.  You get sick.  You go to the doctor.  She pulls your
>> > chart
>> >> and examines you.  She draws blood.  She sends the blood to a lab for
>> >> analysis.  You go home and await your results.  The doctors office
>> >> puts
>> > the
>> >> file back in the filing cabinet.  The lab gets the blood.  It has your
> ID
>> > on
>> >> it.  They test the blood.  You are going to be fine.  They send back
> the
>> >> results with your ID.  The doctor's office gets the result, and pulls
>> >> your
>> >> chart back out of the filing cabinet.  They see that you are waiting
> for
>> >> a
>> >> call, so they ask the doctor to call you.  [when they looked at the id
>> >> and
>> >> decided to pull your chart, they were doing message correlation.  The
> lab
>> > is
>> >> stateless].
>> >>
>> >> * optimistic data concurrency management - In a long running
> transaction,
>> >> you cannot lock DB records.  Two-phase commit mechanisms assume
>> > synchronous
>> >> communication mechanisms, so you cannot use them either... at least
>> >> not
>> >> in
>> >> the pure sense.  So you have to take data transformation into account,
>> > often
>> >> by understanding the effect of messages on data.  It is a design
> activity
>> > as
>> >> much as it is a runtime algorithm.
>> >>
>> >> Let's say that an employee requests a week of vacation.  The company
> has
>> >> a
>> >> policy that reads like this: "The employee can request time off if
>> >> they
>> > have
>> >> already accumulated it.  Check accumulation first.  If there is
>> >> sufficient
>> >> accumulation to allow the request, then send it to the manager for
>> >> approval".  Great.  Now Joe has six days built up.  He wants to take
> off
>> >> either the last week of November or the last week of December.  So he
>> > sends
>> >> two requests, each for a week.
>> >>
>> >> His first request goes through just fine.  It is sent to his manager.
>> > What
>> >> about the second?  Do we introduce a way of saying that the first five
>> > days
>> >> of vacation are "committed to an inflight transaction" with the
>> >> ability
>> >> to
>> >> roll it back if the manager doesn't approve it?  In other words, do we
>> > deny
>> >> the second request before it gets to the manager?  An alternate
> approach
>> > may
>> >> be to do a simple check and send the second request to the manager as
>> > well.
>> >> If the manager approves one, but not the other, no problems... because
>> > only
>> >> one will be marked as 'planned and approved time off' while the other
>> >> request disappears.  What happens if the manager approves both?  Does
> the
>> >> first one in the door win?  How do you coordinate informing the
>> >> manager
>> > that
>> >> he approved two but only one went through the system?  This is
> optimistic
>> >> data concurrency management.
>> >>
>> >> * Compensation.  I mentioned an compensation scenario above.  Let's
>> >> say
>> > that
>> >> we choose the first alternative.  We have a seperate counter for the
>> > number
>> >> of hours requested but not yet approved.  This means the second
>> >> request
>> >> is
>> >> rejected by the system without going to the manager.  Now, let's say
> that
>> >> the manager decides to reject the request.  We cannot roll back the
>> > original
>> >> transaction.  That would be silly.  It may be days have passed.  No,
>> >> we
>> >> deduct the requested hours from the seperate counter.  Now, if the
>> > employee
>> >> submits the second request, it will go through to the manager for
>> >> consideration.  This whole notion of having a seperate counter, and
> then
>> >> removing hours from it, is a compensation design.  It is there to
> handle
>> >> 'rollback' of a request that didn't make it through the system.
>> >>
>> >> * External service unavailability:  As I mentioned above, the state
>> > machine
>> >> doesn't do more than simply coordinate things.  So if a customer
> requests
>> > to
>> >> buy 1500 units of a really complex part from a manufacturing company,
>> >> there's a lot of coordinating to do.  What is the bill of materials?
> Are
>> >> all the parts ready to ship or do some need to be built?  How long
>> >> will
>> >> it
>> >> take to manufacture and deliver parts?  Once delivered, what's the
>> >> manufacturing backlog on constructing the finished part?  Does this
>> > timeline
>> >> meet the PO requirements?  All this logic can be pulled into the state
>> >> machine.  (We sometimes refer to this as the 'orchestration' or the
>> >> 'workflow').  However, the logic to decide if all the parts are ready
> to
>> >> ship can be complicated and may require queries to multiple systems.
>> >> Let's
>> >> say that your bill of materials is managed in one legacy system, while
>> > your
>> >> inventory is managed in another.  Now, let's say that a PO arrives and
>> >> the
>> >> inventory system is down for scheduled maintenance (you are swapping
> out
>> > the
>> >> network cards to upgrade to a 1GB backbone in that data center).  The
>> >> orchestration asks for inventory data.  No response comes back.  What
> do
>> > you
>> >> do?
>> >>
>> >> Your messaging system has to know how to hold a transaction request
> until
>> >> the receiving system is back up, and then to resume the flow.  Biztalk
>> >> allows for retry and automatic dehydration.  Other systems queue the
>> > message
>> >> and wait for a signal that the receiver is back online.  It's a
>> > distinction
>> >> that becomes important if you don't want to lose that message.  This
>> >> is
> a
>> >> huge deal.  If you don't have these mechanisms, then the failure rate
> of
>> > the
>> >> orchestration is the maximum overlap of the failures of the remote
>> > systems.
>> >> WIth this mechanism, the failure rate of the orchestration is the
> minimum
>> >> overlap between retry policy and the remote systems... often very near
> to
>> >> zero.  You go from a very unreliable machine to a very reliable one.
>> >>
>> >> I hope this helps.  Final word: message based processing is not
>> >> outside
>> > SOA.
>> >> It is part of it.  In the SOA I am working in, we have message based
>> >> services as part of the infrastructure.
>> >> --
>> >> --- Nick Malik [Microsoft]
>> >>     MCSD, CFPS, Certified Scrummaster
>> >>     http://blogs.msdn.com/nickmalik
>> >>
>> >> Disclaimer: Opinions expressed in this forum are my own, and not
>> >> representative of my employer.
>> >>    I do not answer questions on behalf of my employer.  I'm just a
>> >> programmer helping programmers.
>> >> --
>> >> "Ginny" <techni***@peoplewareindia.com> wrote in message
>> >> news:ewVDF%23IuGHA.4472@TK2MSFTNGP02.phx.gbl...
>> >> > In a service oriented architecture, an application can call an
> external
>> >> > servie. an alternate approach is to use message based technique.
>> > following
>> >> > are the points that need calrifications??
>> >> >
>> >> > 1. how does message based approach help?
>> >> > 2. the .net application architecture guide says that, the message
> based
>> >> > approcah can make the design of you business logic independent of
>> >> > the
>> >> > underlying transport protocol used between services. HOW?
>> >> > 3. In a message based approach you need to take care of special
>> >> > considerations as message correlation, optimistic data concurrency
>> >> > management,business process compensation, and external service
>> >> > unavailability. What r all these ??
>> >> >
>> >> > --
>> >> > Regards
>> >> > Ginny
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

"Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message
news:ekQ6jXbuGHA.4968@TK2MSFTNGP03.phx.gbl...
> I see CD has already answerred some of this but ...
>
> >What are the advantages of coarse grained over
> >chatty-interfaces. MS has used these jargons in their guides but with no
> >explanation at all.
>
> That is because these are computer science concepts, they do not just
belong
> to microsoft.
>
>
> "Ginny" <techni***@peoplewareindia.com> wrote in message
> news:%2304AbzTuGHA.4160@TK2MSFTNGP06.phx.gbl...
> > Hi Greg,
> > There are no examples of loose coupling and high cohesion. The links
only
> > talk about the definition. With the definition, its a little clear to
me.
> > But i was looking for an example, probably on .net realted to loose
> > coupling
> > and high cohesion, to get the concepts throughly clear. Like for
exapmple,
> > you mentioned that coarse grained means a number of small messages and
> > chatty-interfaces means a big message, now how does it actually affect
the
> > remote communication. What are the advantages of coarse grained over
> > chatty-interfaces. MS has used these jargons in their guides but with no
> > explanation at all. Furthermore, nothing much is available on net also
> > with
> > examples. Definitions are everywhere. So I was looking for some
practical
> > examples to get the concepts clear.
> >
> > Regards
> >
> > "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message
> > news:O7c68VRuGHA.2036@TK2MSFTNGP05.phx.gbl...
> >> Ginny,
> >>
> >> #1 It is the difference between sending one big message verse many
small
> >> messages.
> >>
> >>  I believe #2 was alrady answerred for you in another post
> >>
> >> with http://en.wikipedia.org/wiki/Loose_coupling and
> >> http://en.wikipedia.org/wiki/Coupling_%28computer_science%29
> >>
> >> for #3 there are alot of goob books/articles on SOA I would personally
> >> recommend
> >>
> >

> >> Service-Oriented Architecture (SOA): Concepts, Technology, and Design,
> >> Thomas Erl
> >>
> >>
> >> "Ginny" <techni***@peoplewareindia.com> wrote in message
> >> news:eQ0G7$PuGHA.4336@TK2MSFTNGP06.phx.gbl...
> >> > Dear Nick,
> >> > Thanks a lot for your efforts. I am reading more on SOA to understand
> > your
> >> > answer as well :) I have some small questions, if you can assist
again:
> >> > 1. What is coarse-grained interfaces compared to chatty interfaces
for
> >> > remote communication
> >> > 2. What is meant by loose coupling and high cohesion?
> >> > 3. Can you send me a link of a good article on SOA?
> >> >
> >> > Regards
> >> > Ginny
> >> > "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in
> >> > message
> >> > news:0r6dnfa9ee4CIUnZnZ2dnUVZ_oydnZ2d@comcast.com...
> >> >> Hello Ginny,
> >> >> You appear to be a little confused.  SOA is a high level
architectural
> >> >> approach to distributed systems design.  What you appear to be
> > referring
> >> > to
> >> >> as 'message based approach' is a subset of the SOA approach that
uses
> >> >> long
> >> >> running transactions.  It is still SOA.
> >> >>
> >> >> > 1. how does message based approach help?
> >> >>
> >> >> Long running transactions and messaging solve a particularly
difficult
> >> >> design problem: how to simplify the code around the state machine
and
> >> >> seperate it from the rest of the system for easy modification.  The
> > state
> >> >> machine is traditionally a problem.  In the early days of Computer
> >> > Science,
> >> >> greats like Djikstra and Turing recognized the immense power of
state
> >> >> machines.  The Turing Machine is, itself, a state machine that is
able
> > to
> >> >> simulate the computational capabilities of any modern computer.  The
> >> > problem
> >> >> is twofold: 1) our declarative programming languages are lousy for
> >> >> describing and maintaining state machines. There are a great deal of
> >> >> practical considerations to take into account that are not built in
to
> >> >> the
> >> >> error handling structures, branching structures, and even data type
> >> >> declarations.  2) state machines change a lot.  When done properly,
a
> >> > large
> >> >> portion of the business rules