Developing a Service-oriented Architecture (SOA)-based e-commerce services platform for one of the leading online auto parts provider

The client is one of the leading online providers of auto parts and accessories in the US and offers a wide range of high-standard replacement parts, performance parts, and accessories.


Business Problem  
The key systems of the organization such as Order Management System, Inventory System, Catalog System, Warehouse Management System, E-commerce websites, and Customer Service Console were developed in heterogeneous platforms such as PHP and Java. 
However, the following problems existed:        

  • The data or information communication among various systems was becoming increasingly difficult. A lot of redundant functionalities existed for inter-data communications for a single purpose
  • No standard way of communication or interaction between any two systems was in place.
  • No single repository of services was in place.
  • Interfaces were not extensible, and scalability was an issue.
  • Any changes in one system had unknown effects on other systems and attracted complete system regression, thus increasing the go-to-market timeline.


Business Solution – SOA Service Layer:   
While we evaluated several technology model solutions, we zeroed down on developing a Service-oriented Architecture (SOA) model to address these problems while providing a scalable and extensible system to be consumed by the E-commerce ecosystem. The services in the SOA Service layer were available to systems across the organization with a well-defined access control mechanism and provided a common interface to get desired data from the required systems. For example, to get the Product information from the Catalog system, the SOA Service layer provided an interface that any other system could use. Hence, there was a single point of interface, and any changes made to the service were abstracted at the Service layer.   
The SOA-based Service layer had the following features:           

  • Orchestration: The SOA Service layer used orchestration to serve a business request and use the various available de-coupled service components to form a response as per the requestor’s need.
  • It was a technology platform that was language-agnostic. It used a standard way of communication over the web through web services with Representational State Transfer (REST)-based protocol and provided data in JavaScript Object Notation (JSON) objects format.
  • The Service layer architecture being service-oriented was highly extensible.
  • It offered a single repository for all the services. Any system could explore available services and use it. The scale-out option was possible and came out of the traditional scale-up model.
  • It provided a means for rapid development and quality check of the new services.



The following systems started consuming SOA services:

  • The E-commerce website used SOA services to:
    • Get product, brand, categories, attributes, assets, and pricing information. SOA services connected to the Catalog system to get the required information, message it, and send it.
    • Push orders to the downstream supply-chain system such as the Order Manager System.
    • Do My Account information management.
    • Get inventory information.
    • Introduce a content service that used NoSQL data such as MongoDB as the back-end storage and help in publishing contents on various sites.
    • Centralize the shipping calculation service.
    • Execute SEO services to manage various on-page SEO components.
    • Centralize the coupon system to allow publishing different coupons on a different web.
  • The Catalog system used SOA services to get inventory information and send it to the Warehouse Management System (WMS).
  • Mobile applications used SOA services to get all the product information and other Mobile Commerce-related information to manage the transaction life cycle and content syndication.


SOA SERVICE LAYER ENVIRONMENT:

  • The SOA Service layer instances were deployed on multiple servers to serve traffic using the load balancer.
  • This layer was hosted on a private network of the organization and exposed through the proxy layer.
  • Memcache was used for service cache. This cache reduced the load on hardware and expedited the response.
  • The MongoDB database was used for access and error log.
  • The Service signature made services secure from any external sources.
  • The Custom Alerts system helped to find out failure in any systems and downstream systems.
  • The Service Discovery tool helped to easily find out available versions of services and methods under it.
  • The Dashboard displayed status of various dependent systems and replication status and current deployed versions.


Tools and technologies:       

  • PHP 5, REST, JSON, JavaScript, SOAP, My SQL 5.0, Mongo, Web Services, XML, Memcache
  • Red Hat Linux 4.x, Apache 2.0.52