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.
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;
Operations capacity 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.
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 ( www.oasis-open.org ) 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.
Specifications and tools
SOA is based on six principles:
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.
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.
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.
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).
Messages use XML data. The messages are based on XML data—not flat files or a proprietary binary interface.
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.
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.
Annual 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.