Page 208 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY

Information Security and Privacy

Notes needs early architectural decisions assisted by well-understood design methods, structural
patterns, and styles. These patterns address general service concerns like scalability, reliability,
and security.
Business stakeholders are based on the IT organization to offer solutions to their business needs.
For both financial and market-driven purposes, stakeholders want to shorten the investment in
time and money it takes to give IT solutions. They also wish to grow the value they derive from
IT solutions by maximizing the needs coverage each software project offers. As so many of those
projects today include Web services, it is very imperative that we have better tools and methods
for the rapid and successful execution of those business requirements by means of SOA. We
consider modeling to be especially imperative due to its capability to separate concerns and
present a unified view of those issues. Security in service executions is a major concern since
many applications function across organizational boundaries. The reason of this is to offer a set
of primitive modeling elements that permit the business stakeholders to mention the intent of
security inside the requirements procedure.

Did u know? System architects who take benefit of SOA can include one or more services
into their applications as constituents.

14.3.1 Architectural versus Implementation Models

As IT professionals goes to deliver applications by means of Web services, they frequently find
themselves in the place of coming up to speed on an architectural model (SOA) and an execution
model (Web services) at the same time. As one might expect under the situations, the distinctions
among the model and the execution sometimes get lost. This assumes the utilization of a Model
Driven Architecture method that carefully averts commingling the platform-independent model
of an application’s architecture and behavior with the methods and platforms used to execute
that modeled behavior. System architects employ either domain-particular languages or profiles
for Unified Modeling Language (UML) to model the issues of the service domain. The principles
that need architects to keep platform and language issues out of this model also need them to
keep implementation-particular security issues out.

Example: A model that involves abstract ideas of services and messages should not also
involve details of how messages can access public-key encryption and certificates to execute
service authentication and message signatures, since doing so violates a very basic principle
(the need to separate concerns) by producing the details of a specific technical execution into the
platform-independent model.
Alternatively it is not possible to treat security as an afterthought. Security executions are
complex; they can have serious influences on performance, and they can position additional
needs on the IT infrastructure assisting the services. It is thus in everyone’s best interests to
model security issues as carefully as any other issues.

By dividing issues, the IT organization can proficiently engage the business stakeholders in
understanding and illustrating the business requirement to maximize needs coverage. We intend
to display how to mention security intents in these high-level models while isolating behavioral
concerns from execution and platform-specific ones, consistent with the rules of MDA.

14.3.2 Revisiting Security Concerns

The team that produced the RosettaNet family of B2B standards formed concerns that were
similar to the ones we just conversed, and made a beginning toward addressing them. The

202 LOVELY PROFESSIONAL UNIVERSITY