This file can be constantly monitored by an
external process. Now, the itinerary data is send to EastAir's JMS Queue.
EastAir's JMS Queue Listener can get the itinerary information for
further processing.
Part E This part introduces the sequencing and branching properties of BPEL.
When a request for reservation is made, the BPEL process checks the
destination sector. If the destination is set to 'SFO', then the itinerary is
routed to NorthAir WS otherwise it is routed to WestAir Web Service.
Since WestAir Web Service is new, we create an identical web service using
NorthAir Web Service and name it WestAir Web Service. They do not do
any actual itinerary processing but they send a confirmation message back
to the client so we can find out which airlines service was invoked. So far
through the earlier parts of this example, we have created a sequential
process for invoking NorthAir Web Service, stored an itinerary and sent
an itinerary to a JMS physical destination. Ideally, updating the partner
airlines repository is independent of itinerary processing. In spite of failed
reservations, we update the data store for the purpose of maintaining
a waiting list (Of course without a confirmed reservation ID). Hence,
UpdateItinerary sequence is introduced as a flow branch to process
the itinerary branch, so both the sequences work in parallel.
Pages:
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186