Service Oriented Architecture and its Impact on Automation

Service oriented architecture (SOA)-everyone seems to be talking about, teaching, selling, or implementing it, but there is also a lot of confusion about what it really is. This article is a guide to understanding what it is, how it works, and how it applies to manufacturing-related applications.


SOA is not a product or a technology or even an architecture. SOA is a set of principles for integrating software applications in a way that minimizes the complexity and number of interfaces between applications, therefore providing the most modularity for software evolution and support.

The principles of SOA define rules for deciding what software applications should support what functions and the type of information the applications need to exchange. As a result, the potential of SOA-structured systems is that they have cleanly defined interfaces, that the interfaces relate to well-understood business or operational data, and that the applications are focused on well-understood business or operational processes.

Conversely, the downside of SOA is that there are still few SOA-related success stories because many IT organizations are using SOA tools, but not yet implementing the SOA principles. SOA tools include Web services, enterprise service buses, XML gateways, SOAP (simple object access protocol) models, and REST (representational state transfer) models. These tools are the current best methods for application integration. However, just using SOA tools does not mean that systems follow SOA concepts.

The two general models for SOA implementations: orchestrated and choreographed. Orchestrated models feature coordination of coarse-grained services to implement business processes. Choreographed models do not have this coordination; instead, one corase-grained service may trigger another.

The two general models for SOA implementations: orchestrated and choreographed. Orchestrated models feature coordination of coarse-grained services to implement business processes. Choreographed models do not have this coordination; instead, one corase-grained service may trigger another.

SOA’s role in execution

The key to understanding what SOA means to manufacturing-related technologies and processes is to focus on software services. There are two general classes of services related to SOA: fine-grained services that deal with small pieces of data, and coarse-grained services that deal with larger collections of data. The large collections of data are called business objects and the services are actions on the objects. Often a combination of coarse- and fine-grained classes is needed for any integration project.

Coarse-grained services in the business world deal with objects such as purchase orders, invoices, checks, shipment receipts, transportation orders, advanced shipping notices, and inventory. Typical actions include creating purchase orders, sending advanced shipping notices, and moving inventory between plants. An SOA system would have integration interfaces that follow the action-object interface model (where the interface specifies the action followed by the object the action will be performed upon) with larger actions occurring on big and complex objects. Examples of business system interfaces in this instance would be things like: “create shipment receipt”; “make vendor payment”; “pay invoice”; and “create transportation order.”

Coarse-grained services in the manufacturing world deal with objects such as production schedules, production reports, certificates of analysis, laboratory test results, maintenance schedules, and inventory. Typical actions include publishing of production schedules, creating laboratory test results, and moving inventory between production areas and warehouses. Examples of manufacturing system interfaces are “execute production schedule”; “move material lots”; and “assign material to storage container.”

Fine-grained services are data query services, not action services. A query service deals with a small piece of data that is managed by one system but is also needed by other systems. Typical fine-grained queries include “get storage location of lot”; “get new lot ID”; and “get equipment status.” If the system has only fine-grained action services and no coarse-grained services, then it is not SOA, even though it may use SOA tools. One common problem with SOA implementations is the use of a large number of fine-grained services, but with no partitioning of services by business objects.

Manufacturing services generally fall into the following areas:

  • Production order management;

  • Production response management;

  • Maintenance operations management;

  • Lab management;

  • Inventory management;

  • Operations capacity management;

  • Receiving management;

  • Shipping management;

  • Manufacturing master data management (MDM); and

  • KPI (key process indicators) and OEE (overall equipment effectiveness) calculation, monitoring, and management

These services deal with organizations, locations, personnel, materials, equipment, containers, and tools. From an SOA perspective, the coarse-grained objects would relate to ANSI/ISA 95 objects such as production schedules, production performance reports, operations schedules, operations capabilities, and recipes.

Implementation models

There are two general models used for SOA implementations: an orchestrated model and a choreographed model. In the orchestrated model, there is a coordination service that contains the rules that sequence the coarse-grained services to implement the business process. Coarse-grained services in a well-defined SOA system will also use fine-grained services. The coordination services typically use BPEL (business process execution language) to implement business rules. BPEL is an OASIS ( ) standard for specifying interactions with Web services.

The orchestrated model isolates business processes in a coordination layer, allowing the coarse-grained services to focus on the business objects. Many modern business systems follow the orchestrated model because it improves modularity and reusability of services. Although there is a performance penalty using this centralized coordination service, the impact is usually not significant at the relatively slow speed of business processes. When real-time is measured in minutes, extra messages and rule interpretation are significant only if hundreds of messages a minutes must be processed.

Choreographed models differ from orchestrated models in that there is no overall coordination layer in the choreographed model. A coarse-grained service may trigger downstream coarse-grained services. The business process is defined by the collection of rules implemented in the coarse-grained services. The choreographed model can handle faster process times and is therefore the model most often used in manufacturing applications and in customer-facing Internet applications. Both of these applications must handle thousands of messages per minute with minimal latency and delays.

Understanding the difference between SOA specifications and tools: SOA specifications include definitions of business or operations processes, their objects and transactions. SOA tools are applications that implement business and transation services.

Understanding the difference between SOA specifications and tools: SOA specifications include definitions of business or operations processes, their objects and transactions. SOA tools are applications that implement business and transation services.

Specifications and tools

SOA is based on six principles:

  1. Applications are loosely coupled. 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 requesting application.

  2. Interface transactions are stateless. A stateless interface has no history associated with it; each use of the interface is based only on the exchanged data and does not use hidden knowledge maintained by the service provider.

  3. Interfaces follow the RPC (remote procedure call) model. The RPC model means that the interface looks like a local function or subroutine call and the calling program does not handle the message details and communication protocols.

  4. Interfaces are message based. A message-based interface sends messages between the applications using an enterprise service bus (ESB). An ESB provides fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus).

  5. Messages use XML data. The messages are based on XML data—not flat files or a proprietary binary interface.

  6. Interfaces may support both synchronous and asynchronous transactions. The services may be synchronous, i.e., there is a request for the service and a wait for a response. Alternately, the interface may be asynchronous, with the application making a service request, while continuing to handle other processing, and the response arriving later.

SOA principles are highlighted in SOA specifications and SOA tools. The SOA specifications include the definition of loosely coupled business or operations processes, services that implement the processes, objects that contain the service information, and transactions that define the coordination of services and objects. SOA tools are applications, application services that implement business services, standard messages that represent the business objects, and integration services that implement the transactions.

SOA will affect manufacturing systems as their use becomes more ubiquitous in internal and externally linked applications. As a result, operations systems and control systems will have to operate in an SOA environment and coordinate with other SOA-defined applications. This means that control applications will need to expose their core business functions as loosely coupled coarse-grained services and expose their shared data through fine-grained synchronous services.

For example, a coarse grained service may be a command to an automated guided vehicle from an MES system to move material between a warehouse and a production location, while a fine grained service may be a request for the bar code number of the pallet being moved.

Application of SOA principles will simplify manufacturing systems because the principles are consistent with the best practice models of loosely coupled business and manufacturing systems. SOA principles are also entirely consistent with the best practices for manufacturing system security. To keep your systems up-to-date with the increasing use of SOA, you should look to begin widely applying SOA principles in your manufacturing applications.

Author Information

Dennis Brandl is president of BR&L Consulting in Cary, NC, . His firm focuses on manufacturing IT. Contact Dennis at .

No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.