Software Architecture for Evolving Environment
-
Upload
phailin-suttikul -
Category
Documents
-
view
29 -
download
2
description
Transcript of Software Architecture for Evolving Environment
Software Architecture for Evolving Environment
Jaroslav Král, Michal ŽemličkaCharles University, Prague{jaroslav.kral,michal.zemlicka}@mff.cuni.cz
25th September 2005 STEP 2005, Budapest 2
Changing Requirements on IS
Companies/organizations evolve during time – they join, split, change structure, restructure their business processes, etc.
Laws change Techniques change Partners change Standards change too …
The IS must adapt to all these changes!
25th September 2005 STEP 2005, Budapest 3
Problems
Current development techniques (object orientation, object-relational and relational databases) do not support enough radical run-time changes (reconfigurations) of the system.
Radical change of an application or a system (even single application upgrade) is a risky and costly operation. These problems should be reduced.
25th September 2005 STEP 2005, Budapest 4
Idea
The IS should have a flexible structure Individual subsystems supporting
basic operations of the supported institution should not change (unless it is necessary for its basic functionality). They should retain their local interface and functions used by local users.
Interfaces of the subsystems should be user-oriented
25th September 2005 STEP 2005, Budapest 5
Software Confederation
Virtual peer-to-peer network of autonomous applications (services) where every peer know (is aware of) its communication partners.
Typical examples: e-government IS of a large or distributed enterprise
Examples of systems being not confederations: e-commerce Monolithic applications
25th September 2005 STEP 2005, Budapest 6
Application Components
They provide the real functionality of the confederation
Often legacy or third party systems Typically preserve their original
interface and users and provide additional functions for the users of the whole confederation
Must be equipped with a special interface (primary gate) to be integrated into the confederation.
25th September 2005 STEP 2005, Budapest 7
Front-End Gates
Serve as providers of user-oriented interface of application components
Transform user-oriented requests (messages) to application-oriented messages and respective transform the answer for the requests.
Single application component can be equipped with several front-end gates.
Similar to connectors in Enterprise Service Bus offered by several software vendors
25th September 2005 STEP 2005, Budapest 8
An Application service, its primary gate and front-end gates
Application
service
Primary gate
Front-end
gate
Front-end
gate
Logically it can be viewed as a single application service
application-oriented interface
user-oriented interface
25th September 2005 STEP 2005, Budapest 9
Data Stores
Services/components having properties of data store from structured design (or DFD)
Allow to use more complicated communication between services than simple message queues – human control of the communication inclusive.
Can solve some problems with timeliness, accuracy, or availability of some data.
Have been successfully used in some applications
Indicate that service orientation is a paradigm different from object orientation
25th September 2005 STEP 2005, Budapest 10
Process managers
Control the flow of business processes (or, more precisely, allow to control BP to its owner).
There may be different (business) process managers following different business process methodologies (workflows, Petri nets, business rules, or simply fulltext instructions)
25th September 2005 STEP 2005, Budapest 11
Portals
Provide user interfaces to the whole system
There can be different portals for different groups of people.
They correspond to portals known from web
Similar to front-end gates Should be designed as one of the
peer (as a service)
25th September 2005 STEP 2005, Budapest 12
Implementation Strategy
Register and analyze communication of people requesting individual services within supported organization
Design interfaces of individual services Create screen prototypes of the
services providing the interfaces Create primary gates connecting the
user-oriented interfaces to the underlying applications
25th September 2005 STEP 2005, Budapest 13
Identify services
25th September 2005 STEP 2005, Budapest 14
Register and analyze existing communication
25th September 2005 STEP 2005, Budapest 15
Design interfaces of the services
25th September 2005 STEP 2005, Budapest 16
Create screen prototypes and redirect the communication to them
25th September 2005 STEP 2005, Budapest 17
Create front end-gate and connect it to the underlying application
FEG
App.
25th September 2005 STEP 2005, Budapest 18
System Evolution
If a part of an enterprise has to be sold, the supporting information system must be split. If the IS is a confederation, the splitting operation is simple.
When new parts are acquired, they are connected as new services and incorporated in portals and business processes
It opens new opportunities for support of SCM and CRM.
25th September 2005 STEP 2005, Budapest 19
System Evolution (2)
When business processes of the organization are to be changed, it is necessary to reconfigure only default business processes in the business process repositories. Most users using only one service need not to be aware of such a change
25th September 2005 STEP 2005, Budapest 20
Experience
Discussed architectural principles have been used in development of several control systems developed by Prof. Král. All such projects were successful and used for many years without significant maintenance. Also in the case of replacement of cooperating information system.
25th September 2005 STEP 2005, Budapest 21
Experience (2)
Discussed technique has been used in integration of agendas of a municipal office by a single master-degree student.
Similar experience with control systems using the confederative experience has also Prof. Kopeček from ZČU Plzeň, Czech Republic
25th September 2005 STEP 2005, Budapest 22
Conclusion
Discussed architecture supports smooth evolution of the system with minimum influenced users
Even when building such system the conversion from existing systems is usually smooth as many legacy applications can serve as application services (and their users feel that they still have “their” system).