Re: How to develop, schedule, execute, manage ADF Model layer periodical backgound threads?

[John Flack]

You might want to be a little clearer about what you are asking - a use case would help.

When you talk about background threads, I think about our batch processes, some of which run on a scheduled basis.  Since ours are very database intensive, we figure that the best execution environment is inside the database, not in the middleware.  So the older stuff uses DBMS_JOB in Oracle, while newer uses DBMS_SCHEDULER.  Some run in response to an event - where the ADF BC Application Module calls a PL/SQL procedure which in turn schedules a job for immediate execution.  Others are scheduled by time.

This works very well in our shop, where my developers are much more comfortable writing in PL/SQL than in Java.  If you have developers who on the opposite side of this continuum you may feel differently.  But there is a lot to be said for the better performance of writing anything that hits the database a lot as close to the database as possible, and eliminate the ORM and network traffic.

On Friday, June 1, 2012 7:27:03 PM UTC-4, Birol wrote:

Hello everyone, 

Is there any implementation pattern? 

Of course there can be independent of application server vendor would be perfect.

[Birol Bora]

Thanks for the answer, John.

Yes, I want to ask a question about middleware batch processes.
I do not prefer to run batch processes the database layer.
I am developing database independent(SQL-92 compliant) application.
Batch processes can be very complex and fulfills a variety of tasks.
Typical examples: closure of the accounting period, Automatic creation
of a variety of business documents(order, purchase, invoice, shipment,
costing).
Exchange of data between external systems and integration processes.
Therefore, the execution of background processes necessary middleware.
This situation raises many problems: scaling, prioritization,
monitoring, managing, etc...

Is there any example of an application?

2012/6/3 John Flack <Jo...@smdi.com>:

> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0
> Unported License (http://creativecommons.org/licenses/by/3.0/). Any content
> sourced must be attributed back to the ADF EMG with a link to the Google
> Group (http://groups.google.com/group/adf-methodology).

[Chad Thompson]

On Sunday, June 3, 2012 at 5:58 PM, Birol Bora wrote:

Thanks for the answer, John.

Yes, I want to ask a question about middleware batch processes.

I do not prefer to run batch processes the database layer.

There's a "kinda-two-way-but-only-one-way" answer to middleware batch processes that I come up with off the top of my head:

1)  There was (though apparently not at present?) an ability to schedule batch jobs (and even BPEL processes) with Oracle SOA Suite.  There's a thread about this here that has some interesting links - along with a bit of discussion about the removal of batch scheduling from SOA Suite yet making it part of Oracle apps.  (So… it depends on what your context is.  Are you a Fusion Apps user, or developing a custom app?)

https://forums.oracle.com/forums/thread.jspa?threadID=953479

(I believe AIA also has some kind of scheduling capability as well.)

2)  If you're not using "middleware" in terms of "Oracle Fusion Middleware", there is also the option (which is also the only option for standalone SOA Suite users as well) to use the commonj* WorkManager and TimerManager interfaces in WebLogic to create scheduled jobs:

http://docs.oracle.com/cd/E23943_01/web.1111/e13733/toc.htm#i1061923

… the commonj* methods could be used as part of your ADF application (as a servlet deployed along with the ADF app), or could be deployed as a separate app.

These two approaches aren't really "ADF Specific", so you might be able to find some good articles and examples in WebLogic or SOA documentation, depending on the path you follow.

-- 
Chad Thompson 
chad_t...@mac.com

[Tony Brimeyer]

Hey everyone,

What Chad said rang a bell. I spend a lot of time jumping from ADF to SOA, and I use the following pattern for scheduling SOA processes:

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/soascheduler-186798.pdf 

Granted, at its core the Java application that is created in this use case simply uses Quartz to schedule a JAX-WS Web Service (which in itself is incredibly slick), but it can be adapted to do whatever you want within the context of an ADF project (and beyond).

Very nice because it is vendor neutral. As stated in the example, there are additional configurations that need to be made when going "Highly Available", but Quartz is certainly scalar in that regard. In terms of scaling to crunch massive amounts of data, maybe a scatter-gather type solution using web services will be the most helpful. I'd be curious to see an ADF specific best practice there as well.

 

--

You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--
Tony Brimeyer | Development Services Manager
Zirous – Oracle Gold Partner
1503 42nd Street, Suite 210 | West Des Moines, IA 50266
(515) 225-9015 ext. 5552 | www.zirous.com

[John Flack]

Don't get me started about database independence - people SAY they want it, but in reality, people rarely switch databases, DB2 shops stay with DB2, Oracle shops stay with Oracle.  And when you strive for database independence, you immediately eliminate some of the things YOUR database does best - like Oracle's PL/SQL.

However, many people have this as a requirement, and people who sell software as their main line of business can justify it.  One way to have the best of both worlds is to modularize - take a module and write multiple versions of it - one for each major database, taking advantage of that database's features.

But if we're going to get generic, lets get really generic - how about having "cron" (if your servers are *nix) or the Windows scheduler kick off your batch processes.  These can be written in any language you want, including Java.  As for reports, many report servers can schedule reports to run at a particular time and deliver by e-mail, or store them to be downloaded on demand.  Some of these will run the report for the first user to request it, and subsequent requests are filled from the copy until the copy reaches a predetermined age.

[Sashika]

You can use JavaEE 6 Timer Service to schedule Middle Tier Jobs. Then again You might need to maintain a separate JavaEE 6 Instance to co-exist with EE5 which the ADF runs and Trigger the relevant schedulers through Web Services or MDBs.

On Sat, Jun 2, 2012 at 4:57 AM, Birol <bora....@gmail.com> wrote:

Hello everyone, 

Is there any implementation pattern? 

Of course there can be independent of application server vendor would be perfect.

--

[filip.h...@contribute.be]

I love it, the never ending battle between db and middleware.
Use what you know best, would be mine advise. Never forget that you
need to be able to manage it.

From experience, using a solution in the application itself, like
Quarz, has a real visible impact(read performance, unexpected load) on
your application.
That's why we also went to the "cron" or OS scheduler solution. The
major disadvantage of this solution is that you need to be able to
extract(refactor) the code to be called from an non-application server
environment.
Once that is done, you have the perfect situation: reuse of the
existing code, manageability by the application developers, no impact
on the middleware for your application.

HTH

Filip

[Chad Thompson]

On Tuesday, June 5, 2012 at 5:12 AM, filip.h...@telenet.be wrote:

From experience, using a solution in the application itself, like

Quarz, has a real visible impact(read performance, unexpected load) on

your application.

That's why we also went to the "cron" or OS scheduler solution. The

major disadvantage of this solution is that you need to be able to

extract(refactor) the code to be called from an non-application server

environment.

 This is a good thing to keep in mind with scheduled jobs, especially in a web application.  That job will use up the resources defined in the web app, so if you've tuned your app for user interaction through a browser (which you probably have), running 'background jobs' in the same app will take memory, connection pools, resources, etc. from your online system.

(So, if you're going to use Quartz, common* or any app-server type of container for scheduled jobs, make sure that you either have timing set for off hours, or consider scoping and adding additional resources to handle both batch processing plus online interaction.)

- Chad

-- 
Chad Thompson 
chad_t...@mac.com