Building t=
he SOA
City – Part III: The Magic of Asynchronous Processing
By Axel Angeli and Lynton Grice
Editor’s Note: Which would you rather do? Place an order and wait, and wait,= and wait until it’s available? Or place your order, and then go about your business until your order is ready? Yep, we thought = so, too. Whether it’s an or= der for a drink or a job on our computers, we’re not inclined to sit and = wait for the final product—we like to make use of our time more productively. Axel Angeli and= Lynton Grice return to this issue to show you how asynchronous processing found in= SOA can provide a much needed sense of “place your order and return when it’s ready” that so many technology users crave.
Programmers fancy bars with service. You= enter the bar and order a beer. During the three minutes when the beer is drawn, = you can go away to do some other important things, like visiting the rest rooms= or answering another 12 emails. When you get back, the beer is waiting for you. Just imagine if there were many people wanting a beer: it wouldn’t be efficient for the bartender to take the order, prepare the beer, and then s= erve the next one. It’s better if the bartender asks all thirsty folks for their orders and then starts preparing all orders in parallel.
What a difference this is to some fast f= ood restaurants. You have to line up properly and wait for your turn to give yo= ur order. Then you have to wait until the meal is prepared (compiled) and put = on your tray. This often takes longer than a freshly drawn beer and your time = is completely wasted. You cannot leave the line and return later. The system is not prepared for it.
We have an analogous situation in our SO= A City. The pattern used by the bartender is an asynchronous process. The client submits the request to the server. Then it is up to the client whether to w= ait or do some other activities in the mean time. The fast food restaurant, however, is a de facto synchronous process, requiring the client to wait un= til the request is fully processed.
This example should make it clear that t= he asynchronous process is by far superior (in efficiency) to the synchronous process. The asynchronous process does not exclude the synchronous behavior= at all. With an asynchronous framework you can always emulate synchronous behavior: just stand-by and wait for an answer, then the behaviors are synchronous. A synchronous framework, however, requires the requester to wa= it for a reply, whether it wants it or not. Hence, an asynchronous process lea= ves it as an option to the client as to what communication strategy ‑ synchronous or asynchronous ‑ is eventually applied.
Despite the name, SOA is definitely more= than just architecture. SOA is a new paradigm, another way of thinking, a new wa= y to view application programming. SOA transforms IT landscapes from autocratic rulings into democratic governance, where market-oriented, Darwinistic principles and strategies come into play.
SOA is a collaboration infrastructure th= at allows for and encourages collaboration by making it easier to reuse common components over the Web, instead of building isolated silo solutions.
But there is one important issue to cons= ider when you work with many mutually independent and autonomous processes runni= ng on a commonly shared infrastructure. You need mechanisms that allow for pro= per ad hoc communication between the running instances. We need a well-designed architecture that guarantees a reliable transport and supervision of events. This has a dramatic consequence on the understanding of any development in = an SOA context. Programs need to assume proper responsibility to permanently a= lert the underlying infrastructure when it reaches an important step. In addition the same programs need to provide “callback agents” that allow other programs to request additional information related to the event. This= is called an “Event Driven Architecture” and one corollary of a pr= oper SOA .
Note: An event-driven architecture (EDA)=
is a
mandatory component of a full SOA.
In general, we can say that an event-driven archit=
ecture
is the technical soul of an SOA and the core component of an Enterprise Ser=
vice
Bus, which stands for the technical incarnation of a SOA
SOA Has Already Be=
en Here
For Many Years: Under the Lid
U=
nfortunately
the knowledge of the “event-driven” architectural model for
integrating large enterprise solutions is not widespread among the people w=
ho
implement ERP systems. For people who come from an electronics or
microprocessor development arena, these concepts are much more common. We c=
an
even say that all the thrilling new concepts of SOA are mostly quite old and
long-established ideas.
EDA is the oldest architectural concept = in concurrent IT. In the beginning, computers were all concurrent processors; = you had one big computer that served many jobs in parallel. All computers of the 1960’s and 1970’s were purely EDA. Only the PC revolution kicke= d us back into the Neanderthal era of computers and made the new generation beli= eve that sequential processing is the common ground. This has made EDA now appear as somethi= ng new ... which it isn't.
Those who are familiar with microprocess= ors or operating system architecture are also very familiar with event architectur= es. Every microprocessor, every RISK processor, every slightly complex silicon = chip is an EDA; it would not work otherwise. When billions of transistors need to work in harmony they cannot be sequenced in a serial processing scheme.
So, only the highest level of software d= esign is still at such a low evolutionary level that it can work in a serial, synchronous fashion. While this is true for the application design level, it already looks quite different when we look directly at the ABAP engine. The ABAP engine is full featured, highly asynchronous EDA. For instance, when y= ou save a sales order, the data is NOT written directly to the database, but t= he request is submitted to the Update Queue and an event is raised to wake up = the queue. This underlying concept of EDA is the true reason ABAP is highly rob= ust and enjoys unlimited scalability.
T= he Netweaver Java stack, however, is quite different. It is a simple an execution engine with very limited support for asynchronous processing of programs. A "misbehaving" program has the potential to bring down the whole runtime engine.
S= OA has numerous advantages, like agile development, reusability, and standard-based development. But to achieve true "loose coupling" between compone= nts, you will need to turn your attention to EDA to realize the true benefits of asynchronous communication. <= o:p>
SOA
– “Spaghetti Oriented Architecture”
Concurre=
nt and
asynchronous processing are the core principles of a stable and relia=
ble
concurrent processing architecture. Let's consider an analogy. It’s 6=
:30
am, your alarm goes off to wake you up. Your car is running on empty, so it
tells you that it needs more fuel by displaying a warning message. Your cell
phone rings, a text message arrives telling you that money has been transfe=
rred
into your bank account….the list is endless. Computers have become
pervasive. Events and alarms are all around us.
It would be laborious and inefficient to =
check
all this information in a traditional serial “one-after-the-otherR=
21;
manner. Most of these systems do not change their physical state very often.
That would mean that most of the status checks are done in vain, and contri=
bute
more to system overhead than successful system operations. The solution to =
all
this is designing the data collectors so that they "listen" in
parallel to many devices. In fact, the listeners will hibernate until an al=
arm
event wakes them up. This introduces concurrency into our scenarios.
Concurrency
is getting a lot of attention these days. The real world is based on concur=
rent
(or asynchronous) actions. The concurrent nature is also found in the
governance of an SOA. If an SOA project is not correctly implemented and
designed, it can most certainly disrupt the business. Numerous business are=
as
should be involved from the onset to ensure that services are designed with
reuse in mind. Without getting everyone involved, you may build the wrong
services or design them the wrong way, and therefore you won’t be abl=
e to
compose new business applications or processes with them. In fact, if the
services are not tested or are managed incorrectly, you may put key business
processes at risk, and the business could become more fragile.
You’ve probably heard this before; =
SOA
will make your business more agile. But what does this really mean? It means
getting all stakeholders around a table and deciding on how to design solut=
ions
so that it "may" be possible to use them again in the future. Thi=
s,
in itself, is a big undertaking, and once again requires a paradigm shift in
mindset and a solid governance policy from the top. An effective SOA requir=
es
governance, not in the sense of imperative ruling, but in finding a new way=
of
democratic collaboration between all IT users and service providers in the
whole organization.
B=
ut getting
everybody involved does not mean that everybody needs to be present all the
time. A proper strategy would rather allow everybody to develop at their own
pace and occasionally alert the teams what their current status is. From ti=
me
to time, a convent would be held to synchronize the parallel processes.
M=
ost of us
have experienced the “weekly meeting”. The team meets and it’s alwa=
ys the
same old story: endless discussions, deviations from the topic, yawning, wa=
sted
time. This begs the question If meetings are so important, why does everybo=
dy
call them inefficient? The reason is simple: Most of the discussed topics go in=
to
some peer to peer discussion. The administrator discusses some issues that =
are
not of interest to the developer; the developer wants to know about master =
data
from the sales team and bores the remaining team, etc.
W=
ouldn’t
it be if the only the sub teams that are really concerned about the topic at
hand sat together and discussed the solutions? Only the results would be
signaled to the rest, allowing them to react in exceptional cases and other=
wise
use their time in a more useful way. We’ll go back to the bar
analogy: You place your order=
and
return when what’s important to you is on the table.
S=
ame goes
for programming. It is better to delegate the individual work steps into sm=
all
and parallel tasks, then do a roundtrip to collect the results. In ERP
development, like SAP, this is seldom the case. Let’s see how SAP wou=
ld
process a simple sales order item as shown in Figure 1.
![](3D"Angeli_Grice_2007_10(MagicAsynchronousProcessing)_files/image002.gif")
F=
igure
1: Sales Order Processing in =
SAP
T=
his means
that you can calculate the price only after you determined the availability
although they might not be depend on each other. In a service-oriented
architecture, we would here identify this as a candidate for concurrent
processing. We would submit as shown in Figure 2.
![](3D"Angeli_Grice_2007_10(MagicAsynchronousProcessing)_files/image004.gif")
F=
igure
2: Concurrent Sales Order
Processing in SOA
I=
t is now
the indispensable duty of the underlying SOA to cater for mechanisms that m=
ake
the synchronization of the parallel tasks completely transparent to the
developer. And here we come to the value of a programming language. Besides=
the
fact that an SOA language must be more or less a script language to allow f=
or
“on the fly” changes to the code, the SOA language must be awar=
e of
concurrency. Unfortunately most programming languages implement this import=
ant
feature half-heartedly. If they do, they typically implement the concurrent
core as an API library that can be imported into the code.
N=
ot even in
the core competence sectors of SOA ‑ the Web development ‑ where
concurrency and asynchronous processing are rather the regular case than the
exception, do we find helpful concepts. Yes, it is very easy to build web
services. Just open up a .NET IDE and you’ll have a handful done in o=
ne
afternoon. But without proper support for concurrency, you’ll end up =
with
a different kind of SOA – “Spaghetti Oriented Architecture̶=
1;.
(An interesting, historic side note—one that “younger”
readers might not be aware of: This discussion about concurrency and its
importance already took place in the late 1970s and had been forgotten about
until now.)
And now =
another
example: Let’s say your code makes an HTTP call to some service in the
World Wide Web, but that service is currently down. What happens? Well afte=
r a
lengthy timeout, an exception will probably be appear (like a time-out
message). Then the calling program will have to handle the exception after
spending a long time waiting in vain. Normally the request works fine when =
we
refresh the page. For a programmer, things are much more difficult. First of
all, making an HTTP request is awkward in most programming languages. And
saying something like “try making an HTTP call to that servicem but if
you don’t get any response within 4 seconds, go and do something else=
and
try again later” is for the most part not a standard solution.
A=
lthough
having such robustness and flexibility it is the desired way to implement t=
he
solution, the modern programming languages still neither actively support n=
or
encourage such a programming style. There are programming languages that do=
so,
but they are still living in some niches. One very good example is the
programming language Erlang. Both direct TCP support and concurrency are pa=
rt
of the language kernel. This language has been designed to work in embedded
data communication devices like mobile phones or RFID scanners and is an
example of how a modern, reliable programming language needs to be designed.
The cunning thing about Erlang is that it is based on asynchronous processes
which lead to inherent runtime stability. Unfortunately, the great idea of
Erlang is ridiculed by obviously unreadable language syntax. Erlang is very
different to “the norm”. Erlang has been designed to be a highly
robust and reliable language, so it is doubtful that there would ever be any
big changes to the language that could introduce incompatibilities like Pyt=
hon
has recently done. And there’=
;s
the trade-off: a stable, reli=
able
and backwards compatible language is simply not compatible with rapid
development.
T=
he example
shown in Figure 3 illustrates how Erlang would handle a “timeout̶=
1;
scenario when sending some data to a socket.
<= o:p>
|
socket_client
(Str) -> {ok, Socket} =3D gen_tcp:connect(“localhost”, 4321, [b=
inary,
{packet, 2}]), &nbs=
p;
gen_tcp:send(Socket, term_to_binary(Str)), receive
{tcp,Socket,Bin} -> Val =3D binary_to_term(Bin), io:format("Client result ~p~n", [Va=
l]), gen_tcp:close(Socket) after 4000 -> io:format("Connection timed out~n",=
[]) exit(timeout) end. |
F=
igure 3:
“Erlang” Time-out Message
A=
s you can
see, we simply added a timeout to the receive statement. This sets the maxi=
mum
time that the process will wait to receive a message. So the code above says: ”Try
sending data to the socket, but after 4 seconds issue a timeout…̶=
1;
A=
BAP has
some of this, too. It has no intrinsic support of HTTP, everything is handl=
ed
through libraries, and class CL_HTTP_CLIENT is the entry point to do this. =
The
concurrency support is, however, part of the language. You may submit reque=
sts
as RFC calls in a separate task while specifying a call back routine. The
intrinsic WAIT statement, as shown in Figure 4, also allows hibernation of =
the
program until a certain Boolean condition is met. It allows the specification of a Boolean
condition that evaluates to true or false. As long the condition is false, =
the
calling program hibernates.
Wait until sy-uzeit =3D '120000'.
F=
igure
4: Wait Statement
S=
o if you
were to make a statement like the one shown in Figure 4, the program would =
halt
execution until noon and then continue.
T=
his
statement unfolds its true power when it is used with some asynchronous RFC
processing. It allows you to =
submit
the function as a separate task and later pick up the result using the RECE=
IVE
statement (see Figure 5).
F=
igure
5: RFC Function Call
W=
hen the
routine has finished, it will call the form RFC_INFO. There we can fetch the
results shown in Figure 8.
*
*
*
F=
igure
8: Receive Results from RFC
I=
n the full
ABAP example shown in Figure 9, we show a small program that submits the sa=
me
RFC function call several times in a background task. Then the program waits
until all called RFC routines report back a successful execution.
fun= ction ZLOGOS_BPEL_ASYNC_ARBITER.
*&q= uot;----------------------------------------------------------------------<= /span>
*&q= uot;*"Local Interface:
*&q= uot; IMPORTING
*&q= uot; VALUE(GUID) TYPE= BAPIGUID OPTIONAL
*&q= uot; VALUE(MESSAGE_IN) TYPE STRING DEFAULT 'Hello Wo= rld'
*&q= uot; VALUE(QNAME) TYP= E TRFCQOUT-QNAME OPTIONAL
*&q= uot; EXPORTING
*&q= uot; VALUE(MESSAGE_OU= T) TYPE STRING
*&q= uot; VALUE(START_TIME) TYPE BAPIBP_TIMESTAMP<= /p>
*&q= uot; VALUE(END_TIME) TYPE BAPIBP_TIMESTAMP<= /p>
*&q= uot; VALUE(RUNTIME) TYPE I
*&q= uot; VALUE(TID) TYPE<= span style=3D'mso-spacerun:yes'> ARFCTID
*&q= uot; VALUE(FNUM) TYPE= QRETSTATE-QRFNUM
*&q= uot;----------------------------------------------------------------------<= /span>
*
*
<= /span>get time.
end= function.
*&a= mp;---------------------------------------------------------------------*
*&a= mp; Form rfc_info
*&a= mp;---------------------------------------------------------------------*
form RFC_INFO using NAME.
*
*
*
* receive results from function 'ZLOGOS_BPEL_ASYNC_SUBPROCESS'=
receive results= from function GL-FUNCNAME
importing
MESSAGE_OU= T =3D GL-MESSAGE_OUT.
* exceptions
* SYSTEM_FAILURE =3D 1 MESSAGE GL-MESS
* COMMUNICATION_FAILURE =3D 2 MESSAGE GL-MESS.
end= form. = "rfc_info
Figure 9: Parallel Processing in ABAP
fun= ction ZLOGOS_BPEL_ASYNC_SUBPROCESS.
*&q= uot;----------------------------------------------------------------------<= /span>
*&q= uot;*"Local Interface:
*&q= uot; IMPORTING
*&q= uot; VALUE(GUID) TYPE= BAPIGUID
*&q= uot; VALUE(MESSAGE_IN) TYPE STRING
*&q= uot; EXPORTING
*&q= uot; VALUE(MESSAGE_OU= T) TYPE STRING
*&q= uot;----------------------------------------------------------------------<= /span>
end= function.
Figure 10: A sample function module to represent a
time consuming sub process
fun= ction-pool ZLOGOS_BPEL. = "MESSAGE-ID ..
typ= e-pools: ABAP.
typ= es: begin of TASK_TYPE,
*
dat= a: begin of GL,
SND_JOBS type I, &nbs= p; &= nbsp; &nbs= p; &= nbsp;
..F= UNCNAME type funcname,
*
*
loa= d-of-program.
F=
igure 11:
Global variable declarations for the examples above
A=
nother
example of how “callbacks” are done can be shown easily using
Python.
T=
he code
shown in Figure 12 says the following:
- Try connecting to ̶= 0;http://www.cnn.com” in an asynchron= ous fashion and execute a callback method when the results are available.<= o:p>
- When the HTML response =
is
received executes the CALLBACK method called “printResult”.
This will print out the HTML from “http://www.cnn.com” to the console.=
- If an error occurs duri=
ng processing
then execute the CALLBACK method called “errorHandler”,
passing in the error and printing it to the console.
- If after 5 seconds of t=
rying to
connect to “http://www.cnn.com” there is still =
no
response then issue a timeout. This is setup in the code below by using
the “callLater” method and issuing a timeout in seconds.
from twisted.web.client import getPage
from twisted.internet import reactor
def errorHandler(error):
def printResult(result):
def timeout():
def= erred =3D getPage('http://www.cnn.com/')
def= erred.addCallback(printResult)
def= erred.addErrback(errorHandler)
rea= ctor.callLater(5, timeout)
rea= ctor.run()
F=
igure
12: Python Call Backs
<= o:p>