Component meets service: what does the mongrel look like?

Abstract

Computing with services has attracted much attention as a promising approach for developing distributed applications. The approach is often advertised as being superior to distributed component-based software engineering (CBSE), because it provides a higher potential to bridge heterogeneous IT application and infrastructure landscapes. It facilitates cross-institutional cooperation, lets services run over all kinds of ubiquitous communication infrastructure, scales better and simplifies legacy software integration. If this were absolutely true, there would be no reason for a consortium of major vendors of service and Java EE technology to come up with a new specification, called service component architecture (SCA). This emerging standard tries to leverage service-oriented architecture (SOA) principles with component-based software development techniques. In this article we discuss some commonalities and fundamental differences of the CBS and SOA worlds. We illustrate SCA briefly using snippets of an ongoing case study based on an e-university federation. Then we elaborate on the qualities and current deficits of SCA in the light of CBSE findings and related works.

Building portable middleware services for heterogeneous cyber-physical systems

“…Services, in SOA terminology, are self-describing software components in an open distributed system. The description of a service, called a contract or an interface, lists its inputs and outputs, explains the provided functionality, and describes non-functional aspects of execution [7]. Different applications can be built from the same set of services depending on how they are linked and on the execution context [8].…”

Mixing Workflows and Components to Support Evolving Services

“…Those entry points define the interfaces provided by the component. In (Krämer, 2008), the author sketches the advantages of combining Component based Software Engineering (CBSE) and Service Oriented Architecture, illustrating the SCA approach. The presented and exemplified architecture shows that an SCA component implemented in BPEL can orchestrate other SCA components (through their provided interfaces).…”

Towards Unified Service Hosting

“…It wraps each service into a uniform component and defines dependencies between those (Krämer, 2008). However, there are several shortcomings with SCA regarding unified hosting.…”