On March 4th, I am to present – together with ADF and Mobile Application Framework expert Luc Bors – a live development demo session at the EMEA Oracle Fusion Middleware Partner Forum in Budapest, Hungary. Luc and I are in the middle of our preparations for this event. And I thought perhaps it would be nice to share some of the background for this session.
It all started in the Fall as Jürgen Kress, responsible at Oracle for Fusion Middleware Partner Adoption EMEA, sent out a call for papers for the Forum, looking for proposals for presentations and other types of sessions. Luc and I prepared a proposal for a session where we would do live development (always appealing for the audience and somewhat nerve racking for the presenters) and show the development of a mobile app (using Oracle MAF) on top of a mobile back end (created using SOA Suite 12c and its REST capabilities). Luc and I have done similar sessions in the past. They can be a lot of fun – and be quite stressful because of all the things that can and typically will go wrong.
Jürgen accepted our proposal, invented the title (Live Mobile Hacking with an OFM 12c red stack) and allocated a general slot for us: a full hour as the last section of the second day.
The Case
That was several months ago, and now the event is imminent and we better start preparing in anger. First of all we needed a case: what would be the storyline for our live demo? We decided on the airline industry – inspired perhaps a little bit by the airport case that provides the backbone for the book I am currently writing on SOA Suite 12c. A flight provides a good example of an application that does not have constant connectivity – one of the features we would like to demonstrate. Everyone partakes in flights from time to time. And between flight attendants, ground staff and the back office systems of the airline and the airport, it would not be hard to find interactions that we could use in the demo.
Last week we started discussing the case in anger. And we ended up with the following storyline:
The mobile app runs on a tablet and is to be used by flight attendants. The app allows the flight attendant to retrieve details about today’s flight. Then, the passenger list can be presented and the status of each passenger can be verified and updated. The status of the flight can be updated, from waiting to boarding and from boarding to closed. These updates are immediately sent to the back office for synchronization to the terminal displays. During the flight, with the app in offline mode, the app can be used to record complaints and suggestions from passengers, for example with regard to malfunctioning entertainment systems, immovable chairs, great or poor food and rude behavior by the cabin staff. Details are recorded including passenger contact information. When the plane has landed, the app reconnects and the data recorded in off line mode is uploaded to the back office. For each complaint, a BPM process is initiated and an email is sent to the passenger who lodged the complaint. A human task (or even an ACM case?) is created to handle whatever the complaint is about.
The Outline of the Session
Once the case was decided, we could create the outline for the session itself. What is a good way to bring across the main concepts? What will fit in one hour? What is the logical order to explain and demonstrate? What are the essential elements that we should include and create live – and what should be prepared and only demonstrated in the end-to-end case? We quickly decided on the following outline (still open to change):
- 10 Intro of the case and the technology stack; overview of the end to end case/application architecture
- 20 Brief intro SOA Suite 12c; Intro/demo existing SOAP services; demo REST/JSON enabling of SOAP services; demo of REST services from browser or SoapUI
- 20 Brief intro of MAF? Demo development App and UI and the interaction with REST services
- 5 End to end demo of a flight (flight details, passenger list, flight status (boarding, closed); record complaint about TV screen and start of BPM process (send mail)
- 5 Short summary of what we have shown and demonstrated, of how this type of development (Mobile App/Mobile Oriented Architecture/SOA back end) usually goes; some conclusions/tips
It should be doable, it does paint a useful and fairly complete picture. It will be challenging – so many different moving pieces, so many things that can go wrong and mundane things like switching the cable to connect to the projector between our laptops and finding a way to create the connection between our laptops.
The Interface
Luc and myself hardly ever meet in person. Our communication is through email mainly. So actually collaborating through close and intense personal interaction is not really an option. The architecture for our application does not really require very frequent conversations: the layered, service based approach allows for a very decouple way of discussing, designing and implementing the application – a core strength of the approach. Luc does not require in depth knowledge of SOA or service implementation and database interaction and I need no knowledge at all about the Mobile Application Framework and the development of a mobile UI and its features.
Crucial however is the careful design of the interfaces of the services and their operations – or in REST terms: the resources and their attributes. What resources are available (Flight, Passenger, Complaint) and which operations are supported on each resource? What search parameters are supported? What is the (JSON message) format for the request and response messages? What are the (URL) paths for the resources?
Once Luc and I have agreement on these interfaces – we can do our work in splendid isolation: Luc can work from a mock implementation of service interfaces upwards to create the mobile application and its capabilities. Meanwhile, I will create the back office systems and services: the corporate database for the airline, SOAP Business Services and the BPM Complaint process. Then I will use the REST adapters in SOA Suite 12c to expose the agreed upon service interfaces as both RESTful and JSON-speaking. The business services and the RESTful endpoints can be tested and when accepted can be made available to Luc. He replaces the reference to the mock implementation of the service interface with the end points for real services and the end -to-end chain is established, all the way from the mobile app with off-line mode to the corporate database and process engine.
Designing the resources and operations has to be done carefully, as changing design details can have substantial impact. The exact definition of the attributes and the JSON message format is not as important because we are quite flexible in changing those at a later stage.
The operations my RESTful services will provide to Luc for consumption in the MAF app are:
- retrieve flight details: GET – http://host:port/FlightService/FlightService/flights/<flightCode>?flightDate=<date of flight>
- retrieve passengerlist for flight: GET – http://host:port/FlightService/FlightService/flights/<flightCode>/passengerlist?flightDate=<date of flight>
- update status of flight: PUT – http://host:port/FlightService/FlightService/flights
- file a complaint from a passenger: POST – http://host:port/FlightService/FlyingHighCustomer/soa-infra/resources/default/CustomerService!1.0/CustomerCareService/complaints
In a follow up article I will provide details about the back office (SOA Suite, BPM Suite, Database and the interaction between them and the exposure through REST/JSON of them) as well as how we made our two laptops work together.
