4.3 Implementation Issues

Integration of legacy systems

Technically, a legacy system (LS) is integrated into the system via adding a gate (G) to LS.

		LS then becomes an autonomous service AC. G connects AC to a middleware. AC is also reconstructed to
		be a permanent process if needed.

		The choice of P2P architecture should be included into requirements specification though it is a technical
		issue as it substantially influences user properties of the system and structure of the specification.

Confederative architecture can support new requirement types raised by CEO, like

			The transformation of the enterprise organization structure into a decentralized form, selective
			outsourcing of some parts of the information system,

Selling out some divisions/departments, integration of newly purchased firms/divisions,

Support for supply chain management, and

Forming various business coordination groups.

4.3 Implementation Issues

Figure 4.2: Three-tier service (encapsulated information system) with gate G and its communication links

4.3 Implementation Issues

Front-End Gates (FEG):

		The properties of the interfaces of autonomous services/components (AC), is the basis of the requirements
		specifications of software confederations.

		The interface of AC is known only to its partners, therefore it is used as a black box also interfaces should
		hide the implementation details and philosophy of autonomous services.

FEG:

			It is an autonomous service (peer) with the properties similar to user components.

Stabilize and generalize the interfaces of components and make them partner-friendly.

Can direct messages to the components that are less loaded at a given moment.

Some services can be replicated. It enables load balancing and distribution of services.

		As FEG is used as a white box, the properties of its input language L and its output language L1 must be
		included in the requirements specifications.

		FEG can be viewed as an enhancement of the middleware services as the developers develop, in this case,
		rather the middleware than the applications.

4.3 Implementation Issues

Figure 4.3: System with front-end gates

4.3 Implementation Issues

Petri Nets:

		FEG (front-end gates) are based on methods and special tools having common features with formal
		language translation and compiler construction.

		It is a solution to the interoperability problem as it can compose several messages into one message and
		decompose one message into several messages. Hence can also play the role of message routers.

FEG can therefore be viewed as a generalization of places in Petri nets with colored tokens.

Tokens are messages, whereas application services behave like processes in temporal colored Petri nets.

		To enable a proper modeling and simulation of confederations, Petri nets needs to be generalized and it
		depends on various factors.

		Petri nets describe, in some sense, atoms of communications in networks of static structure. Workflows must
		therefore be defined using some other tools.

		Petri nets indicates links between software confederations and manufacturing systems (and, generally, soft
		real-time systems) and hence are used in manufacturing control systems.