Spring/spring-boot-data-geode
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Review and edit the 'Function Implementations & Executions' chapter.

Browse Source
This commit is contained in:
John Blum
2018-06-25 13:42:18 -07:00
parent b1b735f885
commit fbceb2f4dc
1 changed files with 22 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
spring-geode-docs/src/docs/asciidoc/functions.adoc
View File

@@ -12,41 +12,41 @@ typically more efficient to move the processing and computations on the predicat
perform the required computations, summarize the results and then send the reduced data set back to the client.
Additionally, when the computations are handled in parallel, across the cluster of computing resources, the operation
can be performed much faster. This typically involves intelligently organizing the data, which implies partitioning
(a.k.a. sharding) and balancing the data set across the cluster.
can be performed much faster. This typically involves intelligently organizing the data using various partitioning
(a.k.a. sharding) strategies to uniformly balance the data set across the cluster.
Well, both Apache Geode and Pivotal GemFire address this very important application concern in its
{apache-geode-docs}/developing/function_exec/chapter_overview.html[Function Execution] framework.
Spring Data for Apache Geode/Pivotal GemFire {spring-data-geode-docs-html}/#function-annotations[builds] on
this Functional framework by enable developers to {spring-data-geode-docs-html}/#function-implementation[implement]
and {spring-data-geode-docs-html}/#function-execution[execute] GemFire/Geode Functions using a very simple POJO,
annotation-based configuration model.
this Function Execution framework by enabling developers to {spring-data-geode-docs-html}/#function-implementation[implement]
and {spring-data-geode-docs-html}/#function-execution[execute] GemFire/Geode Functions using a very simple POJO-based,
annotation configuration model.
TIP: See {spring-data-geode-docs-html}/#_implementation_vs_execution[here] for the difference between
Function implementation & executions.
Taking this 1 step further, Spring Boot for Apache Geode/Pivotal GemFire _auto-configures_ and enables both Function
implementation and execution out-of-the-box, so that you can immediately begin writing Functions and invoking them
without you having to worry about all the necessary plumbing and setup. You can rest assured that it will just work
implementation and execution out-of-the-box. Therefore, you can immediately begin writing Functions and invoking them
without having to worry about all the necessary plumbing to begin with. You can rest assured that it will just work
as expected.
=== Applying Functions
Earlier, when we talked about <<geode-caching-provider, caching>>, we described a `LoanApplicationService` class
Earlier, when we talked about <<geode-caching-provider, caching>>, we described a `FinancialLoanApplicationService` class
that could process eligibility when a `Person` applied for a financial loan.
This can be a very resource intensive operation (i.e. expensive!), since it might involve collecting credit history,
employment history, information on existing, outstanding/unpaid loans, and so on and so forth. We applied caching
to not have to recompute/redetermine eligibility every time a loan office may want to review the decision with
the customer.
This can be a very resource intensive & expensive operation since it might involve collecting credit and employment
history, gathering information on existing, outstanding/unpaid loans, and so on and so forth. We applied caching
in order to not have to recompute, or redetermine eligibility every time a loan office may want to review the decision
with the customer.
But what about computing eligibility in the first place?
But what about the process of computing eligibility in the first place?
Currently the application's `LoanApplicationService` class seems to be designed to fetch the data and perform
Currently the application's `FinancialLoanApplicationService` class seems to be designed to fetch the data and perform
the eligibility determination in place. However, it might be far better to distribute the processing and even
determine eligibility for a larger group of people at once. Maybe even multiple people are involved in
a single decision, as is typically the case.
determine eligibility for a larger group of people all at once, especially when multiple, related people are involved
in a single decision, as is typically the case.
We implement an `EligibilityDeterminationFunction` class using SDG very simply as:
@@ -63,13 +63,13 @@ class EligibilityDeterminationFunction {
}
----
Using SDG's {spring-data-geode-javadoc}/org/springframework/data/gemfire/function/annotation/GemfireFunction.html[`@GemfireFunction`]
annotation, it is easy to implement our Function using a POJO method. SDG handles registering this POJO method
Using the SDG {spring-data-geode-javadoc}/org/springframework/data/gemfire/function/annotation/GemfireFunction.html[`@GemfireFunction`]
annotation, it is easy to implement our Function as a POJO method. SDG handles registering this POJO method
as a proper Function with GemFire/Geode appropriately.
If we now want to call this Function from our Spring Boot, `ClientCache` application, then we simply define
a Function Execution interface with a method name matching the Function name, and targeting the execution
on the "EligibilityDecisions" Region:
on the "_EligibilityDecisions_" Region:
.Function execution
[source,java]
@@ -82,14 +82,14 @@ interface EligibilityDeterminationExecution {
}
----
We can then inject the `EligibilityDeterminationExecution` into our `LoanApplicationService` like any other
We can then inject the `EligibilityDeterminationExecution` into our `FinancialLoanApplicationService` like any other
object/Spring bean:
.Function use
[source,java]
----
@Service
class LoanApplicationService {
class FinancialLoanApplicationService {
private final EligibilityDeterminationExecution execution;
@@ -99,9 +99,8 @@ class LoanApplicationService {
@Cacheable("EligibilityDecisions", ...)
EligibilityDecision processEligility(Person person, Timespan timespan) {
return this.execution.determineEligibility(person, timeSpan);
return this.execution.determineEligibility(person, timespan);
}
}
----