by Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmeidel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg
An exploration of the fundamentals of applying a factory approach to modern service-oriented software development.
Part of the Industrial SOA article series
In this article, we present and explore the fundamentals of applying the factory approach to modern service-oriented software development in an attempt to marry SOA industrialization with service contracts. As service developers and designers, how can we successfully fulfill factory requirements and achieve the essential characteristic of industrialized SOA while remaining compliant with standards on the service contract level?
Thinking in terms of contracts has been found to be requisite for granular sourcing strategies that virtualize underlying implementations. Contracts also function as a common language between business units and IT teams, across cloud computing technologies, and for future-proof and agile enterprises in general.
Let's imagine that today's "pre-industrialized" world has become one in which contracts are been replaced by organizational and technical silos and the best solutions available. In today's SOA landscape, functional components are created for specific applications, often redundantly and lacking organization-wide standardization at the interface level. These components work well in a "silo" landscape in which the "application SOA" architecture is particularly suitable within the context of single applications.
Figure 1 illustrates the simplicity of combining services within applications that results from standardized design and structures being used as the framework for interfaces and exchanged data:
If a business activity service (BAS) comprises business entity services (BESs) of different designs from multiple "application SOAs," the data that is exchanged will vary greatly in structure. A single "contract" business object can be structured very differently for each application service (Fig. 2).
Figure 3 illustrates how a high level of integration effort is required for each compiled service even though all of the services are based on underlying standards like SOAP and WSDL. Great integration effort is caused by the different structural characteristics of the data types.
A high level of integration effort is required for service usage due to an absence of industry standards, which forces service reuse efforts to remain difficult and highly cost-intensive. These drawbacks cause developers to prefer building functionality themselves rather than using services. Integration effort is therefore a major obstacle on the path to successful SOA adoption.
The solution lies in domain-wide standards that are placed at the level of functional data exchanges and technical cross-sectional data exchanges. LEGO® is chosen as a metaphor to demonstrate the necessity of standardization in service contracts, since the uniformity of LEGO® brick structure produces the perfect fit. A LEGO® brick that has just a minor imperfection or a small protrusion cannot be properly attached to other bricks. Similarly, simplified service reuse can be achieved by merely standardizing the exchanged data.
Figure 4 illustrates how combining services that are based on the same standards can be as basic as building structures out of LEGO® bricks. This is the holy grail of SOA. The artificial connector, the integration layer, becomes very small or ceases to exist.
One of the most important characteristics of the industrialization approach is a domain-wide standardization of interfaces or ""service-level agreements." This agreement is a contract into which a service enters with its users, and is the prerequisite for BASs that are incorporated as function components for processes and portals. Considerable integration effort isn't required, and SLA compliance can in evaluated through enterprise asset management (EAM) or business process management (BPM) dashboards.
It is conceivable for specifications to be centrally determined on an SOA dashboard as an option for establishing the standards throughout an enterprise or organization. SOA governance tasks check and verify their use and compliance with the applicable specifications. These governance tasks require substantial effort to remain compliant with the specifications of standardized interfaces, which must be fulfilled for each service. The model-driven generation of service contracts can be implemented to reduce this effort and allow service developers to focus their attention on service implementation instead.
SOA architects define business object data types for reference data types and cross-sectional data types to prepare for a range of errors. The underlying business objects and their attributes are saved as an object model, such as the unified modeling language (UML), in a central repository. Service designers use this centralized object repository when defining contracts and "feed" the repository into the generator, which creates the service interface in accordance with previously specified rules. This process demonstrates how a tool expert has defined the compilation of a standardized WSDL from selected data, cross-sectional data, and reference data.
SOAP messages are exchanged during runtime. The standardized filling in of SOAP headers, which also contain essential information for dashboard evaluations, is one of the tasks of the enterprise service bus (ESB). The ESB is configured for this task only once and doesn't typically require any further involvement from the developer who programs services.
The interface specification, WSDL, and SOAP messages are now created according to the standards of the central architecture. Generating service contracts beyond or outside of this standard structure is not possible. The shift away from developer specifications and governance tasks that monitor specifications compliance, towards a generator-driven contract manufacturing process, is a key aspect of the implementation of the factory approach to industrialized SOA.