Professional Documents
Culture Documents
Cloud Computing Based On Peer To Peer - Modules
Cloud Computing Based On Peer To Peer - Modules
1. Workflow
In this module, we are going to create the workflow for the software company need,Here we
noted that “Workflows introduce automation that enforces data validation and verification within
business operations, overcomes constraints in time and space, maintains consistency in the
business system, and significantly eliminates possible human errors.”
1. Every project has some number of tasks and employees. All tasks under a project can
only be handled by these employees.
2. A task is assigned to only one employee at a time. Task can be forwarded to other
employee of that project.
3. An employee can comment on his task, attach file with task, forward the task to other
employee of its project and also can download attachment of his task.
4. There are two types of employee, named Admin and User. Both of the type must be an
employee.
5. A user can only comment on his task, attach file with task, forward the task to other
employee of its project and also can download attachment of his task.
6. An Admin user has some extra privilege including all privilege of a user.
Admin can create project, edit project information, add / remove employee
to a project and can close a project.
Admin can create task, edit task information and close task.
Admin can create employee, edit employee information.
**A project can only be closed if its entire tasks are close.
7. All types of user must log in by user ID and password. According to their type there
will be different privilege, as discus earlier.
2. Web Services
In module, we will implement the major concerns that cloud Service Providers and
Service Consumers have to face when deploying Web Services in business environments.
Service Providers is to easily define new services, publish them, and manage them.
Service Consumers should authenticate with the Service Provider before they are
allowed to access and execute the service. The service provider should be able to further
control the access of the services based upon the credentials of a service consumer.
This requirement has implications in the Service Registry, the Service Discovery Process,
security, and the privacy of business data.
This requirement has implication in the Transaction area, and the Message and Protocol
semantics.
This requirement has implications in the web service description, as the context under
which the service is being executed will become part of the service inputs available to the
execution engine.
Service Providers needs to be able to offer a logging and auditing data for service
tracking, management and billing purposes.
Service consumers are the actual application developers who are building these new-age
applications using web services. Service Consumers usually have the most stringent
requirements from the web services environment because they need to support and manage
business applications. Some of the most common requirements posed by Service Consumers are
listed below:
Web Services need to be able to isolate the technical details of the service binding and the
communication with the Service Provider in order to minimize any impact of business
relationship changes on web services based applications (this is the problem, web
services are designed to solve to begin with)
The Service definition should then allow expressing such fail over plans similar to
managing business relationships.
2.2.4 Caching
2.2.5 Authentication
This is really important. Although many security mechanisms existing today may
be sufficient to provide some form of authentication. The distributed nature of web
services usually demands something similar to a single sign-on solution for security and
authentication.
It may not be obvious to many readers why web services should be concerned
with the channel they are being accessed from. In real life applications, when multiple
channel access the same service, they require vastly different behavior. It may be
necessary to consider some of the requirements while defining web services, so that the
needs of these applications may be satisfied easily.
This is a clear requirement from all the application developers who wish to use
web services in their application environments.
The process slip must be generated prior to the initiation of each instance of the workflow. This
must be done either by the initiator of the workflow or by a service invoked by the initiator. Our
process slip structure contains four subcontainers: Data, Audit Data, Security Policies and
Workflow Description.
3.1. Data
According to the needed security level some (or all) data can be encrypted and signed for
the corresponding recipient to ensure confidentiality and integrity of the data.
In the audit trail data sub container each involved manager should write according to the
workflow or security definition log data for the recently performed tasks.
To ensure that each service will have access only to the policy rules needed to execute the
assigned tasks and in the information, needed for the next partners, the initiator could
encrypt the rules for the corresponding authorized service. By encrypting the rules each
partner service is limited in his knowledge to the absolute minimum of knowledge
regarding the workflow he is working in.
Thus authentication and integrity may be added by XML Signature, XML Security, or
WS-Security. In case of a reference it should be noted that the integrity means are created
nonetheless. If the reference is changed or not available the workflow has to perform a
roll back.
4. Workflow Execution
To prevent an unauthorized access to the service's policies the initiator may encrypt each
policy with the public key of the corresponding service.