MobileFabric: When to use Integration Service vs Object Service?
Ajay Bhat - Mar 31, 2017 - Integration
In this post, Rahul Roshan and Gautam Goenka discuss the relative merits of using Object Services vs. Integration Services while building your mobile apps.
An Integration Service is an application component that represents the application interaction with an external system or data source. A service definition comprises the meta-data or the configurations required to exchange data with the external system or data source. For more, refer documentation here.
Object Services is a feature of MobileFabric that enables model-driven app design and development by following a micro services architectural approach to create reusable components. With Object Services, you can define your preferred app data model that defines how your application wants to interact with its data. There is a clear separation between the app data model and how it maps to the back-end systems of record. The defined app data model and mappings encapsulate the back-end data and APIs thereby abstracting the API complexity from your client application. For more, refer documentation here.
Integration Service or Object Service?
In many ways, both Integration Services and Object Services helps to pull data from external systems, transform it to render in the application, and then push it back to external entity. So, the natural question that arises is when to use which one? When should one prefer Integration Service vs when should one use Object Service?
This question is analogous to when should one use Functional Programming vs Object Oriented Programming. Different experts will give you different answers – starting from philosophical (both are same) to strongly opinionated ones. Integration vs Object Service debate is no different – at a philosophical level, both are indeed the same and are built on the same core engine. The default is to just go with Object Service, the way we default to Object Oriented Programming. You can refer a white paper on app development using Object Service here.
Advantages of Object Service
- Service Driven Objects: If a user has a legacy app/service and he wants to use an Object Service, he can create an Object Service on top of the Integration Service. This is known as Service Driven Objects.
- Accelerates back-end development by automatically discovering metadata via business adapters for easy integration at the back-end data object level.
- Automatically generates back-end data object code reducing time, labor and cost.
- Accelerates frontend delivery by generating the client app code from the object model leveraging reusable or easily created app data model objects.
- Reduces application complexity and cost of maintenance by:
- Maintaining development consistency by using a standard model–view–controller (MVC) framework.
- Avoiding rework by generating app data model object code to extend existing apps to add new data and functionality.
- Sharing objects or groups of objects between client applications to reduce rework and ensure consistent interaction with back-end data systems.
- Configuring the defined objects to utilize the MobileFabric Sync Services to make the objects available offline. This allows the user to continue using the client app without a network connection and they can then sync their changes once a network connection becomes available.
- Integration within MobileFabric to provide seamless incorporation of other key mobile back-end as a service functions required for back-end mobile development.
- Object Services doesn’t stop with the initial release of the app. Subsequent releases are also three to four times faster because new features are built following the same approach.
- Update App Data Model
- Map to Back-end System
- Re-Generate Client Code
- Keep posted App Presentation Layer
- Map Updated Model/Controller to UI
When you may not use Object Service
- No reusability requirement: When a user is doing a quick PoC or if the user does not want to share components across different applications, Integration Services could be simpler and less costly.
- Legacy app/service: When backend APIs don’t change too frequently or if you already have service definition defined etc.
- Pass through APIs: When a user is looking for pass through APIs for architectural reasons (like security) and does not want to do any manipulation or transformation of request and response data.
Object services are recommended for a large percentage of core app development. They are viewed as the default approach which will bring in significant savings for developers and it will also greatly augment overall productivity.