Chapter 7 • Software
Components 261
Another issue is, what if, in Figure 7-5, component A needs some return value from component B
? This could probably be achieved by connecting B’s output port to A’s another input port, but is this the most elegantefficient solution?
7.5.2 Levels of
Abstraction
A key question with components is the right “size”, the level of abstraction. Low level of specialization provides high generality and reusability, but also low functionality thus resulting in
productivity gain.
Cf. Lego blocks: Although it is possible to build anything using the simplest rectangular blocks, Lego nevertheless provides specialized pre-made pieces for certain purposes. The point is not
whether anything can be built with universal components; the point is whether it is cost effective to do so.
Recall Example 3.1 about the simplified domain model of the virtual biology lab Section 1.5.1. We compared the solution presented in Problem 2.10 that uses abstract objects modeled after the
physical objects against a simplified solution that uses only abstract geometric figures lines, circles, polygons, etc.. True, the simplified model is not adequate because classes Cell or
Nucleus have relatively strong semantic meaning, whereas class Circle can stand for both of these and many other things. However, one may wonder whether we need to represent every detail in
the problem domain by a different class. Consider human bodies composed of cells—there are only 220 or so specialized sorts of cell. For comparison, Java libraries have thousands different
classes. Of course, each cell has many complex elements, as illustrated in Figure 1-16. One may wonder whether it is possible to have a similar, biologically-inspired, hierarchical abstraction and
composition of functions. UML packages contain classes, but they are not functional abstraction. Work on software architectures is in early stages and may eventually offer the path for
component abstraction.
processEvent1 a1 : PortIn
A : Component receiveEvent1
a2 : PortOut
sendEvent2 processEvent2
b1 : PortIn B : Component
receiveEvent2
Figure 7-5. Typical event communication and processing in a single-threaded system.
Ivan Marsic • Rutgers University
262
7.6 Summary and Bibliographical Notes
Cite a book on Java Beans. Computational reflection was introduced in [Smith, 1982]. A review is available in [Maes, 1987].
The component design presented in Section 7.5 is derived from the current literature, mostly the references [Allan et al., 2002; Bramley et al., 2000; Chen Szymanski, 2001; Hou et al., 2005;
Szymanski Chen, 2002; Tyan et al., 2005]. Additional information is available from the Common Component Architecture CCA Forum at
http:www.cca-forum.org .
Problems
263
Contents
8.1 Service Oriented Architecture
8.1.1 8.1.2
8.1.3 8.1.4
8.1.5 8.1.6
8.1.7
8.2 SOAP Communication Protocol
8.2.1 The SOAP Message Format 8.2.2 The SOAP Section 5 Encoding
8.2.3 SOAP Communication Styles 8.2.4 Binding SOAP to a Transport Protocol
8.3 WSDL for Web Service Description
8.3.1 The WSDL 2.0 Building Blocks 8.3.2 Defining a Web Service’s Abstract
Interface 8.3.3 Binding a Web Service Implementation
8.3.4 Using WSDL to Generate SOAP Binding 8.3.5 Non-functional Descriptions and Beyond
WSDL
8.4 UDDI for Service Discovery and Integration
8.4.1 8.4.2
8.4.3 8.4.4
8.5 Developing Web Services with Axis
8.5.1 Server-side Development with Axis 8.5.2 Client-side Development with Axis
8.5.3 8.5.4
8.6 OMG Reusable Asset Specification
8.6.1 8.6.2
8.6.3
8.7 Summary and Bibliographical Notes Problems
Cha pt e r 8
We b Se rvic e s
A Web service is a software function or resource offered as a service; remotely accessed over the “web”; and, has
programmatic access using standard protocols. A Web service is an interface that describes a collection of operations that are
network accessible through standardized XML messaging. Web services fulfill a specific task or a set of tasks. A Web
service is described using a standard, formal XML notion, called its service description that provides all the details
necessary to interact with the service including message formats, transport protocols and location.
While there are several definitions available it can be broadly agreed that a Web service is a platform and implementation
independent software component that can be,
• Described using a service description language • Published to a registry of services
• Discovered through a standard mechanism • Invoked through a declared API, usually over a
network • Composed with other services
Web services are characterized as loose coupling of applications—clients and service providers need not be known
a priori. The underlying mechanism that enables this is: publish-find-bind, or sometimes called find-bind-execute. The
application can be developed without having to code or compile in what services you need. Similarly, when service
provider deploys a service, it does not need to know its clients. In summary, 1 Service publishes its description; 2 Client
finds
service based on description; and, 3 Client binds itself to the service.
