SOA
SC (Services computing) and SOA are a programming paradigm and an architecture/framework, respectively, that enable programmers to isolate functionalities common amongst different parts of the application (termed cross-cutting concerns) and implement them elsewhere as common "services". Without SOA, the common functionalities may have to be directly implemented inside many scattered code modules and it makes it harder to understand the code and to efficiently maintain/revise the shared functionalities (because of the repeats or variations). Those common functionalities are abstracted out as "services" and implemented as separate code units. These services have to be deployed into an SOA system and the SOA makes them available to the codes to the service consumers (SC). The services are accessed via service interface.
An SOA framework should define how to install services (including service declarations and deployment) and how they can be used. IBM uses a term SC (service coordinator), as a service user, and the services are called service prividers (SP). I, however, think that both service user (SU) and SP are made possible to operate together by SC on a system which supports the SOA.
Some other people, however, uses the abbreviation SC (service consumer). Reference: "Delving into Service-Oriented Architecture" by Bernhard Borges, Kerrie Holley and Ali Arsanjani. September 17, 2004.
With SOA, modules which need to use the services may know what services are available and how to use them (via interface). Without a standard SOA, each application may have to come up with a proprietary way to install and to make the services available to any modules which wish to use the services. Also, having a common interface allows different developers to work on the services and the service users independently.
If the services are implemented as Web Services, the services do not reside on the same system as the service users. The services are deployed on Web Service containers and are accessed across the networks via Web Services interface.
The reason why the SOA is preferable to others, is that, as a programming paradigm, it is logical to pool those "cross-cutting concerns" in building an application and this is expected to make the program using the "reusable" and "maintainable" principles.
In real situations, however, multiple "service consumers" use the resulting service and whether they are requesting a singular service or multi-faceted service becomes a problem. One article (2007-04-27) claims that a report from the financial sector who was an early adaptor is reporting some problems. This seems to be caused by interpretation and application of SOA to build a multi-functional service. In a multi-functional service, multiple "service consumers" may require the service responding slightly differently in different requests and situations, and the service may be designed to cater them all. Although this does not sound like a proper use of the SOA principle, naturally designing and building such multi-functional services become more costly, codes may be unreliable, and quickly it may become hard to maintain.
SOA does not work without an SOA supporting system. If the system gets complicated, unreliable or inefficient, an application built on an SOA would be undesirable. Also, some SOA system is built to offer the Services to the users rather than the system using the Services internally. If the UI is exposed directly by the Services to the users, there is an additional problem with overall control and the QA issues.
Finally, although the SOA is supposed to take advantage of multi-vendor contributing different Services, QA and authentication/authorization may become an issues in contrast to the situation where all the Services are developed in-house.
Workflow and SOA
Workflow is another programming paradigm to isolate the flow aspect of application from the rest of the code. In conventional programing, the workflow analysis is done only during the development phase of an application and the implementation is embedded inside hard-coded modules to achieve the workflow at runtime in a fixed manner. In a "workflow application", however, workflows can be authored or manipulated at runtime to change the application behaviour.
When SOA is used in workflow application context, it enables the programmers to hide the implementation details of the workflow nodes. Various types of workflow nodes can call abstract services rathern than implementing individual codes directly inside all those node types. Node types are repeatedly used in different workflows, so this is an ideal situation to use SOA design pattern. Workflow contains the normal nodes, such as, Tasks or Activities (naming depends on the specification or modeling). In addition to Tasks or Activities, workflow contains other notations, such as, gates, event triggers or receivers, branching, loop, merge points, and so on. These can be provided by corresponding services, as well.
In SOA terms, for example, each workflow activity which calls upon a required service from a SP (service provider) may be regarded as an SU (service user) or SC (service consumer). Workflow then is regarded as SC (service coordinator). The whole workflow system is an SOA system which supports/implements the API, framework, code contracts, protocols, etc.
SOA allows programmers to make so-called composites applications, i.e. applications are composites of multiple services. (In addition, the SCA (Service Compoments Acrchitecture) introduces concepts such as Components and SCA Domains, which are higher level of composites.)
However, Sun Miscrosystems and Microsoft point out that, although composites provide some internal "wiring", merely making composites does not make the application work. It requires mechanism for (1) the services to talk together (JBI and ESB, Sun Microsystems), (2) to interact with user interface (e.g. IBF, Microsoft, is designed to do so) and (3) to be able to manage cohesive application logic.
Workflow can supply the application logic in terms of how the services are meant to work together. If the workflow has human interface, it should be able to handle the user interface aspect, as well. Supplying application logic is what technologies such as BPEL, BPMN, ebXML, WS-CDL are desgined for, while LAMS type of workflow, which presents human interface, can deal with the human interface problems.