Re: Going to SOA and BPEL direction

yuriy_zubarev_at_yahoo.ca schreef:
> Greetings,
>
> I work for an IT department of a medium size company where a decision
> has been made to move to SOA paradigm. Whether or not the company truly
> needs to get into SOA world is a separate question but the reality is
> that SOA is an official strategy right now and BPEL (BPEL Process
> Manager from Oracle) is a tool that will invariably get us there. The
> pressure is to try to use BPEL every time two or more systems need to
> talk to each other so that we unify and standardize all integration
> interfaces. The problem is (at least in my opinion) that overwhelming
> majority of those "interfaces" fall under "data population"
> pattern. We have a system as a master of, let's say, employee data,
> and 10 other systems requiring the same data or a subset of it. So
> every nigh bunch of scheduled jobs pump data around. One of the drives
> is to have BPEL do pumping work as well. I know that BPEL Process
> Manager has all these connectors that can operate with databases and
> files and theoretically it can do the job. It just seems to me like a
> gigantic misuse of the tool and technology.
>

Sorry, but I don't get the "nightly jobs" bit. Application Interconnect, the "data mangling part" of the suite will do just that, on the fly.

What you need is the biggest denominator, define that as common view, and define every application view off that.

Define your transformations (iStudio/BPEL) and Business Flow(s) (BPEL), code your application dependent stuff (PL/SQL, Java, ...) and you're done.
Need for more data? Just add to your application definition in the central repository...

Your central Employee app inserts (or updates) data, all interested parties get their own view of the data. One of the interested parties changes some HR data? It should send it back to the central HR app, which, after careful consideration, rejects or accepts the change, and broadcasts the change to all interested parties.

No nightly jobs here... all asynchronous, but as real time as possible (depending on the "careful consideration" bit; that might involve human intervention).

OAI is a great concept, but do not misuse it, and start querying data with it (seen it, Murphy all over...). The great thing is, a new system wanting HR data only requires a new application dependent view to be defined, and the application code - all other views and systems are already in place.

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...