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.1. Creation of work flow

A fundamental element in a workflow is a task. A task can basically be defined by three

parameters: input description, transformation (actor), and output description. The input
description provides the information required to complete the task. The transformation is
composed of the algorithms carried out in the task. The output is the information produced in this
task which can be provided as input to the downstream tasks.

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.

 Admin can set user type.

 Admin can view project, task , task history, employee reports(Crystal

Report) 

**While creating a project Admin will be a member of the project by default.

**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.

2.1. Cloud Service Providers

Service Providers is to easily define new services, publish them, and manage them.

2.1.1       Easy and flexible service modeling

Service Providers should be allowed to create services out of their existing

software infrastructure re-using existing applications. This requirement has implications
in the Web Service description and model. The model should provide an extensible
binding so that existing sources can be exposed as services with minimal or no additional
code.

2.1.2       Access Control

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.

2.1.3       Transactions and Session

 Service Provider may offer a set of web services that requires keeping a state (e.g
shopping cart). For example, consumers should be able to execute an ‘add to shopping
cart service’ multiple times and finally execute a ‘buy’ service which buys everything
that has been added.

This requirement has implication in the Transaction area, and the Message and Protocol
semantics.

2.1.4       Personalized Service Execution

Service Providers should be able to customize the execution of a service based on

parameters associated to the service consumer requesting it. This option can be used to
provide different quality of services to different users.

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.

2.1.5       Logging and Auditing

Service Providers needs to be able to offer a logging and auditing data for service
tracking, management and billing purposes. 

2.1.6       Added-Value Services

Service Providers (intermediaries) can publish added-value services built using

third-party services. In this use case, Service Providers are also acting as Service
Consumers and they are therefore sharing the same concerns.

2.2        Cloud Service Consumers Using SOAP

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:

2.2.1       Management of Business Relationships

 Service Consumers are bound to a Service Provider by a business agreement.
Change from one Service Provider to another or the terms and conditions of service usage
should not require any modifications in the consumer application.

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)

2.2.2       Reliable Services

In an effort of to maintain 24x& availability of their applications, developers can

decide to define some fail over plan when a service fails. This fail over plan may include
hardware failure, software failure as well as service failure. In the context of web
services, it is the service failure that needs the attention of the service execution
framework.

The Service definition should then allow expressing such fail over plans similar to
managing business relationships.

2.2.3       Aggregation of Services

Multiple services can be combined together to define a new value-added service.

This becomes desirable as the applications built using web services start to expose their
own features as web services.

2.2.4       Caching

Service execution environment needs to consider caching due to network

overheads and slow server responses.

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.

2.2.6       Session Management

 This is a requirement for most of the applications. If web services need to work
with existing applications, they need to support an abstract notion of session that can be
mapped onto several different implementations.

2.2.7       Service Invocation (Asynchronous and Synchronous)

Quality of service requirements on an application may force them to require

asynchronous execution of the services. Since most of the Internet applications have this
requirement, asynchronous execution environments need to be supported. Indirectly this
has an impact on how the services are defined and interpreted by the execution
environments.

2.2.8       Ability to Integrate with Multiple Delivery Channels

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.

2.2.9       Service Management

This is a clear requirement from all the application developers who wish to use
web services in their application environments.

2.2.10    Workflow and modeling of business processes into a Web Service

Any advanced application of web services, especially when it needs to execute

multiple web services and additional business logic, and wishes to expose them as an
advanced service, will require workflow and business processes to be available as a part
of the service execution environment. Such applications also require a mechanism with
which they can expose a process within a service concept.

3. Creation of Process Slip

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.

3.2. Audit 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.

3.3. Security Policy

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.

3.4. Workflow Description

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

In this module we will develop our custom workflow execution.

4.1. Generating the Security Policies

To prevent an unauthorized access to the service's policies the initiator may encrypt each
policy with the public key of the corresponding service.

4.2. Initialization of the Data and the Audit Data Sections

 Once the initialization phase is complete, the workflow execution proceeds with
the delegation of the execution to the service responsible for the first set of tasks. In order
to verify that a received certificate is not revoked the security stub relies on some
communication with external security services. These are Public Key Infrastructure
services which are used to verify certificate validity by querying the certificate authority
using the Online Certificate Status Protocol (OCSP). In order to provide this functionality
we introduce in our workflow model the Trusted Third Party (TTP) service, which
implements the functionality of the verifying CA.