04-08-2012, 01:20 PM
ser- vice-oriented architecture (SOA)
ser- vice-oriented architecture (SOA).doc (Size: 7.27 MB / Downloads: 231)
INTRODUCTION
PURPOSE OF THE PROJECT
Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective.
The implementation stage involves careful planning, investigation of the existing system and it’s constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods.
SCOPE OF THE PROJECT
Main Modules:-
SOA Business Process Module:
A ser- vice-oriented architecture (SOA), an organization may en- capsulate and publish its applications as services, and select and interact at runtime with the services provided by other organizations. However, for both user and vendor organiza- tions, this raises immediate problems of security, trust and dependability [3]. Until these problems are addressed and solved satisfactorily, the potential of automatic inter- organizational business processes will be severely restricted. In a dynamic and distributed environment, it is often difificult for a complex business process to follow a static business specification.
Federated Authentication Module:
Federated authentication is a solution of accept- ing user authentication between different organisations. A growing number of methods are emerging in the early stage of development, such as SAML, OpenID , Liberty , and Windows Cardspace. However, the over- head of generating federated authentication between many heterogeneous organisations is very high, including high infrastructure requirement, cost of contact amendments and cost of building understanding by the partners, which leads to the slow adoption of existing federated authentication mechanisms. Moreover, in the federated authentication, a server often needs to authenticate a chain of credentials sub- mitted by a client, and this requires the server to perform multiple expensive digital signature verifications. Main- training a direct cross-realm authentication relationship be tween any pair of security realms could be difficult and costly.
Authentication-path of Credential Conversion Module:
Another solution to this problem would be to locate some intermediate realms that serve as an authentication-path of credential conversion between the two separate realms that are to collaborate. However, the overhead of generating an authentication-path for two distributed realms is not trivial, which requires the cooperation from intermediate security realms. The process may involve a large number of extra operations for credential conversion as well as a long chain of invocations to intermediate services.
MULTI-PARTY BUSINESS SESSIONS MODULE
Two-Party Session
The two-party session technique is both simple and practically effective, and it is used widely in many distributed systems and integrated with the design of most authentication protocols (e.g. SSL and Kerberos [17]). However, new problems arise when the two-party session technique is ap- plied directly to the construction of a multi-party session that has three or more session partners. Hada and Maruyama in [1] demonstrate that, if a multi-party session is constructed out of multiple two-party sessions, it is difficult in some cases for a session partner to verify whether the service in- stance it contacts is actually a member of the same session. This is because the two-party session technique does not have a mechanism for distinguishing a principal from a group of other principals.