We've been discussing skills and training a couple of times in the
group, so I thought it would be a good idea to start a skills list -
what are the skills you want on your ADF Dream Team?
Here's a couple of ideas to get the discussion going:
Java skills
Java (as a language - basic skills)
Java OO (understanding inheritance, interfaces, etc)
BC skills
Business Components basics (building components using wizards)
Business Components intermediate (extending framework classes)
Business Components advanced (what do we consider "advanced"?)
JSF skills
JSF Basics (drag-and-drop, task flows)
JSF Intermediate (templates, backing beans etc)
JSF Advanced (building your own components, other advanced topics?)
Other
HTML (is this necessary?)
CSS (how much of this does an ADF team need?)
JavaScript (is this necessary?)
HTTP (is this necessary?)
Expression Language
Regular Expressions?
Please comment on this list and add your own suggestions.
I think an understanding of HTTP is always necessary. It is important for
team members to understand the differences between what happens on the
server and what happens in the browser. Even though ADF abstracts a lot of
the necessity for this type of understanding away, without it you can find
your developers going down some strange paths when attempting to implement
some unique functionality.
Also, along those same lines, a few team members need to have an
understanding of the JSF and ADF Lifecycles.
On Tue, Oct 6, 2009 at 8:31 AM, Sten Vesterli <s...@vesterli.com> wrote:
> Hi all,
> We've been discussing skills and training a couple of times in the
> group, so I thought it would be a good idea to start a skills list -
> what are the skills you want on your ADF Dream Team?
> Here's a couple of ideas to get the discussion going:
> Java skills
> Java (as a language - basic skills)
> Java OO (understanding inheritance, interfaces, etc)
> BC skills
> Business Components basics (building components using wizards)
> Business Components intermediate (extending framework classes)
> Business Components advanced (what do we consider "advanced"?)
> JSF skills
> JSF Basics (drag-and-drop, task flows)
> JSF Intermediate (templates, backing beans etc)
> JSF Advanced (building your own components, other advanced topics?)
> Other
> HTML (is this necessary?)
> CSS (how much of this does an ADF team need?)
> JavaScript (is this necessary?)
> HTTP (is this necessary?)
> Expression Language
> Regular Expressions?
> Please comment on this list and add your own suggestions.
Hi, We have plenty of PL/SQL APIs used by the forms applications. Now we are developing ADF applications on top of this back-end and we need to utilize most of the code that is already there in PL/SQL. Our back-end APIs are not straight forward, meaning they use PL/SQL and SQL types heavily. This makes calling them from Java a little complicated. After seeing this we thought that we need some kind of code generator to generate the Java code to call them. I wonder how others are handling these challenges ... Do you use JPublisher , Orinda or your own generator ?
> We have plenty of PL/SQL APIs used by the forms applications. Now we are
> developing ADF applications on top of this back-end and we need to utilize
> most of the code that is already there in PL/SQL.
> Our back-end APIs are not straight forward, meaning they use PL/SQL and SQL
> types heavily. This makes calling them from Java a little complicated. After
> seeing this we thought that we need some kind of code generator to generate
> the Java code to call them.
> I wonder how others are handling these challenges …
> Do you use JPublisher , Orinda or your own generator ?
> Thanks
-- Marko Mitić
Bul. Kralja Aleksandra 249/62
11000 Belgrade
Serbia
Phone. +381 (0)63 7737328
Hi,
Because of multi tier or SOA application the good ADF team must have:
1. One expert for database to tune, create some jobs on DB, make
optimisation for some queries, materialized queries, ...
2. One expert for BC, EJB ... to make services, methods that will be use in
view
3. One expert for JSF (ADF) who can create task flows, regions,
reusable/declarative components, navigation and create some login on
view/presentation layer
4. One with good knowledge in HTML, CSS, facelets to make template pages and
to skin ADF components (if project requires different skin then existing few
oracle skins)
5. One head of dev team
I will skip guys for deployment (cause ADF can only deploy on WebLogic) and
ADFSecurity (in my opinion the weakness link in ADF because is only useful
with WebLogic and if you want to use ADF and new feature of 11g you must
using ADF Security)
Depend of project size, you can involve more developers in any tier. Also
one man in team can cover few tier.
Marko,
I guess I forgot to mention that I am using ADFBC not EJB as my persistence layer. My real problem is with complicated APIs that has parameters in PL/SQL record types or SQL record types.
Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL APIs but it has many limitations and often it is very hard to generate code that fits into your coding standards…
Thanks
From: adf-methodology@googlegroups.com [mailto:adf-methodology@googlegroups.com] On Behalf Of Marko Mitic
Sent: Wednesday, October 07, 2009 3:02 AM
To: adf-methodology@googlegroups.com
Subject: [ADF Enterprise Methodology Group] Re: What is the best practice for handling calls to existing PL/SQL APIs
Hi,
You can create functions or stored procedures from PL/SQL block code and use thought EJB 2.
See:
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#How_t... However, I agree that more complicated to create ADF 11g application with PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
Regards
Marko
2009/10/6 Soyer, Muhammed A. <MSo...@micros.com<mailto:MSo...@micros.com>>
Hi,
We have plenty of PL/SQL APIs used by the forms applications. Now we are developing ADF applications on top of this back-end and we need to utilize most of the code that is already there in PL/SQL.
Our back-end APIs are not straight forward, meaning they use PL/SQL and SQL types heavily. This makes calling them from Java a little complicated. After seeing this we thought that we need some kind of code generator to generate the Java code to call them.
I wonder how others are handling these challenges …
Do you use JPublisher , Orinda or your own generator ?
Thanks
--
Marko Mitić
Bul. Kralja Aleksandra 249/62
11000 Belgrade
Serbia
Phone. +381 (0)63 7737328
Hi,
We are wrapping PL/SQL procedures with DB Views. In ADF BC we are retrieving
data through read-only View Objects and doing updates through direct PL/SQL
calls. In the beginning we were using JPublisher, its good tool, however we
are not using it now mainly because political decisions (not technical). I
would recommend to take closer look into JPublisher.
> I guess I forgot to mention that I am using ADFBC not EJB as my
> persistence layer. My real problem is with complicated APIs that has
> parameters in PL/SQL record types or SQL record types.
> Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL
> APIs but it has many limitations and often it is very hard to generate code
> that fits into your coding standards...
> Thanks
> *From:* adf-methodology@googlegroups.com [mailto:
> adf-methodology@googlegroups.com] *On Behalf Of *Marko Mitic
> *Sent:* Wednesday, October 07, 2009 3:02 AM
> *To:* adf-methodology@googlegroups.com
> *Subject:* [ADF Enterprise Methodology Group] Re: What is the best
> practice for handling calls to existing PL/SQL APIs
> Hi,
> You can create functions or stored procedures from PL/SQL block code and
> use thought EJB 2.
> However, I agree that more complicated to create ADF 11g application with
> PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
> Regards
> Marko
> 2009/10/6 Soyer, Muhammed A. <MSo...@micros.com>
> Hi,
> We have plenty of PL/SQL APIs used by the forms applications. Now we are
> developing ADF applications on top of this back-end and we need to utilize
> most of the code that is already there in PL/SQL.
> Our back-end APIs are not straight forward, meaning they use PL/SQL and SQL
> types heavily. This makes calling them from Java a little complicated. After
> seeing this we thought that we need some kind of code generator to generate
> the Java code to call them.
> I wonder how others are handling these challenges ...
> Do you use JPublisher , Orinda or your own generator ?
> Thanks
> --
> Marko Mitić
> Bul. Kralja Aleksandra 249/62
> 11000 Belgrade
> Serbia
> Phone. +381 (0)63 7737328
> Hi,
> We are wrapping PL/SQL procedures with DB Views. In ADF BC we are
> retrieving data through read-only View Objects and doing updates through
> direct PL/SQL calls. In the beginning we were using JPublisher, its good
> tool, however we are not using it now mainly because political decisions
> (not technical). I would recommend to take closer look into JPublisher.
> Andrejus
> 2009/10/7 Soyer, Muhammed A. <MSo...@micros.com>
> Marko,
>> I guess I forgot to mention that I am using ADFBC not EJB as my
>> persistence layer. My real problem is with complicated APIs that has
>> parameters in PL/SQL record types or SQL record types.
>> Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL
>> APIs but it has many limitations and often it is very hard to generate code
>> that fits into your coding standards…
>> Thanks
>> *From:* adf-methodology@googlegroups.com [mailto:
>> adf-methodology@googlegroups.com] *On Behalf Of *Marko Mitic
>> *Sent:* Wednesday, October 07, 2009 3:02 AM
>> *To:* adf-methodology@googlegroups.com
>> *Subject:* [ADF Enterprise Methodology Group] Re: What is the best
>> practice for handling calls to existing PL/SQL APIs
>> Hi,
>> You can create functions or stored procedures from PL/SQL block code and
>> use thought EJB 2.
>> However, I agree that more complicated to create ADF 11g application with
>> PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
>> Regards
>> Marko
>> 2009/10/6 Soyer, Muhammed A. <MSo...@micros.com>
>> Hi,
>> We have plenty of PL/SQL APIs used by the forms applications. Now we are
>> developing ADF applications on top of this back-end and we need to utilize
>> most of the code that is already there in PL/SQL.
>> Our back-end APIs are not straight forward, meaning they use PL/SQL and
>> SQL types heavily. This makes calling them from Java a little complicated.
>> After seeing this we thought that we need some kind of code generator to
>> generate the Java code to call them.
>> I wonder how others are handling these challenges …
>> Do you use JPublisher , Orinda or your own generator ?
>> Thanks
>> --
>> Marko Mitić
>> Bul. Kralja Aleksandra 249/62
>> 11000 Belgrade
>> Serbia
>> Phone. +381 (0)63 7737328
The days that the bussiness logic was developed in database procedures
are over.
But its not because BC4J dont support it.
Its because of the 3 tier architecture.
The overhead of having data management and business logic in same
datatabase server cost too much for the server.
Thats why Application Servers were created to release the database
server from bussiness rule processing.
So if you are seriusly migrating a Forms application to an ADF
application then this logic should be transfered to BC layer.
You dont need Fusion if you just want a presentation layer for logic
developed in database.
You can use SOA for that.
Create webservices from database procedure and just present them in
simple web pages.
Regards
Michael
On Oct 7, 8:24 pm, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> > Hi,
> > We are wrapping PL/SQL procedures with DB Views. In ADF BC we are
> > retrieving data through read-only View Objects and doing updates through
> > direct PL/SQL calls. In the beginning we were using JPublisher, its good
> > tool, however we are not using it now mainly because political decisions
> > (not technical). I would recommend to take closer look into JPublisher.
> > Andrejus
> > 2009/10/7 Soyer, Muhammed A. <MSo...@micros.com>
> > Marko,
> >> I guess I forgot to mention that I am using ADFBC not EJB as my
> >> persistence layer. My real problem is with complicated APIs that has
> >> parameters in PL/SQL record types or SQL record types.
> >> Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL
> >> APIs but it has many limitations and often it is very hard to generate code
> >> that fits into your coding standards…
> >> Thanks
> >> *From:* adf-methodology@googlegroups.com [mailto:
> >> adf-methodology@googlegroups.com] *On Behalf Of *Marko Mitic
> >> *Sent:* Wednesday, October 07, 2009 3:02 AM
> >> *To:* adf-methodology@googlegroups.com
> >> *Subject:* [ADF Enterprise Methodology Group] Re: What is the best
> >> practice for handling calls to existing PL/SQL APIs
> >> Hi,
> >> You can create functions or stored procedures from PL/SQL block code and
> >> use thought EJB 2.
> >> However, I agree that more complicated to create ADF 11g application with
> >> PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
> >> Regards
> >> Marko
> >> 2009/10/6 Soyer, Muhammed A. <MSo...@micros.com>
> >> Hi,
> >> We have plenty of PL/SQL APIs used by the forms applications. Now we are
> >> developing ADF applications on top of this back-end and we need to utilize
> >> most of the code that is already there in PL/SQL.
> >> Our back-end APIs are not straight forward, meaning they use PL/SQL and
> >> SQL types heavily. This makes calling them from Java a little complicated.
> >> After seeing this we thought that we need some kind of code generator to
> >> generate the Java code to call them.
> >> I wonder how others are handling these challenges …
> >> Do you use JPublisher , Orinda or your own generator ?
> >> Thanks
> >> --
> >> Marko Mitić
> >> Bul. Kralja Aleksandra 249/62
> >> 11000 Belgrade
> >> Serbia
> >> Phone. +381 (0)63 7737328
Well, this is a topic I've spent a fair bit of time thinking about, and I
think it's a really complex one. For one thing, I think it depends wildly
on what sort of team size we're talking about here. Here's an example of
that: If I had a team of 4 developers to organize, I'd almost certainly
not bother with ensuring that one of them had experience developing (in a
non-declarative sense) JSF components, but if I had an in-house
organization of 1000, I'd certainly think that having a handful of true
JSF component developers could be useful. Just generally, the larger your
team, the more you can afford to specialize, and I think that, even with a
framework like ADF, the upper bound on what you can gain from
specialization (given a large enough team) is really very, very high.
The division I suggest in Extreme Reusability assumes that the biggest
skills division on a typical team is level of general Java programming
knowledge. More standard methodologies (such as the methodology hinted at
by the developer's guide) assume that the primary team division is going
to be front end vs. back end. In an environment where you have a large
team, I think respecting both distinctions is probably ideal--allowing
people to specialize in declarative work vs. Java development *and* in
business components vs. view/controller work is probably ideal.
> Java (as a language - basic skills)
Getting basic linguistic skills with Java is so trivial (assuming your
developers have *ever* used a procedural language of any sort) that
there's not much trouble with expecting your whole team to have these. On
the other hand, I think developers should be very careful about *using*
these basic skills--in 11g, almost anything you could do with Java this
simple you can do without Java at all. I actually think that team members
who have only this basic "scripting" level of Java should be advised to
use Java only as a last resort.
So, I've made my beliefs about this clear: 20% of the team, down to a
minimum of 1, should be made of people who are actually comfortable with
object-oriented programming (as opposed to simply being comfortable
writing a few script-type lines of Java). I'd definitely rather have one
Java programmer who really knew what he/she was doing on an ADF project
than five who were sort of limping along.
I should note, though, that that's a bit controversial. I'm really into
the idea that Java development in an ADF project should more or less equal
framework extension, which is where you get these sorts of numbers. This
isn't even necessarily endorsed by the JDev team itself (in fact, I know
they think I go a bit too far with it, at any rate).
> BC skills
> Business Components basics (building components using wizards)
So, this is interesting: Traditionally, people make the association:
business components declarative programming = basic
business components programming with the API = advanced
But that's not really true at all. There's a *lot* of stuff you can do
declaratively with business components that your standard 24-hour tutorial
or 40-hour class isn't going to get around to. For example, I just
finished going through some tips and techniques for ADF BC tuning on my
blog. With only two exceptions (explicitly notifying certain rowsets of
entity changes instead of using association consistency, and lazy-loading
view link details), these techniques were all 100% declarative, and many
of them can be done in the initial creation wizards. But I don't think
they're things that everyone with a "basic" level of ADF BC background
knows.
So rather than something as vague as "building components using wizards,"
which can include some pretty sophisticated stuff, how do people feel
about the following list of topics as "basic"?
-Being able to create, though not necessarily tune, entity objects and
view objects based on them (in at least one query mode), one-to-many,
one-to-one, and many-to-one associations and view links based on them
-Understanding the retrieve/store/write cycle for entity-based VOs, and
ability to draw conclusions about behavior based on them (e.g., how many
Departments EO instances will be created from a join between Employees and
Departments, and what effect will changing a value in one of them have on
another VO that also uses the Departments EO)
-Being able to assemble a data model, including important conceptual
distinctions such as the difference between the definition of a VO and a
particular VO instance in the data model
-Being able to create view criteria objects (declaratively)
-Being able to create simple LOV-based attributes
-Being able to declaratively apply validation rules
These are skills that, IMO, *any* member of the team who will be creating
BCs should master for 11g.
> Business Components intermediate (extending framework classes)
This is where I think most of the other declarative stuff goes. There
should be at least one person on the team who, for example, would think of
checking the JDBC fetch size as an automatic part of developing any VO, or
who could puzzle out how to use effective-dating if they had to. A pretty
thorough understanding of all necessary and optional aspects of the ADF BC
lifecycle (validation, activation/passivation, range paging, etc) is
pretty important for *somebody* on the team to have. And I agree, most of
the basic stuff involved in extending framework classes, which includes
not only basic OO programming skills but a tolerable understanding of the
ultra-common BC APIs should go here too. Certainly anything involving
navigating or searching through rows, retrieving or changing attribute
values, committing or rolling back the transaction, traversing
associations or view links, saving values at the session level, etc. And
probably things like retrieving attribute and property metadata,
overriding doDML(), etc.
> Business Components advanced (what do we consider "advanced"?)
I think the above will get a lot of projects by. If I really had a "dream
team" assembled, though, there'd be somebody who knows, or knows how to
discover and can easily understand, *all* public BC APIs. And probably has
a pretty good grasp on the APIs for their JDBC driver, too (and
*certainly* for generic JDBC). Someone who would be comfortable, say,
changing the strategy used to cache JDBC prepared statements, or who would
be willing and able to take on a project like implementing an entity/view
object class pair that allows you to query and change the contents of an
XML file in an efficient and scalable manner. I'd certainly recommend that
any *large* organization (say, >25 developers devoted to creating ADF
apps) try to maintain a "hot-shot" in each technology being used,
including ADF BC. But this probably isn't a good investment for a small
team, since skills like this will be needed so rarely. This is a good role
(in a bigger company) for what Duncan Mills once described as "SWAT
teams," with no permanent attachment to a project, who can just go
wherever they are needed and do what needs to be done.
Agreed, but this shouldn't be mindless drag-and-drop. Even at a basic
level, people need to know how to, say, pass parameters into a task flow,
and either need to know best practices (use parameter passing instead of
session-scoped variables, for example) or need to be closely guided by
people who do.
Not sure if you're considering knowledge of the databindings part of this.
If so, in addition to drag-and-drop, I'd say that even at the basic level,
people ought to be reasonably comfortable with using the visual binding
editors, and should, say, be able to pass a parameter into an operation.
> JSF Intermediate (templates, backing beans etc)
Hmm..."backing bean" covers so much stuff, from being able to write a
simple bean that does nothing but hold a bit of transient data to, say,
being familiar with relatively obscure areas of the JSF, Trinidad, or ADF
Faces RC API. Going by the "one person per team" standard for
"intermediate" that I used for business components, I'd include
-Being able to create backing beans and store them at various scopes; a
general working knowledge of how injection works
-Knowing how to retrieve and work with bindings in a Java context,
including at least a solid knowledge of the APIs in the oracle.bindings
package
-A good solid knowledge of executables, including how to work with them in
the visual editor
-Knowing the ADF and JSF lifecycle, and being able to override it to do
simple things
-Knowing what needs to be done to, say, process uploads or drag-and-drop
-Being able to create templates and declarative components
-Being able to write validators and converters and suchlike
> JSF Advanced (building your own components, other advanced topics?)
Building your own components *programmatically*. Building your own
declarative components is definitely just "intermediate." More obscure
bits of the JSF/Trinidad/ADF Faces RC/ADF databindings (especially outside
oracle.bindings) API would arguably go here too. If I were really
assembling a dream team, I'd make sure that there was someone on it who
could *circumvent* the lifecycle when necessary, by, say, developing
servlets and filters with a pretty solid understanding of the APIs
available there.
I'm not quite as comfortable with the front end as I am with ADF BC, so
all this is a little tentative. I have a feeling that what I've called
"advanced" above is actually a lot less advanced than what I called
"advanced" under ADF BC.
> Other
> HTML (is this necessary?)
No. XHTML is a good "introduction to XML" language. Otherwise, knowing
HTML too well (compared to how well you know other relevant technologies)
can
...
If our application were a simple one that might be displayed in "Simple web pages" that might be an option but it is not.
We have hundreds thousands line of "working" code that was written in PL/SQL and we can't just say we will rewrite it in Java in the BC layer.
So we need a hybrid solution that will allow us to utilize the existing code in PL/SQL.
-----Original Message-----
From: adf-methodology@googlegroups.com [mailto:adf-methodology@googlegroups.com] On Behalf Of Michael Koniotiakis
Sent: Wednesday, October 07, 2009 4:44 PM
To: ADF Enterprise Methodology Group
Subject: [ADF Enterprise Methodology Group] Re: What is the best practice for handling calls to existing PL/SQL APIs
I agree.
The days that the bussiness logic was developed in database procedures
are over.
But its not because BC4J dont support it.
Its because of the 3 tier architecture.
The overhead of having data management and business logic in same
datatabase server cost too much for the server.
Thats why Application Servers were created to release the database
server from bussiness rule processing.
So if you are seriusly migrating a Forms application to an ADF
application then this logic should be transfered to BC layer.
You dont need Fusion if you just want a presentation layer for logic
developed in database.
You can use SOA for that.
Create webservices from database procedure and just present them in
simple web pages.
Regards
Michael
On Oct 7, 8:24 pm, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> I also had disign, many databases like this;
> Using a lot of data-sets returned from procedures; when I was using
> delphi ( old days );
> Now ;
> I must say that I abandoned this kind of database dising, mainly because
> BC4J does not suported it , naturally;
> > Hi,
> > We are wrapping PL/SQL procedures with DB Views. In ADF BC we are
> > retrieving data through read-only View Objects and doing updates through
> > direct PL/SQL calls. In the beginning we were using JPublisher, its good
> > tool, however we are not using it now mainly because political decisions
> > (not technical). I would recommend to take closer look into JPublisher.
> > Andrejus
> > 2009/10/7 Soyer, Muhammed A. <MSo...@micros.com>
> > Marko,
> >> I guess I forgot to mention that I am using ADFBC not EJB as my
> >> persistence layer. My real problem is with complicated APIs that has
> >> parameters in PL/SQL record types or SQL record types.
> >> Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL
> >> APIs but it has many limitations and often it is very hard to generate code
> >> that fits into your coding standards…
> >> Thanks
> >> *From:* adf-methodology@googlegroups.com [mailto:
> >> adf-methodology@googlegroups.com] *On Behalf Of *Marko Mitic
> >> *Sent:* Wednesday, October 07, 2009 3:02 AM
> >> *To:* adf-methodology@googlegroups.com
> >> *Subject:* [ADF Enterprise Methodology Group] Re: What is the best
> >> practice for handling calls to existing PL/SQL APIs
> >> Hi,
> >> You can create functions or stored procedures from PL/SQL block code and
> >> use thought EJB 2.
> >> However, I agree that more complicated to create ADF 11g application with
> >> PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
> >> Regards
> >> Marko
> >> 2009/10/6 Soyer, Muhammed A. <MSo...@micros.com>
> >> Hi,
> >> We have plenty of PL/SQL APIs used by the forms applications. Now we are
> >> developing ADF applications on top of this back-end and we need to utilize
> >> most of the code that is already there in PL/SQL.
> >> Our back-end APIs are not straight forward, meaning they use PL/SQL and
> >> SQL types heavily. This makes calling them from Java a little complicated.
> >> After seeing this we thought that we need some kind of code generator to
> >> generate the Java code to call them.
> >> I wonder how others are handling these challenges …
> >> Do you use JPublisher , Orinda or your own generator ?
> >> Thanks
> >> --
> >> Marko Mitić
> >> Bul. Kralja Aleksandra 249/62
> >> 11000 Belgrade
> >> Serbia
> >> Phone. +381 (0)63 7737328
First: Sorry about the post above...not quite sure why it appeared in
this thread instead of the appropriate one. But:
The days of business logic in the database are most certainly *not*
over, not only because of legacy code but because for some business
logic the database is the most appropriate place. Business logic that
needs to churn through large amounts of data should *never* be placed
in the application server, which is not meant to handle grotesquely
large rowsets gracefully. And ADF BC most definitely does support
business logic in the DB--pretty well, if you're using an Oracle
database.
Complex SQL types shouldn't be an issue--just create domains to
represent them. Complex PL/SQL types are more of a problem, but
there's certainly a lot written on, say, how to load datasets from PL/
SQL functions. (ahem: http://www.avromroyfaderman.com/framework-for-package-api-based-adf-b... , although a better version--this version has locking and scalability
problems--will be forthcoming in a few more weeks). There's also a bit
of an issue that JDBC doesn't respect PL/SQL datatypes (like strongly
typed cursors), so you'll probably have some trouble working with them
no matter what you do.
You can go with code generation if you absolutely must, but if you
can, I'd suggest a metadata-driven solution (see the one above for a
simple example), so you won't have reams and reams of hard-to-maintain
generated Java code. A generalized solution that lets you specify
details of each PL/SQL API element declaratively is almost certainly
the best idea if you have hundreds of thousands of lines of DB code.
For the record, my current major client currently has 10+ production
ADF applications, with *all* business logic in the database (not that
I'd suggest this in greenfield development). It's not a problem.
Hope this helps,
Avrom
On Oct 7, 3:06 pm, "Soyer, Muhammed A." <MSo...@MICROS.COM> wrote:
> If our application were a simple one that might be displayed in "Simple web pages" that might be an option but it is not.
> We have hundreds thousands line of "working" code that was written in PL/SQL and we can't just say we will rewrite it in Java in the BC layer.
> So we need a hybrid solution that will allow us to utilize the existing code in PL/SQL.
> -----Original Message-----
> From: adf-methodology@googlegroups.com [mailto:adf-methodology@googlegroups.com] On Behalf Of Michael Koniotiakis
> Sent: Wednesday, October 07, 2009 4:44 PM
> To: ADF Enterprise Methodology Group
> Subject: [ADF Enterprise Methodology Group] Re: What is the best practice for handling calls to existing PL/SQL APIs
> I agree.
> The days that the bussiness logic was developed in database procedures
> are over.
> But its not because BC4J dont support it.
> Its because of the 3 tier architecture.
> The overhead of having data management and business logic in same
> datatabase server cost too much for the server.
> Thats why Application Servers were created to release the database
> server from bussiness rule processing.
> So if you are seriusly migrating a Forms application to an ADF
> application then this logic should be transfered to BC layer.
> You dont need Fusion if you just want a presentation layer for logic
> developed in database.
> You can use SOA for that.
> Create webservices from database procedure and just present them in
> simple web pages.
> Regards
> Michael
> On Oct 7, 8:24 pm, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> > I also had disign, many databases like this;
> > Using a lot of data-sets returned from procedures; when I was using
> > delphi ( old days );
> > Now ;
> > I must say that I abandoned this kind of database dising, mainly because
> > BC4J does not suported it , naturally;
> > > Hi,
> > > We are wrapping PL/SQL procedures with DB Views. In ADF BC we are
> > > retrieving data through read-only View Objects and doing updates through
> > > direct PL/SQL calls. In the beginning we were using JPublisher, its good
> > > tool, however we are not using it now mainly because political decisions
> > > (not technical). I would recommend to take closer look into JPublisher.
> > > Andrejus
> > > 2009/10/7 Soyer, Muhammed A. <MSo...@micros.com>
> > > Marko,
> > >> I guess I forgot to mention that I am using ADFBC not EJB as my
> > >> persistence layer. My real problem is with complicated APIs that has
> > >> parameters in PL/SQL record types or SQL record types.
> > >> Oracle has a tool named JPublisher to generate wrapper code to call PL/SQL
> > >> APIs but it has many limitations and often it is very hard to generate code
> > >> that fits into your coding standards…
> > >> Thanks
> > >> *From:* adf-methodology@googlegroups.com [mailto:
> > >> adf-methodology@googlegroups.com] *On Behalf Of *Marko Mitic
> > >> *Sent:* Wednesday, October 07, 2009 3:02 AM
> > >> *To:* adf-methodology@googlegroups.com
> > >> *Subject:* [ADF Enterprise Methodology Group] Re: What is the best
> > >> practice for handling calls to existing PL/SQL APIs
> > >> Hi,
> > >> You can create functions or stored procedures from PL/SQL block code and
> > >> use thought EJB 2.
> > >> However, I agree that more complicated to create ADF 11g application with
> > >> PL/SQL code rather then BC or other ORM like EJB eclipselink, hibernate, ...
> > >> Regards
> > >> Marko
> > >> 2009/10/6 Soyer, Muhammed A. <MSo...@micros.com>
> > >> Hi,
> > >> We have plenty of PL/SQL APIs used by the forms applications. Now we are
> > >> developing ADF applications on top of this back-end and we need to utilize
> > >> most of the code that is already there in PL/SQL.
> > >> Our back-end APIs are not straight forward, meaning they use PL/SQL and
> > >> SQL types heavily. This makes calling them from Java a little complicated.
> > >> After seeing this we thought that we need some kind of code generator to
> > >> generate the Java code to call them.
> > >> I wonder how others are handling these challenges …
> > >> Do you use JPublisher , Orinda or your own generator ?
> > >> Thanks
> > >> --
> > >> Marko Mitić
> > >> Bul. Kralja Aleksandra 249/62
> > >> 11000 Belgrade
> > >> Serbia
> > >> Phone. +381 (0)63 7737328
While I understand Michael's point, and it falls into the "all in the
db vs all in the app server" argument that has been discussed numerous
times online previously in the JEE space, I think to say (without
attempting to be rude) that a site should rewrite their entire PL/SQL
in Java/the middlelayer is shortsighted.
I've worked at far too many sites where there is over a 100+ man years
of PL/SQL development (yes, you read that right). Those same sites
cannot afford to rewrite that level of code. As such for a
contemporary 3 tier technology such as ADF (as contemporary as a 10
year old software can ever be ;-), a solution to integrate PL/SQL is
essential if Oracle wants to pick up those existing Oracle-PL/SQL
laden applications.
While that sounds like a dire statement, it's not really that bad,
because ADF is flexible with it's PL/SQL support, through numerous
techniques, including:
... and the other techniques described earlier in this thread.
The problem unfortunately is us, or more exactly in our expectations.
At times I see an attitude that if a site has programmed PL/SQL
routine X, if routine X can't be easily fit into ADF then ADF is a
failure. From my years of PL/SQL programming I've seen many and
wonderful versions of routine X. And when I say wonderful I mean
fruity, strange, what-the?, why'd you do that?, oh-that's not
standard, oh-my-god, get-me-out-of-here. In other words PL/SQL is a
wonderfully flexible language which doesn't dictate how we build
applications, so each site has come up with their own solution. The
end result is the solution is not standard (whatever that is), and
this makes it hard for ADF and other frameworks in general to always
integrate easily and well with our fruity PL/SQL (I love that
phrase ;-). Thus it is an unrealistic expectation *in*all*cases
across every site and every development for a universal ADF to PL/SQL
plugin.
Once you realize that expectation is unrealistic, I'll return you to
the original intent of this thread. So, what are the best practices
for integration of PL/SQL? There is no single best practice, you need
to work out what works for you and your existing application, what you
can get working with your current PL/SQL, work out what PL/SQL you'll
have to throw and rewrite in the middle tier because it doesn't sit
well, and yes, you probably need to do some work to get this all
there. There's no holly grail.
So maybe the original thread should have been, "we have developed our
existing PL/SQL application with the following design guidelines in
mind" .... "and does anybody have any suggestions on what we can
easily port to ADF and what not given what we achieved in PL/SQL".
Please excuse typos, poor grammar etc, extremelly jet lagged on
arriving in San Fran.
I think that most part of plSql to Bc4j insue, at least in my
applications, resume in retriving cursors from plSql ,
Steve Muench, i'm not sure, wrote some time ago, a paper using plSql
procedure and bc4j viewObject to create viewObject's rowSet; unfortunatly,
i can't find it now;
IMO, Bc4j could have an xml based component just like ViewObject , to
execute and load data from those kind of procedures;
DML procedures, has a great number of "cases" and they require more
attention; as your paper apply very well ;
> While I understand Michael's point, and it falls into the "all in the
> db vs all in the app server" argument that has been discussed numerous
> times online previously in the JEE space, I think to say (without
> attempting to be rude) that a site should rewrite their entire PL/SQL
> in Java/the middlelayer is shortsighted.
> I've worked at far too many sites where there is over a 100+ man years
> of PL/SQL development (yes, you read that right). Those same sites
> cannot afford to rewrite that level of code. As such for a
> contemporary 3 tier technology such as ADF (as contemporary as a 10
> year old software can ever be ;-), a solution to integrate PL/SQL is
> essential if Oracle wants to pick up those existing Oracle-PL/SQL
> laden applications.
> While that sounds like a dire statement, it's not really that bad,
> because ADF is flexible with it's PL/SQL support, through numerous
> techniques, including:
> ... and the other techniques described earlier in this thread.
> The problem unfortunately is us, or more exactly in our expectations.
> At times I see an attitude that if a site has programmed PL/SQL
> routine X, if routine X can't be easily fit into ADF then ADF is a
> failure. From my years of PL/SQL programming I've seen many and
> wonderful versions of routine X. And when I say wonderful I mean
> fruity, strange, what-the?, why'd you do that?, oh-that's not
> standard, oh-my-god, get-me-out-of-here. In other words PL/SQL is a
> wonderfully flexible language which doesn't dictate how we build
> applications, so each site has come up with their own solution. The
> end result is the solution is not standard (whatever that is), and
> this makes it hard for ADF and other frameworks in general to always
> integrate easily and well with our fruity PL/SQL (I love that
> phrase ;-). Thus it is an unrealistic expectation *in*all*cases
> across every site and every development for a universal ADF to PL/SQL
> plugin.
> Once you realize that expectation is unrealistic, I'll return you to
> the original intent of this thread. So, what are the best practices
> for integration of PL/SQL? There is no single best practice, you need
> to work out what works for you and your existing application, what you
> can get working with your current PL/SQL, work out what PL/SQL you'll
> have to throw and rewrite in the middle tier because it doesn't sit
> well, and yes, you probably need to do some work to get this all
> there. There's no holly grail.
> So maybe the original thread should have been, "we have developed our
> existing PL/SQL application with the following design guidelines in
> mind" .... "and does anybody have any suggestions on what we can
> easily port to ADF and what not given what we achieved in PL/SQL".
> Please excuse typos, poor grammar etc, extremelly jet lagged on
> arriving in San Fran.
Of course PL /SQL is the best way for large amount of data
manipulation.
But I think ADF is not for back end applications.
I also work in a migration of forms application that has a database
with more than 2 hundred thousands lines of PL/SQL code.
The problem is that more than half of that code is procedure based
blocks:
As you know in forms you could define for a block:
Select procedure
Update procedure
Insert procedure
Lock procedure.
They get as in parameters PL/SQL Table types.
In my project they also don’t want to transfer this logic to java.
So we end up writing more PL/SQL wrapper procedures getting simpler
types and overriding Transaction Management of Entities , Application
modules and Transaction Factory Implementation, in order to handle
locking and posting order.
Yes it can be done but I would not recommend it as best practice.
In general I don’t see any other reason for passing complex types like
Tables to database procedures. This data probably already exist in
database and the procedure could find it with an SQL statement.
On 8 Οκτ, 06:14, Marcos Ortega <mar...@santoandrea.com.br> wrote:
> I think that most part of plSql to Bc4j insue, at least in my
> applications, resume in retriving cursors from plSql ,
> Steve Muench, i'm not sure, wrote some time ago, a paper using plSql
> procedure and bc4j viewObject to create viewObject's rowSet; unfortunatly,
> i can't find it now;
> IMO, Bc4j could have an xml based component just like ViewObject , to
> execute and load data from those kind of procedures;
> DML procedures, has a great number of "cases" and they require more
> attention; as your paper apply very well ;
> > While I understand Michael's point, and it falls into the "all in the
> > db vs all in the app server" argument that has been discussed numerous
> > times online previously in the JEE space, I think to say (without
> > attempting to be rude) that a site should rewrite their entire PL/SQL
> > in Java/the middlelayer is shortsighted.
> > I've worked at far too many sites where there is over a 100+ man years
> > of PL/SQL development (yes, you read that right). Those same sites
> > cannot afford to rewrite that level of code. As such for a
> > contemporary 3 tier technology such as ADF (as contemporary as a 10
> > year old software can ever be ;-), a solution to integrate PL/SQL is
> > essential if Oracle wants to pick up those existing Oracle-PL/SQL
> > laden applications.
> > While that sounds like a dire statement, it's not really that bad,
> > because ADF is flexible with it's PL/SQL support, through numerous
> > techniques, including:
> > ... and the other techniques described earlier in this thread.
> > The problem unfortunately is us, or more exactly in our expectations.
> > At times I see an attitude that if a site has programmed PL/SQL
> > routine X, if routine X can't be easily fit into ADF then ADF is a
> > failure. From my years of PL/SQL programming I've seen many and
> > wonderful versions of routine X. And when I say wonderful I mean
> > fruity, strange, what-the?, why'd you do that?, oh-that's not
> > standard, oh-my-god, get-me-out-of-here. In other words PL/SQL is a
> > wonderfully flexible language which doesn't dictate how we build
> > applications, so each site has come up with their own solution. The
> > end result is the solution is not standard (whatever that is), and
> > this makes it hard for ADF and other frameworks in general to always
> > integrate easily and well with our fruity PL/SQL (I love that
> > phrase ;-). Thus it is an unrealistic expectation *in*all*cases
> > across every site and every development for a universal ADF to PL/SQL
> > plugin.
> > Once you realize that expectation is unrealistic, I'll return you to
> > the original intent of this thread. So, what are the best practices
> > for integration of PL/SQL? There is no single best practice, you need
> > to work out what works for you and your existing application, what you
> > can get working with your current PL/SQL, work out what PL/SQL you'll
> > have to throw and rewrite in the middle tier because it doesn't sit
> > well, and yes, you probably need to do some work to get this all
> > there. There's no holly grail.
> > So maybe the original thread should have been, "we have developed our
> > existing PL/SQL application with the following design guidelines in
> > mind" .... "and does anybody have any suggestions on what we can
> > easily port to ADF and what not given what we achieved in PL/SQL".
> > Please excuse typos, poor grammar etc, extremelly jet lagged on
> > arriving in San Fran.
|
