Skip to main content

Object orientation and Service orientation

Object orientation is all about modeling the real world information mainly through encapsulation, abstraction, polymorphism, containment, inheritance and so on. In simple words, an object contains the data structures and methods to change the content state. A typical OO run-time manages the life cycle of objects. You can create as many objects as required as long as the run-time does not over run its memory.

Service orientation requires you to encapsulate a process. The operations of a services are interaction points with the particular process. Data structures are the arguments for these operations. Service run-time shall validate the correctness of the process. Service can have multiple invocation instances, not multiple instances of service itself.

Example: TrainTicketBookingService involves a process.
- Check the train timings //  interaction point
- Check the seat availability // interaction point
- Issue ticket // interaction point
There could be many ticket counters that provide this service, but as a service, TrainTicketBookingService is the only service.

It is possible to design service oriented architecture through well defined process with object orientation. However, we always need to keep in mind, our goal is the service implementation, not to expose object interactions.

Comments

Post a Comment

Thanks for your comments.

Popular posts from this blog

Essential GCP services for a new age application

Identity and resource management IAM  Identity aware proxy Resource Manager Stackdriver Monitoring Stackdriver Monitoring: Infrastructure and application monitoring Stackdriver Logging: Centralized logging Stackdriver Error Reporting: Application error reporting Stackdriver Trace: Application performance insights (latency) Stackdriver Debugger: Live production debugging Development management Cloud Deployment Manager: Templated Infrastructure deployment Cloud Console: Web based management console Cloud shell: Browser based terminal/CLI Development tools Cloud SDK: CLI for GCP Container registry: Private container registry Container builder: Build/Package container artifacts Cloud source repository: Hosted private git repository Database services Cloud SQL: Managed MySQL and PostgreSQL Cloud BigTable: HBase compatible non-relational DB Cloud Datastore: Horizontally scalable non-relational (ACID) Cloud Spanner: Horizontally scalable relation...
Post a Comment
Read more

GCP: GAE - Memcache best practices

Memcache is a distributed in-memory data cache in front of or in place of robust persistent storage for some tasks. GAE includes a memory cache service for this purpose. Best practices for using memcache: 1. Handling memcache API failures gracefully; Do not expose errors to the end users 2. Use batching capability of the API when possible 3. Distribute load across your memcache keyspace Use sharding and aggregating for improving performance efficiency. Use TTL (expiration policy) to make sure the memcache does not fill-up indefinitely Use getIdentifiable() and putIfUntouched() for managing the values that may get affected by concurrent updates Use batching (getMulti ("comments", "commented_by") ) to fetch related values together instead of one by one Use graceful error handling
Post a Comment
Read more

RAID Levels: Redundant Array of Independent Disks

Standard RAID levels comprise of configurations that employ the techniques of * STRIPING * MIRRORING * PARITY  to create large reliable data stores using general purpose HDDs. Levels are standardized by SNIA (Storage Networking Industry Association) in Common RAID Disk Drive Format (DDF) RAID 0 >> STRIPING (No fail-over, No Redundancy, Total loss of information if disk fails, each disk size will be of smallest disk size in the set of the disks) RAID 1 and its variants >> MIRRORING (Copy of write will be in more than one disk, Redundancy, less performant) RAID 5 >> Distributed PARITY RAID 6 >> Dual PARITY Source:   Wikipedia
Post a Comment
Read more