The most recent buzzword in the IT industry is SOA, short for service oriented architecture. SOA is the current favorite of IT managers, system integrators and IT vendors, yet few managers, integrators, or vendors agree on what it really is. SOA is not a product, technology, or architecture. SOA is just a concept for integrating applications. Manufacturing professionals should know what SOA is because they will be asked to interface their systems to other systems using an ESB backbone and an SOA model. The ESB is the pipeline between applications, routing messages and buffering requests and responses. SOA defines what travels through the pipe.

The basic SOA concept is that any interface to an application should encapsulate a business service, such as processing a purchase order or performing a physical count of an inventoried material. Calling a service causes the execution of the associated business process. For example, a service may be “assign a storage container ID when material arrives.” The service requires a material lot ID and returns a number for a storage container. The SOA interface could be a service named “AssignStorageContainerID.” The service interface is published to the ESB by the application that assigns container numbers. The application probably performs other processes when assigning the ID, such as recording the assignment, sending the storage number to a warehouse system so that the container is recognized when it arrives, and assigning the container status as “in-use.”

SOA is based on six assumptions: applications are loosely coupled; interface transactions are stateless; interface follows the RPC (remote procedure call) model; interface is message-based; messages use XML data; and interfaces may support both synchronous and asynchronous transactions.

Applications are loosely coupled when the availability of one system does not significantly affect the other system and when the implementation of a service is hidden from the caller. A stateless interface has no implicit history; each use of the interface is based only on the exchanged data and does not use hidden knowledge maintained by the service provider. The RPC model means that the interface looks like a local function or subroutine call and the caller does not have to handle any details of interface messages. A message based interface sends messages between the applications using an ESB, and the messages are based on XML data, not flat files or a proprietary binary interface. The services may be synchronous, in which there is a request for the service and a wait for a response. Alternately, the interface may be asynchronous when the caller makes a service request, continues other processing, and the response comes back later.

These simple SOA concepts are difficult to implement in existing systems. The key is defining the appropriate level and type of services your systems provide. Services can be fine-grained, meaning they perform small actions such as changing one element of data, or coarse-grained, meaning that they encapsulate significant business processes. Coarse grained services are the preferred model for SOA applications, but fine grained services are also often needed.

Manufacturing personnel must assist in corporate SOA initiatives by identifying the critical coarse and fine grained services that manufacturing systems perform. Focus on the business processes that manage the physical control and movement of materials, equipment, and personnel. Coarse grained services will reflect major actions, such as production, testing and maintenance, while fine grained services will handle detailed information on specific materials, equipment, or personnel. Remember that SOA is not an out-of-the box solution; implementing SOA requires a good understanding of manufacturing’s role in the corporate supply chain.