Architecting for ADF Mobile - ADF BC SDO web services

[Chris Muir]

Phew, now that we're out of the busy OOW period and all the exciting announcements, it would be good to get back to the roots of this group and discuss architecture.

I know ADF Mobile is brand new for most of you, and you're still exploring the features and lodging your purchase orders to buy those iPads at your employers' expense  However I'd like to start a conversation on enterprise architecture for ADF Mobile.

In considering architecture for ADF Mobile there's the architecture within the native application, and then the broader enterprise picture of how your ADF Mobile application calls to base.  Most mobile apps at some point need to make a call out to some service to retrieve and write data.  To date traditional "web" ADF programmers (see, as an ADF programmer you're now considered old, it was only a matter of time ;-) within context of an ADF application use services like ADF BC to interact with the database for CRUD like services.  Of more importance we've built a lot of validation and additional smarts into the ADF BC layer, and that validation isn't something we necessarily want to re-code on the ADF Mobile device.

However on ADF Mobile we don't have ADF BC as an option, so we must rely on web services.

Hmm, what's the solve?  (Obviously most of you know where I'm going with this).  Solution: server side ADF BC allows AMs and VOs to be published as SDOs (aka. SOAP based web services) which can be consumed externally to the server based ADF application by web service clients, including mobile devices.  Shay just created a handy YouTube video on this: http://www.youtube.com/watch?v=Cos1qSn4EvU (I highly recommend you watch Shay's YouTube channel, Shay is always posting new videos on tips and techniques for our latest technologies and topical content)

So I know a few of you have been doing experiments in the SDO area before ADF Mobile existed, and very likely your purpose for this was other mobile frameworks to consume the ADF BC SDO objects.

What I'd like to discuss is how have you been architecting this & what issues have you been hitting?  I could imagine we could turn on the SDO services for all pre-existing AMs and VOs built for our existing ADF web applications, but I don't think that really considers the mobile use case very well, a VO built for a web page may include too much stuff for a mobile page who is also bandwidth and memory limited.  As such I can also imagine a scenario where we would create separate AMs and VOs for the mobile use case, backed by the same EOs of the ADF web application.

This discussion doesn't need to be restricted to people who have just worked with SDO.  I bet there's a whole bunch of questions we can collectively raise and attempt to solve her.

Keen to hear your thoughts.

CM.

[Chad Thompson]

On Oct 24, 2012, at 9:06 PM, Chris Muir <chris...@gmail.com> wrote:

What I'd like to discuss is how have you been architecting this & what issues have you been hitting?  I could imagine we could turn on the SDO services for all pre-existing AMs and VOs built for our existing ADF web applications, but I don't think that really considers the mobile use case very well, a VO built for a web page may include too much stuff for a mobile page who is also bandwidth and memory limited.  As such I can also imagine a scenario where we would create separate AMs and VOs for the mobile use case, backed by the same EOs of the ADF web application.

I haven't had the chance to properly 'dig in' to ADF Mobile and how it handles web services, but I'll bring up a few items:

1) While ADF proper supports SOAP data objects very well (and has been doing so for a long time), ADF does not have a comparable method for creating RESTful web services in a declarative fashion.  (The Jersey based methods are of course available and not terribly 'difficult', but it's not quite as straightforward as the SOAP functionality with Business Components.)

2)  Of interest to me in terms of ADF Mobile development is also using third-party APIs, most of which are RESTful services that may use OAuth for service authentication - for example Twitter or one that I'm fascinated with lately, the "Dark Sky" API  ( https://developer.darkskyapp.com )

[A corollary here -it would also be interesting to discuss using ADF 'in general' to produce restful services that could be used in the manner of DarkSky or other mobile apps.  How would one think about metering API calls, etc. that would even be useful in the more 'corporate' type apps to detect when a malicious client is attempting to make inappropriate calls, etc. ]

What options might we have for digesting RESTful web services (even JSON formatted) with ADF mobile clients?

3)  I do agree with your paragraph I quoted above - I can see areas where different AMs/VOs would be used to generate smaller SOAP envelopes in the interest of reducing the amount of data transferred over (often wireless) data networks.  The key to making better service driven apps is in both reducing the number of service calls and minimizing the size of when we do make calls.

(To that end - are there good caching strategies for managing data 'on the device' prior to using networked services?)

Thanks to all for reading - this was a post that generated more heat than light.  :-)

- Chad

---
Chad Thompson | Sr. Solutions Architect
Zirous -- Oracle Gold Partner
1503 42nd Street, Suite 210 | West Des Moines, IA
Office 515.974.5534 | Mobile 515.999.0268 | http://www.zirous.com

[Chris Muir]

Ha! Chad, you've hijacked my thread ;-)

I'm in a position to say JDev and ADF's support for REST based web
services will be enhanced in the 12c space (with the usual disclaimers
that you can't hold Oracle to this statement as we reserve the right
to change our minds). This will include exposing ADF BC as restful
web services, and the URL data control will be enhanced to consume
REST services. As such questions around REST support from ADF in the
future will be shaped by what we provide in the 12c release.

As such I'd like to bring the conversation back to SDOs at this stage
(hint hint Chad ;-).

CM.

> --
> 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).

[Joe Huang]

As usual I like to turn things a bit upside down to pose the same question.  I typically look at architecting an ADF Mobile app in the following two steps.

 

1.       First you should consider what your client-side app needs to do.  What functionality and data are needed on the device, and design out the screens and task flows in a wireframe.  Then you need to consider whether you need to cache data for performance and/or offline requirements.  These would help you to determine how you want to retrieve data from the server.  Of course there are other considerations like what device services you would need to access, what form factors (smartphone vs. tablet) you would need to support, and what mobile OS do you want to support, but these are not directly related to data services.

2.       Once you figured out what client app needs to do and what data/how data should be retrieved, then you determine how to get data from server-side components, be it ADF BC, WS hosted by SOA Suite, REST interface exposed by TopLink, etc.   For the purpose of this group, most likely your data would be accessed through Service Interface via ADF BC. 

a.       Note that ADF Mobile supports SOAP, REST/XML with XSD, and REST/JSON.

 

The reason you want to approach this way is, for example, if you decide to cache data, then you would want to design your WS to retrieve all the data you need at once.  If the app is connected only, then you would want to retrieve data based on the context/functionality of your screens in the app.

 

Having said that, the most likely outcome of step 1 and 2 is that you would want to configure a set of VOs/AMs that are optimized for mobile app access, and also expose only the service interfaces needed by mobile apps.  The goal is to keep the interactions and data structure as simple as possible, so you can focus on delivering a great mobile user experience in the app.

 

Speaking of simplicity, so a follow up question to Chris M’s is, well, is the ADF BC SDO interfaces too complex, just right, or insufficient to properly support mobile app access?  Even if you have not done ADF Mobile development, one way you can provide some type of feedback is to try to consume ADF BC SDO WS in another ADF app using the WS Data Control.  Is it pretty easy to invoke SDO-based WS in your app, or you have to jump through hoops just to set the parameters and retrieve data?

 

I have some opinions, but would be interesting to hear what everyone says, especially the ADF Mobile Beta participants in this group.

 

Thanks,

 

Joe Huang

Senior Principal Product Manager

Mobile Application Development Framework

Oracle Application Development Tools

ORACLE

650-506-2271 (Office)

510-282-0369 (Mobile)

 

Check Oracle MEAP, Blogs (for latest updates), and Demos (Hint: open on your mobile phone)

--

[Raed Turkmani]

Chris,

 

Q1 - Can ADF BC generate "light-weight" rest based service endpoints instead of SOAP ones? any disadvantages to not using REST for "green field projects"?

Q2- Any advantages to using Glassfish over WLS as appserver for hosting ADF Mobile Framework (beyond it being free)

Thanks

From: Chris Muir <chris...@gmail.com>
To: adf-met...@googlegroups.com
Sent: Wednesday, October 24, 2012 10:06 PM
Subject: [ADF EMG] Architecting for ADF Mobile - ADF BC SDO web services

[Chris Muir]

In answer:

q1) See my follow up post

q2) ADF Mobile framework isn't hosted from a server, it runs on the
mobile device. You need to distinguish the traditional
web-deployed-on-a-server ADF from ADF Mobile which runs on your
iPhone/iPad/Android device as a native app.

CM.

[Stephen Johnson]

This was something Bex mentioned in our interview.  You shouldn't just plop a web service interface on to your existing AMs, as the user controls, screens and workflows supported by mobile devices can be significantly different from those supported by the standard KVM setup we usually target.  Even an app that was already targeted for mobile browsers may have VOs that don’t necessarily work for a native mobile app.

 

One question I have is, is it possible to set things up so that 2 different applications can share the same set of entity objects and association objects, but then have different VOs and AMs built on top of those?  I've done similar things in the past with other development frameworks by linking parts of the project in as external repositories within the version management system (svn).  Would JDeveloper/ADF support setting up something like that?  Then at least you could reuse the business validations and UI hints implemented in the EOs, but still customize the VOs and AMs to support the workflows being implemented.

 

 

Stephen Johnson

Manager, Systems Architecture

Integretas, Inc.

 

From: adf-met...@googlegroups.com [mailto:adf-met...@googlegroups.com] On Behalf Of Chris Muir
Sent: Wednesday, October 24, 2012 10:06 PM
To: adf-met...@googlegroups.com
Subject: [ADF EMG] Architecting for ADF Mobile - ADF BC SDO web services

 

Phew, now that we're out of the busy OOW period and all the exciting announcements, it would be good to get back to the roots of this group and discuss architecture.

--

[Steve Muench]

Steven, ADFBC is designed for maximum component reuse, so you can:

• Reuse the same entity objects in one or more view objects
• Reuse the same view objects in one or more application modules
• Expose only select top-level application module view object instances (including none) to your SOAP-based service interface for any application, as well as expose zero or more custom AM methods to accept custom parameters and/or return custom view object results that are determined by your custom code

That component reuse works fine whether the components you're mixing come from the same project, or from an ADF Library of components (a glorified JAR file with a tiny bit of extra metadata in the META-INF/MANIFEST.MF file). 

So, you can setup whatever situation works best for your project/team.

One comment I'll make on the use of multiple view objects for the same entity objects. Prior to the 11g version of ADF, developers often created multiple view objects for the same entity object simply because their different application use cases involving that business object's data required filtering or projecting the data in distinct ways. For example, consider an entity object named "Customer", it was routine for developers using ADF prior to 11g to create one VO named "Customers", another VO named "GoldCustomers", and yet another named "ForeignCustomers". Often the only difference in these VOs was the WHERE clause to filter the data and the set of EO attributes (or SQL-derived attributes) included in the VOs select list. In the 11g release of ADF we introduced the handy concept of named view criteria on a view object. This allows a single "Customers" view object to have view criteria like "GoldLevelFilter" and "ForeignAddressFilter". You application can decide to use an "unadulterated" instance of "Customers" VO, or when the use case requires, it can declaratively (or programmatically) apply the "GoldLevelFilter" VC to restrict the data returned to only gold customers, or apply the "ForeignAddressFilter" to restrict the data returned to only foreign customers, or indeed apply both of these filters to get a list of only foreign, gold customers. Also, if the VO is set to use SQL Mode = "Declarative" (on the Query panel of the view object editor), then ADFBC can determine the necessary SELECT list at runtime based on what attributes the current UI's page definition (a.k.a. "Binding Container") is asking to bind in the UI. This will automatically "prune" the SQL query to include only relevant attributes (including cleverly pruning out joins if your UI does not include any of the attributes from joined, reference entity usages. In this way, it is much more possible to create single-purpose, reusable VOs that cater to a multitude of different (re)use cases. Of course, creating multiple VOs based on the same EOs is still available, just often not necessary to achieve most common use cases.

[Benjamin Lenglart]

Hi

I would say that you could use the Virtual private database functionnality in Oracle RDMS product
it will ensure more security to data
it will be available through all you apps, Mobile or not..

It's the question of the architecture dedicated to security .

Benjamin Lenglart

2012/10/25 Stephen Johnson <sjoh...@integretasinc.com>

[Chris Muir]

Great, this is where I was hoping this discussion would get.

Frank and I have been considering mobile architecture for the
enterprise for sometime, but couldn't have an open discussion until we
actually released ADF Mobile! There's an obvious extension to the
angels in the architecture presentation here.

So a idea extending from Stephen's question and Steve's answer, it
would be possible to:

a) put the EOs in a separate project/ADF Library

....and have it consumed by.....

b) An ADF BC project comprised of AMs/VOs to be consumed by a standard web app
c) A separate ADF BC project comprised of AMs/VOs to be consumed via
SDO web services by externally mobile/whatever

-or-

A combination of ab+c, a+bc, abc and just ab if you get my drift.

There's advantages in each approach, with considerations including
dependency management and change impacts, downtime, security, naming
conventions and?

Happy to have anybody to take this discussion further to discuss the
options out.

I'm also interested in the issue of versioning web services. For
anybody who has ever read the screams from developers when Twitter
changes their web service APIs, it's important also to consider how if
you decide to upgrade/change your web services, how not to disable all
the mobile users out there who haven't had a chance yet to upgrade to
the latest version of your mobile app.

This brings in some interesting problems where we may need to run two
or more versions of our web services, and include something in our web
services to tell the consuming ADF Mobile app they need to upgrade
soon before the old web services are decommissioned.

Get's interesting doesn't it? I'm a sucker for a good web service debate ;-)

CM.

[Stephen Johnson]

Thanks Steve.  I knew I could use different view criteria at different times, but I wasn’t aware that the declarative mode could actually dynamically adjust the columns being retrieved by the view object.  That could make a big difference as I can see the need for mobile apps to display a reduced data set from what a standard app provides.

 

 

Stephen Johnson

Manager, Systems Architecture

Integretas, Inc.

 

[John Flack]

I thought that ADF Mobile would support a small local database, like Derby or Berkeley to store data on the device, at least while offline.  Are you saying that ADF BC is not available to talk to these?  If not ADF BC, then JPA?  Or do you have to write some Java to use the native APIs for these, then make POJO data controls.

[Steve Muench]

Shay published some screencasts yesterday that show how to use ADF Mobile with ADF BC using ADF BC's service interface, which is our option that automatically adds a SOAP-based web service access to any AM you choose to so-enable.

https://blogs.oracle.com/shay/entry/developing_with_oracle_adf_mobile

--

[Chris Muir]

Indeed. 

ADF BC is a multi user server based caching solution. How many users do you have on a mobile device. 1. Doesn't make sense to make ADF BC natively available on mobile.

Lets be clear though, yes with ADF Mobile you have access to the devices local store (not Derby or Berkley) through the Java APIs. In saying that it would be great to have a declarative programming solution similar to ADF BC, where JDev has the productive tooling to assist writing to the local db, but for v1.0 that doesn't exist.

But most of this forgets the fact, simply put the local db isn't the major player in mobile solutions for sourcing data, unlike the ADF server version, web services are. Thus the discussion here.

CM.

--

[Edwin Biemond]

Hi,

Well done people :-) , you are almost ready to make the jump to eclipselink where we have off course great performance ( you use coherence), shared cache and with the 2.4 version also JSON support  and with 11gR1 PS5 we can also generate SDO web services.
Don't know if you should use SOAP on mobile devices, it requires a lot of parsing, but maybe this is no problem with the new apple devices.

Will do some tests tonight.

Thanks

[Shay Shmeltzer]

Just to clarify - ADF Mobile does come with a local DB that can be used on the mobile device - it is SQLite, and this allows you to store data and use the application offline.
However, having the full ADF BC layer on the mobile device is an overkill (see Chris's remark on multi-user).
Right now the way you would interact with this local DB is through Java and JDBC coding.
See: http://docs.oracle.com/cd/E35521_01/doc.111230/e24475/amxdatabase.htm#CIAEIGEJ

Shay

[Joe Huang]

Also adding to Shay’s comments.  As you know, there are a lot of other HTML5 Hybrid mobile app development framework out there that utilizes a local DB.  You would essentially be writing JavaScript code to interact with an unencrypted database on the device.  With ADF Mobile, we licensed SQLite Encryption pack so the DB file is secured with a password, and you would interact with the local DB using the JDBC APIs in Java as Shay listed below.  No other HTML5-based hybrid framework can support anything similar as far as I know.

 

Several of the partners/customers participated in ADF Mobile beta testing had also successfully implemented mobile apps using these APIs.  Mobile DB structure typically/should be relatively simple, and JDBC APIs should be sufficient to handle DB access.

 

Nevertheless, one of the beta partners did provide some useful feedback around the need to create some interface to common DB operations.  Simplicity is key here – we should only support operations needed for a local single user SQLite DB, without all the overhead and complexity needed for server-side DB access.

 

By the way, until that becomes available, for all of you Java experts out there, I am sure someone can contribute some sample code/libraries that can be shared by others for DB access.  Anyone interested? J 

 

Thanks,

 

Joe Huang

Senior Principal Product Manager

Mobile Application Development Framework

Oracle Application Development Tools

ORACLE

650-506-2271 (Office)

510-282-0369 (Mobile)

 

Check Oracle MEAP, Blogs (for latest updates), and Demos (Hint: open on your mobile phone)

 

From: Shay Shmeltzer

Sent: Thursday, October 25, 2012 9:56 AM
To: adf-met...@googlegroups.com

--

[joe greenwald]

Chris,

It's interesting you mention web services versioning as a web service
deployed as a composite to SOA
Suite can be set as the "default" service and is called automatically
when that service is invoked.
When a new version of the service is deployed, it requires the WSDL
invocation to specifically add a version number to the url...so beta
testers can use the new version.
Once the new version goes "production" it is marked "default" and all
"regular" users who are invoking the service get the new service not the
old.
So, one option is to put a SOA Suite service in between the ADF BC
invocation.

Joe

>>> don�t necessarily work for a native mobile app.

>>> What I'd like to discuss is how have you been architecting this& what

[Raed Turkmani]

Sure Chris,

 

I was trying to gather pros/cons against using GlassFish to host ADF Framework (for server side hosting of BC logic/webservices) since deploying WLS costs money.

 

RT

> unsubscribe send email to adf-methodology+unsub...@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).
>
>
> --
> 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-methodology+unsub...@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).

--

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-methodology+unsub...@googlegroups.com

[Chris Muir]

Then please start a new thread, and I recommend that you not just ask questions with no context, but as you've done in this last reply, actually let us know the "why" as well.

CM.

[Chris Muir]

Thanks Joe

So I can see in the mobile world, given some users wont upgrade/update
their applications straight away or at all, you'd need to potentially
support several versions at the same time, and provide a web service
mechanism to tell old-version mobile users to upgrade or else (or else
what I don't know, um, maybe we'd send the mobile police around ;-).

If I remember correctly it's a common practice to provide a
heartbeat/status web service which allows the client to ping the
service/server to see that the services are completely up, including
exercising the complete stack of services the published web services
consumes. So in context of ADF BC SDOs this would mean a call down to
the db too to ensure the db connections aren't stale/dead. I can
imagine this wouldn't be a bad idea for debugging purposes, and
something reasonable for enterprise mobile apps, but I'm not sure a
successful consumer app would need such a web service.

Anyway point being I can see the fact that our SOA solutions including
ESB, as well as general best practices for web services would be very
useful to know in a mobile-2-enterprise web service architecture.

CM.

>>>> don’t necessarily work for a native mobile app.

[Joe Huang]

Hi, Chris, I like the discussions around exposing ADF BC to mobile apps - this is the exactly the type of discussion we should have.

However, at the risk of taking it to a completely different direction, here is a blog article that might be of interest, since SOA suite is brought into the discussion: https://blogs.oracle.com/fusionmiddleware/entry/lab_submit_an_expense_report.

I had been working with the SOA teams to extend Oracle apps to mobile devices via SOA Suite for a while now, and there are some best practices around that. It's useful for integrating Oracle apps and other types of back-ends, and I believe SOA Suite has ADF BC support as well, correct?

Anyways, I think that's a separate discussion, and I do like the general focus of the discussion here to be around exposing ADF BC as SDO Web Services for mobile consumption. This would be valuable to hook ADF Mobile apps into ADF BC-based Enterprise Apps, without necessarily SOA Suite in the middle.

Thanks,

Joe Huang
Senior Principal Product Manager
Mobile Application Development Framework
Oracle Application Development Tools
ORACLE
650-506-2271 (Office)
510-282-0369 (Mobile)
 

Check Oracle MEAP, Blogs (for latest updates), and Demos (Hint: open on your mobile phone)

-----Original Message-----
From: Chris Muir [mailto:chris...@gmail.com]
Sent: Thursday, October 25, 2012 5:24 PM
To: adf-met...@googlegroups.com

[Chad Thompson]

On Oct 25, 2012, at 7:41 PM, Joe Huang <JOE....@ORACLE.COM> wrote:

Hi, Chris, I like the discussions around exposing ADF BC to mobile apps - this is the exactly the type of discussion we should have.

However, at the risk of taking it to a completely different direction, here is a blog article that might be of interest, since SOA suite is brought into the discussion: https://blogs.oracle.com/fusionmiddleware/entry/lab_submit_an_expense_report.  

I had been working with the SOA teams to extend Oracle apps to mobile devices via SOA Suite for a while now, and there are some best practices around that.  It's useful for integrating Oracle apps and other types of back-ends, and I believe SOA Suite has ADF BC support as well, correct?  

SOA Suite (and the various enterprise integration scenarios) also bring up another interesting question - profiling web services (SDOs, SOA Services) for performance.  In the development and testing of ADF Mobile, were there good recommendations (other than 'the faster the better') for ADF Mobile and/or ADF Mobile on wireless connections?

Enterprise integrations and BPEL services can often get into the notion that 'not every SOA Service is created equal', given either size and complexities of BPEL processes, or even complexities of SQL queries underneath service layers, etc.  (I've seen this in WebCenter projects where a 'good enough' SOA service for an integration process is completely unworkable in an interactive WebCenter portlet, as an example.)

- Chad

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

[Tapash Ray]

Couple of other considerations - 

1. Once we have the SDOs, how do we expose them in a secure way ? Most of the "base" stations that the mobile apps need to connect to are within enterprises. And there needs to be some best practices around exposing the SDO services from within the enterprise, with security. Something similar to advanced DMZ topology that Oracle applications has for exposing internet enabled modules like iStore, iSupplier etc.

2. Not all base stations are Oracle ADF SDO services, for example Oracle applications R12 has something called a integrated SOA gateway, which exposes web services for getting most of the work done within the ERP. How about a single approach to consume any kind of service, be it ADF BC SDO service, or a SOA gateway service or a plain simple Java Web service from ADF mobile ?

My observations are mostly based on wants and needs of customers who I advice as a ADF/SOA consultant.

Thanks,

Tapash

---

Subject: Re: [ADF EMG] Architecting for ADF Mobile - ADF BC SDO web services

From: chad_t...@mac.com
Date: Thu, 25 Oct 2012 21:00:59 -0500
To: adf-met...@googlegroups.com

[Edwin Biemond]

hi,

be carefull with sdo and adf bc especially in combination with oracle soa suite and adf , there are still a lot of bugs which need to be solved first. I know some projects which needed to stop with adf bc sdo ( architect demanded sdo ) and they moved to JPA SDO with eclipselink and this worked perfectly in ps5 with soa suite and adf. and you have the choice to use the fast ejb or ws sdo interface.
but you need to have a jpa,ws , eclipselink expert to make this a success.

thanks

[Joe Huang]

Hi, Tapash:

 

1.       This is a pretty hot area for mobile right now.  One approach is to use VPN, although it can still be considered as security risk because your crendential/point of authentication is on a (easily can be lost) mobile device.  Using a multi-tiered network architecture (mobile device -> web server proxy (in DMZ) -> App server/Oracle apps) is a common approach but many IT shops (including Oracle) does not allow server in DMZ to go inside the corporate network.  BlackBerry Enterprise Server solved this by using a NOC-based infrastructure, and a few of the MDM vendors also have similar infrastructure, where only trusted mobile devices can access the corporate network.  We are actively engaging these MDM vendors, as well as having internal discussions with Oracle Idm team, on recommendations/integrations to solve this.  Let me know if you are looking for recommendation for this or if you have already been working with some vendors/solutions in this area, and we can discuss how to meet the security requirements.

2.       On the EBS SOA gateway, it is based on Oracle SOA Suite anyways.  As far as ADF Mobile certification is concerned, for SOAP-based web services, we focus on certifying against ADF BC/SDO based and SOA Suite-based SOAP web services.  Both are valid and the choice comes down to what backend app(s) you are connecting to.  Of course ADF Mobile is designed to be able to generically support standard SOAP or REST services, but as I am sure everyone is aware, not all WS are the same and compatibility is not guaranteed.  If there are any specific type of WS/backend we should add to our certification list, please let me know.

 

Thanks,

 

Joe Huang

Senior Principal Product Manager

Mobile Application Development Framework

Oracle Application Development Tools

ORACLE

650-506-2271 (Office)

510-282-0369 (Mobile)

 

Check Oracle MEAP, Blogs (for latest updates), and Demos (Hint: open on your mobile phone)

[Joe Huang]

BTW this brings up an interesting point. To clarify, ADF Mobile's Web Services implementation is not the same as ADF's web services implementation. What works/does not work in server-based ADF may not apply to what ADF Mobile supports. This is because ADF Mobile embeds a JavaME CDC VM, and we had to rely on libraries like KSOAP to provide the WS support. We cannot possibly test against or predict all Web Services backends. We did our best to conform to all WS standards, and our eng has to put in a lot of effort to implement WS support. However, if you happen to encounter WS compatibility issues, please do let us know/file bugs (if you work for Oracle), file a SR (if you are an Oracle customer/partner), or just directly email me.

Thanks,

Joe Huang
Senior Principal Product Manager
Mobile Application Development Framework
Oracle Application Development Tools
ORACLE
650-506-2271 (Office)
510-282-0369 (Mobile)
 

Check Oracle MEAP, Blogs (for latest updates), and Demos (Hint: open on your mobile phone)


-----Original Message-----