Mediator Service Engine: parallel routing and the resequencer
This was very interesting because the threading and transactions within the parallel routing rules were explained. I like to use mediator in composites, but had never encountered the need for parallel routing rules. The explanation helps especially when you look at performance issues in your composite.
The storyline about the fabric was continued nicely in the discussion about the Mediator component: Simone explained what operations were implemented by the service engine. On top of that she told us what type of threads are active when handling parallel routing rules.
Next up was the resequencer. It is a very powerful mechanism to put messages that are out of order back in sequence. The only caveat is that it is sometimes really difficult to determine the right order. Unfortunately this can't be easily solved by a tool ;)
EDN: making governance easier
Business events is a concept that is well known to E-Business Suite users. This concept has been used in SOA Suite too. It abstracts away the implementation of a the events (JMS or AQ) from the developer and (the most important feature) makes governance of events easier. Because you can keep track of the events you can subscribe to, and of the subscribers to events. This features is applied in Fusion apps and OER. During this presentation I learned a number of new things: The AQ implementation has a Java API that allows you to publish business events. Secondly, there is an extra queue for Once and Only once implementations (and it makes sense ;) ).
BPEL Service Engine: the Cube engine and idempotent invokes at Starbucks
I know the BPEL engine fairly well after doing work both in BPEL10g and BPEL11g. So I was afraid that this part would be a bit boring for me. Fortunately, it started with a section about the Cube Engine and the components of this engine. It validated the mental model in my mind and added a lot of information to it. An interesting detail about BPEL 2.0 is it generates the runtime model in memory during load(). Some things about the BPEL engine were new to me: the possibility to set an invoke to non-idempotent (causing it to dehydrate the process), and the methods from the Fabric that are implemented by the engine. Last but not least, the function of the two threads, invoke threads and engine threads were explained. This helps a great deal in tuning the performance of your BPEL engine!
In the session about correlation Simone told us about a mnemonic from Gregory Hohpe I will never forget: only the customer cares about the correlation id (your name and your drink type). The same is true for your BPEL process: Whenever you implement correlation, remember where to define it by realizing that only the 'waiting' process needs to define correlation sets, like the customer at Starbucks. The barista couldn't care less. He or she only cares about preparing the drink!
We did not have enough time for all the labs; I am going to do the resequencer lab as soon as I publish this post. However, the correlation lab and the performance lab were a lot of fun and especially the performance lab was challenging!
One thing is for sure, after today I know a lot more about the database structure and the threading models that are used by the service engines. This will make tuning a lot easier. Again, I can't wait what tomorrow will bring....
No comments:
Post a Comment