SOA-REPORT (2)
-
Upload
rounak-vyas -
Category
Documents
-
view
217 -
download
0
Transcript of SOA-REPORT (2)
-
8/7/2019 SOA-REPORT (2)
1/45
1
CHAPTER 1
INTRODUCTION
1.1 OVERVIEW
Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed
capabilities that may be under the control of different ownership domains and implemented using
various technology stacks. In general, entities (people and organizations) create capabilities to
solve or support a solution for the problems they face in the course of their business. It is natural
to think of one persons needs being met by capabilities offered by someone else; or, in the world
of distributed computing, one computer agents requirements being met by a computer agent
belonging to a different owner. The term owner here may be used to denote different divisions of
one business or perhaps unrelated entities in different countries.
There is not necessarily a one-to-one correlation between needs and capabilities; the granularity
of needs and capabilities vary from fundamental to complex, and any given need may require a
combination of numerous capabilities while any single capability may address more than one
need. One perceived value of SOA is that it provides a powerful framework for matching needs
and capabilities and for combining capabilities to address those needs by leveraging other
capabilities. One capability may be repurposed across a multitude of needs.
SOA is a view of architecture that focuses in on services as the action boundaries between the
needs and capabilities in a manner conducive to service discovery and repurposing.
The ultimate goal of a SOA is to have an agile IT environment unaffected by all the disparate
technologies that might be used to develop its services. SOA geniuses have long realized that the
nature of most organizations is composed of heterogeneous computing environments because
different business units perceive their needs differently from one another. Standardization of all
programming objects into one proprietary technology defeats the ultimate aim of enterprise
agility. Standardization should remove the locked chains of technology dependency. The put all
-
8/7/2019 SOA-REPORT (2)
2/45
2
your eggs in the same basket scenario must avoided or else reap the high risks and costs of
being locked and controlled by external forces.
To achieve this, SOA must be based on nothing else but Open Standards. Enterprises, just like
any member of our society, must take steps to protect themselves against the threats of
dependency. Open Standards level the playing fields and therefore vendors have no choice but to
work in the best interest of its customers. Customers can pick and choose freely based on the
quality of service and relations with vendors.
1.2 SERVICE-ORIENTATION
Service-Orientation is not really a new concept. Many IT pioneers and architects like John
Zachman have made exhaustive references to principles such as reusability and standardization
of IT components or parts. Many readers familiar with J2EE, .Net or Object-Oriented
Programming (OOP) in general will find the principles of Service-Orientation very familiar
(although services and objects are quite different in scope).
In Service-Orientation, a service is a business function area that can easily be converted into a
computerized Service (i.e. mostly a service built from information technology). The service
forms the building blocks (i.e. architecture) to be reused across the whole Enterprise in building
business applications. In modern or contemporary IT Shops, services are likely to take the form
of Web Services. Yet, some organizations have been using Service- Orientation theory quite
successfully since the 70s proving that Service- Orientation promotes application agility
regardless of the technology platforms.
If we program our applications using the newest technologies such as Web Services but are still
doing it through traditional methods then it is nothing more that replacing or rewriting the
application all over again (i.e. the endless cycles of re-writing applications). The enterprise thatis constantly rewriting their monstrous apps produces competitive disadvantages because of the
high costs and time to re-write, test and implement. In fact, they would most likely be better off
-
8/7/2019 SOA-REPORT (2)
3/45
3
to keep heritage applications built with Power Builder or COBOL. Services as defined in this
section replaces the traditional word application with the word services instead.
1.2.1 What does being service-oriented implies
The fundamental technical characteristics of SOA are a service and remote service invocation. A
service is a unit of executable code that can be invoked by another service remotely and
inexpensively anywhere in the network. Compared with conventional computing models that
require significant human, programming, and computing resources for applications to
communicate and interoperate, the service-oriented computational model is based on
communication (messaging) and interoperability between services to discover and invoke remote
services, based on requirements, and to orchestrate services into composite services or service
workflows.
Figure 1.1 Service Oriented Scenario
Presumably an SOA is the architecture that supports services-orientated computing, yet there is
no architecture inherent in services and service invocation. Indeed, SOA is not an architecture
characterization; it is a style of programming. As there is no standard definition of an SOA we
-
8/7/2019 SOA-REPORT (2)
4/45
4
adopt a vendor neutral description of SOA functionality [Heffner, 2005] which is characterized
by three values that an SOA supports Change, Connection, and Control. Each value is provided
by a set of functions. Flexible business Change, the key SOA benefit, is enabled by a Service
Life Cycle Environment that supports the service life cycle in which services are developed,
modified, and maintained. Connection between services, the technical essence of SOA, is
realized in the Service Delivery Network through which all service interactions take place.
Control, which is required to manage services, is enabled by the Service Control Platform that
provides tools to monitor, govern, and manage service execution.
Initially during the migration to SOA, an SOA will mix services with conventional or legacy
applications. At least initially, SOAs must deal with existing computing resources that are not yet
or may never be service-oriented. Services are often depicted as service interfaces that are APIs
(Application Programming Interfaces) to functions within conventional applications, called core
application platforms that will exist early in the transition to SOA.
1.3 WHAT IS SOA
Service-oriented architecture (SOA) is a flexible set of design principles used during the
phases of systems development and integration in computing. A system based on a SOA willpackage functionality as a suite of interoperable services that can be used within multiple
separate systems from several business domains.
SOA also generally provides a way for consumers of services, such as web-based applications, to
be aware of available SOA-based services. For example, several disparate departments within a
company may develop and deploy SOA services in different implementation languages; their
respective clients will benefit from a well understood, well defined interface to access them.
XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a Web-based environment and
uses multiple implementation platforms. Rather than defining an API, SOA defines the interface
-
8/7/2019 SOA-REPORT (2)
5/45
5
in terms of protocols and functionality. An endpoint is the entry point for such a SOA
implementation.
Service-orientation requires loose coupling of services with operating systems, and other
technologies that underlies applications. SOA separates functions into distinct units, or services,
which developers make accessible over a network in order to allow users to combine and reuse
them in the production of applications. These services and their corresponding consumers
communicate with each other by passing data in a well-defined, shared format, or by
coordinating an activity between two or more services.
One can consider SOA a continuum, as opposed to distributed computing or modular
programming
Figure 1.2 SOA COMPONENTS
-
8/7/2019 SOA-REPORT (2)
6/45
6
1.4 ACTORS IN SERVICE ORIENTATION
Following are the actors involved in service orientation,
1.4.1 Service Provider: The service provider is responsible for supplying service objects that
implement service functionality.
1.4.2 Service Requester: The service requester is a client for a particular service.
1.4.3 Service Registry: Service Registry is a repository of services which can be dynamically
published and discovered.
1.4.4 Service Object or Service Its a reusable IT asset implementing some functionality
satisfying business need.
-
8/7/2019 SOA-REPORT (2)
7/45
7
1.5 SOA LIFECYCLE
The core IT assets of any organization include the following,
y data,y legacy applications,y line-of-business applications andy packaged applicationsSOA implementation is an iterative approach to building integrated loosely coupled systems.
Microsoft has been the leading player in SOA implementation. Following is the SOA life cycleas defined by Microsoft Corporation
Figure 1.4 SOA Lifecycle
-
8/7/2019 SOA-REPORT (2)
8/45
8
1.6 REQUIREMENTS FOR SOA
In order to efficiently use a SOA, the architecture must meet the following requirements:
y Interoperability among different systems and programming languages that provides the basisfor integration between applications on different platforms through a communication
protocol. One example of such communication depends on the concept of messages. Using
messages across defined message channels decreases the complexity of the end application,
thereby allowing the developer of the application to focus on true application functionality
instead of the intricate needs of a communication protocol.
yDesire to create a federation of resources. Establish and maintain data flow to a Federateddatabase system. This allows new functionality developed to reference a common business
format for each data element.
-
8/7/2019 SOA-REPORT (2)
9/45
9
CHAPTER 2
LITERARY SURVEY
2.1 BACKGROUND
Current Information Technology infrastructures have reached a crossroad as more and more
Enterprises seek ways to restructure, reorganize and re-align their IT shops. Many believe that in
5 to 10 years from now, Information Technology (IT) will be transformed as the old methods of
building huge monolithic systems are likely to give way to more efficient and agile methods.Thanks to recent advancements in the Internet and Web Services technologies a new approach to
building IT systems called the Service-Oriented Architecture (or simply SOA) is quickly
gaining momentum and acceptance. This new approach, modeled from modern schools of
engineering and architecture, is setting the stage for assembling applications at runtime through
the use of reusable plug and play services. This new way of thinking could not have come at a
better time as todays organizations are seeking ways to control development and maintenance
costs and to consolidate IT infrastructure. To do so, most organizations realize that they will
have to re-invent their information systems into services (rather than applications) to improve the
flexibility and agility needed to support all business processes.
A well-planned strategy based on Service-Oriented Architecture (SOA) will put the Department
of Postsecondary Education, Training and Labor in the drivers seat in terms of procuring cost-
effective agile IT services. The SOA approach results in a vendor and technology agnostic
environment where services can be acquired from either an internal IT Shop or from outside
vendors of SOA-enabled services. SOA goes beyond the current methods of concentrating solely
on the microscopic reusability of objects and programming code by encouraging the reusability
and scalability of business-focused services instead. This approach results in an organization
whose processes behave more like a dynamic living organism. In other words, our applications
-
8/7/2019 SOA-REPORT (2)
10/45
10
can dynamically re-align themselves to the changing needs of the enterprise on-the-fly (during
runtime). The approach helps us in designing plug-compatible services rather than building
gigantic complex and inflexible applications.
2.2 SOA HISTORY
Enterprise IT System is decomposed into business services. Decomposition theory was first
introduced in the late 1950s. System theory states, The more complex a system is, the more
unknowns it contains and thus, the harder it is to automate it. This theory supports divide and
conquer modular based approach to software development.
In 1960, decomposition approach was first applied on mainframe applications by splitting them
into separate jobs, each implemented by a separate program.
In 1970, there came a boom of object-oriented (OO) paradigm which further strengthened
decomposition adoption by introducing objects, or modules of code, each of which implemented
a model of a real thing. The idea was to map real world entities to software objects. But object
abstractions too often prove to be too fine-grained making it very difficult to map technical
concepts over business level.
Also, many object-oriented developers used to spend most of their time dealing with technical
constructs such as collections, graphical widgets, and so on. In most cases, the real domain
problem disappears inside objects and modules which no longer are understandable by domain
experts. Ultimately, the object model and the class hierarchy are not really understandable by the
domain experts.
In the late 1990s, component based approach was introduced. It helped up to a certain level to fix
the problems of OO by raising a level of abstraction, increasing granularity, and creating a
tighter linkage with the business level concepts.
Although with the introduction of software components, software applications became more
flexible, better structured, and more manageable. But, it never really solved the fundamental
-
8/7/2019 SOA-REPORT (2)
11/45
11
problem related to software applications of being application-centric. Both objects and
components provide better design and development approaches for individual applications.
With the start of new millennium, SOA brings decomposition to a higher level, SOA approach
too uses the principle of decomposition where business process is decomposed into tasks and
those tasks are then mapped to services. Further services can be composed to form a larger
service called composite service. The architecture of SOA is such that it makes possible to align
business and technology together. It does this by providing meaning to business services and
business processes. And the best part is that it makes it possible to trace services and processes
back to enterprise business architecture.
Thats how starting from multiple jobs era, object orientation, components, we now have service
orientation in place to promote business flexibility and agility that in turn results in flexible IT
infrastructure thereby making it possible a long awaited dream; the dream of having a fastest
time to market. This fastest time to market also yields in least ROI since reusing IT assets in
terms of services requires less time and less effort rather than developing from the scratch.
-
8/7/2019 SOA-REPORT (2)
12/45
12
Figure 2.1 History of SOA
2.3 EVOLUTION OF DISTRIBUTED SYSTEMS TECHNOLOGIES
Shifting our attention now to the technology side of SOA, we should also spend some time
talking about the evolution of distributed systems technologies and its impact on SOA.
Distributed systems play an essential role within SOA. Most businesses are composed of many
departments or LOBs that represent islands of thought and activity that need to collaborate to
achieve the goals of the business. Likewise, the services identified within a business design will
often show up in the information system as a set of independent application functions that need
to be integrated to implement the service, or that will be composed to form higher level services
or business processes. Given the prominence of distributed computing within an SOA, it is worth
understanding what works and does not work in distributed system technologies.
First, tightly-coupled distributed systems generally do not work. Since the boundaries of a
distributed system often represent corresponding boundaries between the organizations
-
8/7/2019 SOA-REPORT (2)
13/45
13
responsible for the parts of the distributed system, you cannot expect that they will all operate
with the same technology, or version of technology (technology constraint). Chances are
technology to use for the construction and deployment of their part; these decisions made over
time accrete different hardware and software technologies.
You cannot reliably expect that calling a function over a distributed network will respond to you
in a timely manner (temporal constraint). If nothing else, a remote procedure call may be
measured in terms of milliseconds to get there and back with a response, whereas a local call to
that same function may be measured in microseconds to respond three orders of magnitude or
more in difference between a distributed call and a local call. Beyond that, there is a higher
chance of running into a system failure over the distributed system than in a local address space.
There is potential for network failure; the target machine may be down; or the function you are
calling may be so heavily overloaded handling requests from other clients that it could be
severely delayed in responding to your request.
Finally, different organizations will often have independent development cycles evolving the
parts of the distributed system at different rates (organizational constraint). It is easy for one
organization to introduce bugfixes to their part that will affect behavior that your part depends
on.
Likewise, they may introduce even more severe changes to address new requirements that will
break your interface to their part. In general, you should avoid designing distributed systems that
require everyone to use the same technology, that requires each part to respond in a fixed time or
with extremely low latency, or that requires an rigidly constant set of behaviors or interfaces.
Having said that, we also recognize that some of these constraints are hard to avoid sometimes
you just have to depend on certain capability that only one technology offers, or you may be
mandated by judicial or regulatory requirements to do things a certain way, etc. There are
degrees of forgiveness in these principles, but the more that you are able to adhere to them, themore successful you will be in exploiting distributed computing.
-
8/7/2019 SOA-REPORT (2)
14/45
14
History in the Information Technology industry is littered with examples of where distributed
computing systems violated (or, more accurately, preceded the discovery of!) these principles.
SNA, DCE, DCOM and CORBA are all examples of distributed computing systems that
required that everyone use the same technology (or, at least, in the case of CORBA, a technology
that implemented precisely the same specified syntax and semantics) to participate in the
distributed integration of parts. Even distributed messaging systems, which embrace some
aspects of loose coupling such as avoiding temporal and to some extent organizational
constraints have tended to also impose technology constraints, requiring all of the distributed
participants operate with the same underlying messaging middleware technology.
We have, hopefully, learned from these mistakes. SOA very intentionally is an evolution of
distributed computing building upon the principles of loose coupling and encapsulation. We take
deliberate steps to avoid dependence on technological, temporal and organizational constraints.
We then allow you to thoughtfully compromise on those principles to the degree that you need to
overcome specific limitations in your environment, but then always with an eye towards
encapsulating those compromises so that they dont create an adverse affect on your use of SOA
elsewhere within your business design.
The notion of loose coupling fits well with the premise of deriving your information system
design from your business design. A significant number of business processes are performed,
today, by human beings. People are inherently loosely coupled in their interactions with other
humans and machines. We are able to communicate with each other over a variety of different
technologies. We are, relative to a computer, very slow that is, we generally dont respond to
each other in a predictably reliable fashion or with low latency. And were pretty good at
adapting to changes in behavior, semantics, and even syntax. Thus, at the highest levels,
activities that automate human processes, with their inherent loose coupling as a comparison,
make for a pretty good approximation for where we can apply boundaries in the distributed
information system.
-
8/7/2019 SOA-REPORT (2)
15/45
15
2.4 EVOLUTION OF SOA
SOA can be viewed as an evolutionary computing architecture that closely mirrors the history of
the industrial revolution. With SOA, computing architectures are expanding beyond object
oriented self-sufficiency and now allowing for highly specialized and interoperable computing
consumer/producer relationships. This summary provides some history and relationships
between SOA and previous enterprise tiered architectures, object oriented paradigms, and
structured procedural programming.
Pre 1980, structured procedural programming was prevalent for assembling well structured
software code (that was the hope) into a software system. Procedural style APIs focus on the
natural ability to solve problems via a functional process. The focus is primarily on how to get
from point A to point B. This functional way of solving a problem is often a necessary first step
when exploring an unfamiliar problem domain. Between 1980 and 1990, OO evolved and
established its dominance in the software industry. OO focuses on combining elements of the
problem domain in the form of objects containing data and methods which help solve the
problem of how to get from point A to point B in a way that will also be good to get to point C
(reusability).
However, OO evolved prior to the common distributed computing environments that we have
today. Between 1990 and 2000, enterprise tiered architectures evolved and demonstrated that
combining methods with data between tiers worked against scalability and loose coupling of the
enterprise system, thus the use of data transfer objects between tiers and the focus on the data
model for communication between tiers of the enterprise system. Up to the year 2000, individual
computing systems remained relatively self-sufficient.
The pre-SOA tiered enterprise architectures and implementations did not provide a good solution
for computing specialization and computing interdependence at a business or government level.
SOA exploded from the evolution of the tiered enterprise architectures and pressures to provide
specialized B2B and G2B interoperability. Under the realm of a SOA ecosystem fall the
concepts of acting in a SOA ecosystem, social structures, service description, service visibility,
-
8/7/2019 SOA-REPORT (2)
16/45
16
service interactions, policies and contracts, governance, etc. and this mix of concepts combine to
provide the architectures for the implementations of the automated computing needs for modern
computing consumer/producer relationships. SOA is a computing architecture that allows for
complex relationships and specializations of computing services on a global scale.
2.4 PROGRAMMING TOOLS TO BUILD SOA SOLUTIONS
Figure 2.2 Programming Tools to Build SOA Solutions
The brief analysis of the programming tools that are being used to build SOA solutions is
elicited. This research is with respect the size of organization or industry corresponding to the
particular tool. According to this research, we clearly see that the vendors that supply the tools to
implement Web Services are in a better position to lead the Web Services technology market.
Microsoft Visual Studio.NET seems to be holding a larger market share with fifty percent of the
companies showing a tendency towards it.
-
8/7/2019 SOA-REPORT (2)
17/45
17
2.5 PLATFORMS TO EXECUTE SOA SOLUTIONS
The brief analysis of the SOA platforms that are being used to execute SOA solutions is elicited.
This research is with respect the size of organization or industry corresponding to the particular
SOA platform. According to this research, Microsoft .NET has proven to be the most widely
used platform to execute SOA solutions. Reason being the may be the ease of use that Microsoft
.NET is providing developers and making it easy to deploy SOA solutions.
Figure 2.3 Platforms to execute SOA Solutions
-
8/7/2019 SOA-REPORT (2)
18/45
18
CHAPTER 3
EXISTING WORK IN THIS FIELD
3.1 SOA TERMINOLOGIES
3.1.1 Service
A service is a coherent unit of business functionality accessible through programmatic interfaces.
This definition has been based on one of the definitions of Gartner Research [Gartner, 2007]. It
importantly stresses that:
y Any service concerns business functionality.y Services are accessed via programmatic interfaces, i.e. that the business functionality is made
available by software.
A service is an abstract resource that represents a capability of performing tasks that represents a
coherent functionality from the point of view of provider entities and requester entities. To be
used, a service must be realized by a concrete provider agent.
3.1.2 Operation
An operation is an individual function of a service associated with a single consumer-service
interaction. A set of messages related to a single Web service action is Operation. An operation
is an interaction with the service consisting of a set of (ordinary and fault) messages exchanged
between the service and the other parties involved in the interaction.
3.1.3 Interface
Interface is a machine-readable description of the services abstract functionality, provided in a
platform-independent form. An interface defines the communication boundary between two
-
8/7/2019 SOA-REPORT (2)
19/45
19
entities, such as a piece of software, a hardware device, or a user. It generally refers to an
abstraction that an entity provides of itself to the outside. This separates the methods of external
communication from internal operation, and allows it to be internally modified without affecting
the way outside entities interact with it, as well as provide multiple abstractions of itself. It may
also provide a means of translation between entities which do not speak the same language, such
as between a human and a computer.
A WSDL 2.0 interface defines the abstract interface of a Web service as a set of abstract
operations, each operation representing a simple interaction between the client and the service.
Each operation specifies the types of messages that the service can send or receive as part of that
operation. Each operation also specifies a message exchange pattern that indicates the sequence
in which the associated messages are to be transmitted between the parties.
Figure 3.1 SOA Terminologies
-
8/7/2019 SOA-REPORT (2)
20/45
20
3.1.4 Contract
A Contract is an expression of visible aspects of Service behavior. A contract is the service
interface specification accompanied with an additional set of requirements and constraints that
must be agreed between the client and the service. A service contract is comprised of one or
more published documents (called service description documents) that express meta information
about a service.
The concept of contract is considered essential to Web Services: contract represents the overall
agreement between the requester entity and the provider entity on how and why their respective
agents will interact; it is not necessarily written or explicitly negotiated. It may be explicit or
implicit, oral or written, machine process-able or human oriented, and it may be a legal
agreement or an informal (non-legal) agreement.
One may argue that any service description conforming to (a version of) the WSDL standard
actually represents a contract. This cannot hold; the service provider and the owners of the
consuming applications usually agree additional requirements and constraints that augment the
WSDL description. Therefore the combination of these two constitutes the contract. If we would
constrain the interaction in such a way that only the machine-readable agreements would be
allowed, then the argumentation would be different. WSDL descriptions would become
contracts, as there would be nothing else beyond it. In practice, this holds for the anonymous
interactions on Internet, where the machine-readable WSDL description is the only agreement
between the consumer and the service.
3.2 WHATS THE BEST FIT FOR SOA
You might be wondering in which business functions and situations SOA fits best and which
best shows its potential? There are some situations and business functions that should conjure
-
8/7/2019 SOA-REPORT (2)
21/45
21
SOA immediately, because SOA can boost competitiveness and productivity, and clearly display
its benefits. Such situations mainly include:
y Centralized business functions used by multiple entities: SOA helps to identify suchfunctions and package them into reusable, self-contained services that aren't affected by
process changes around them.
y Integration with partners: SOA promotes using standards, which is critical in anyintegration because standards create a common baseline for all parties to work on. Also, the
agility provided by SOA enhances the integration experience with the flexibility to plug in,
change, or update services almost seamlessly to your clients with SOA's decoupling
capabilities.
y The existence of old technologies that are still working: Some organizations aren't willingto give up their tried-and-true technologies. Security concerns make some customers,
especially in sensitive industries such as banking, suspicious of new software systems and
their unknown vulnerabilities. In these cases, SOA can help by wrapping legacy technologies
in standardized ways, enabling their exposure in a standards-based environment suited for
integration and reuse.
3.3 FACTORS MAKING SOA, AN AGILE OPTION
Because change is inevitable, the only guarantee of the continuity of a business is its ability to
anticipate and adapt to changes, also known as business agility. Crucial to the future of any
business, SOA makes business agility possible with the following factors.
2.3.1 Loose coupling
y Enables real-time business capabilities because it removes the hard connections that impedethe ability to change
y Changes the way IT costs are distributed, with less expenses in implementation and moreinvestments in reuse
-
8/7/2019 SOA-REPORT (2)
22/45
22
y Increases the feasibility of real-time remote access to original sources of information, thusreducing the delay and dependencies
y Integration projects are driven by business needs, with the visibility of capabilities provided(that is, business is the main driver)
y Lets companies extract more data measuring business performance in real time by exposingand sharing information
y Decreases time to market because connections to customers and partners can be made fastery Makes it easier for partners to do business with your companyy Promotes and publicizes your services, making it easier for customers to find you and your
services
y Makes it easier to find new partners and services by helping you search for the most suitableservice for your need
3.3.2 Reuse
y Makes processes more consistent because they depend on the same reused componentsy Promotes increased quality through competition between the services providersy Gives consumers a wide choice of suppliersy Covers essentially all classes of IT assets: hardware, software, data, and process assetsy Decreases the impact of change because it's done in a central location and reflects on all
concerned parties
y Lets you focus on business processes rather than technical implementationy Helps decrease the cost of integration because the component has already been integratedy Lets you make system changes without constraining business changey Promotes flexibility, which gives you more space to innovatey Lets you publish once but consume many times3.3.3 Extensibility
y Makes SOA solutions available to all sizes of organizations
-
8/7/2019 SOA-REPORT (2)
23/45
23
y Changes software-deployment activities from a big-bang model into a more dynamic, less-time-consuming model, which is more appropriate to the business
y Makes it easier to add or change partnersy Accelerates mergers and acquisitionsy Facilitates exposed services, which represent potential new revenue
3.4 SOA IS ALWAYS BETTER??
SOA provides benefits in almost all cases of business organizations. However, in very special
cases, it might prove to be a liability more than a drive towards better business. These cases
include:
y A homogeneous IT environment: If an organization depends on a set of coherentproductsbelonging to a same vendor, for example, has a limited scope of work, and has
no need to add or change any of these products, an SOA might be a liability more than a
useful strategy.
y When true real-time performance is critical: To provide loose coupling between differentconsumers and producers, an SOA depends on interoperable protocols, which are slow by
nature. It can also induce mediation logic and asynchronous protocols, which aren't suitablefor real-time performance.
y When things don't change: If the customer sees no change happening to the business logic,presentation, data flow, process, or any other aspect of the application, converting old
systems to SOA might not return sufficient value to make the effort worthwhile.
y When tight coupling is not an inconvenience: Loose coupling is of best use when it's usedwith a component that's not under your control and, this, you can't control its change. On the
other hand, when the component is yours and under your control, loose coupling can be a
burden, especially if the component isn't really reusable.
-
8/7/2019 SOA-REPORT (2)
24/45
24
3.5 SOA CONCEPTS
3.5.1 Definition of a service in SOA
There are a lot of different definitions of services, but I think these do the best job of explaining
what a service really is. "A service is a function that is well-defined, self-contained, and does not
depend on the context or state of other services."
3.5.2 The concept of loose coupling in SOA
To understand the concept of loose coupling in SOA, you should first examine the concept of
loose coupling in general. The following items demonstrate what loose coupling is and why it's
valuable:
y An entity is coupled if changes to the entity by one party in the interaction requirecorresponding changes by the other parties (for example, business data models).
y An entity is declared if its behavior is specified in the interface to the service, and servicerequesters and providers can only interact if they have matching declared behavior. Declared
aspects include security, transactional behavior, and quality of service (such as response time
and delivery).
y An entity is transformed if it's declared by both service requesters and service providers, butthe infrastructure provides some transformation capability to enable interactions between
service requesters and providers that declare mismatched behavior.
y An entity is negotiated if both requester and provider declare a spectrum of behaviors theyare able to support, and the intermediary infrastructure is capable of negotiating an agreed-
upon behavior between them for each interaction.
y An entity is decoupled if changes to the aspect by one party in the interaction don't requirecorresponding changes by the other parties. Loose coupling manifests itself in the SOA
paradigm as follows:
y It helps to have an abstraction layer between the service producers and service consumers.y Loose coupling promotes flexibility in changing the service implementation without
impacting the service consumers.
-
8/7/2019 SOA-REPORT (2)
25/45
25
y In the SOA approach, functionality is organized as a set of modular, reusable shared services.These services have well-defined interfaces that encapsulate the key rules for accessing the
services. They're also built without making any assumptions of who will use or consume
these services. Thus, they are loosely coupled to the consumer of these services.
3.6 HOW DOES XML CONTRIBUTE IN SOA
Based on open standards and promoting platform-independent business integration, SOA needs a
common platform to base its infrastructure on. This infrastructure needs to be supported by all
involved parties to form a common base of understanding. XML is at the core of this
infrastructure for the following reasons:
y XML is the foundation for virtually all Web services standards, such as XML schema,SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery,
and Integration (UDDI). These standards leverage the core concept of XML-based
representations, a worldwide supported format that carries out information interchange
between service providers and requesters in an SOA.
y Using XML resolves the challenge of working with different data formats in differentapplications across multiple platforms.
y XML has the benefit of ease of representation, being text-based, flexible, and extensible bynature.
3.6.1 XML Standards in SOA
3.6.1.1 SOAP: This simple XML-based protocol lets applications exchange information over
transportation protocols like HTTP. Using XML in SOAP guarantees that the SOAP protocol is:
y Platform independent.y Internet usable.y Humanly readable, structured, and text based.
-
8/7/2019 SOA-REPORT (2)
26/45
26
With the benefits above, SOAP is the recommended and most widely used communication
protocol for Web services. Knowing that Web services are the cornerstone for SOA, it's therefore
also the basic communication protocol for SOA solutions.
3.6.1.2 WSDL: WSDL is a document written in XML to describe a Web service. It specifies the
location of the service and the operations (or methods) the service exposes to let individuals
access those services. A WSDL file describes four main things:
y Services available by the Web service interface, such as listing names of methods andattribute messages
y Data types of messagesy Binding information for the transport protocol, such as HTTP and JMSy Service address to be used when calling it3.6.1.3 Electronic Business using eXtensible Markup Language (ebXML):
ebXML is a standard way to define the business transactions that can be performed between
different businesses. ebXML defines standard methods for business messages exchange,
establishing trading communications and registering business processes between companies.
3.7 SERVICE REGISTRIES
A service registry is a directory of services available in an SOA system. It contains the physical
location of services, versions and validity periods of services, service documentation, and
policies. A service registry is one of the main building blocks of an SOA architecture. Its role is
described below:
y The service registry realizes the SOA promise of loose coupling. By holding the serviceendpoint locations, it removes the high coupling resulting from hard-wiring the consumer to
the provider. It also eases the potential difficulties in replacing one service implementation
with another if needed.
-
8/7/2019 SOA-REPORT (2)
27/45
27
y A service registry is highly scalable; it evolves seamlessly should the system it serves grow.y It enables systems analysts to survey an enterprise's business services portfolio. They can
then determine which services are available to automate processes to address pressing
business needs and which aren't, letting you know what needs to be implemented and added
to the portfolio, providing a catalog of the available services.
y A service registry can step into the role of governing services by enforcing compliance forsubscribing services. This helps ensure the integrity of service governance and policies.
You'll learn more about governance and its importance in SOA later in this tutorial.
y Visibility of the available services and their interfaces allows speedier development, greaterapplication reuse, improved governance, and better business planning and management. The
lack of a service registry leads to redundancy and inefficiency.
y Service registries help reduce time wasted in locating service information.y Without a registry to track services and their relationships, an SOA environment not only
lacks coherence and control, it invites chaos.
3.8 SOA TECHNOLOGY SIDE: WHAT WORKS AND WHAT DOESNT
As we see there is a strong relationship between SOA and distributed systems. SOA is glue that
makes it possible to interoperate and collaborate disparate systems. Given the involvement of
distributed computing within an SOA, it is worth understanding what works and does not work
in distributed system technologies. Following are the three major constraints where we really
need to take a look at.
3.8.1 Technology Constraint: Technology Dependent Systems Generally Dont Work
First and foremost, its a proven fact that tightly-coupled distributed systems generally do not
work. The property of being tightly-coupled leads to solutions that dont extend and are difficult
to adapt. Also they dont last for longer. Every organization makes its own technology decisions
based on its own needs. It is unrealistic to expect an organization to use a particular technology
-
8/7/2019 SOA-REPORT (2)
28/45
28
just to provide the capability of having reusable IT assets. In todays fast emerging technology
world, you cant expect that they will all operate with the same technology, or version of
technology and this is what we call technology constraint. Previous distributed solutions such as
CORBA, DCOM etc had a dependency of same technology to be used everywhere which was
unrealistic thats why ended up in failure. The key point is that every organization should be
given a leverage of using the technology that better fits their needs and thats where SOA seems
to excel. SOA design is such that it frees an organization from the technology to be used. Java
services can be exploited in .net environment and vice versa. Even a service hosted on a Linux
server is consumable on Microsoft platform. As long as the service is discoverable on web it can
be consumed anywhere in the world over the web.
3.8.2 Temporal Constraint: Never Expect Time-Sensitive Service Response
Temporal constraint refers to the time sensitive behavior of a service. The golden rule to
remember in SOA world is that Never reliably expect that calling a function over a distributed
network will respond in a timely manner. This is due to the fact that there is a higher chance of
running into a system failure over the distributed system than in a local address space. Network
failures are also common; the target machine may be down for several hours; or the function you
are calling may be so heavily overloaded handling requests from other clients.
3.8.3 Organizational Constraint:Every Organization Has Independent Development Cycles
Finally, there is organizational constraint according to which different organizations will often
have independent development cycles evolving the parts of the distributed system at different
rates. It is easy for one organization to introduce bug fixes to their part that will affect behavior
that your part depends on. Likewise, they may introduce even more severe changes to address
new requirements that will break your interface to their part.
-
8/7/2019 SOA-REPORT (2)
29/45
29
CHAPTER 4
PROPOSED WORK
4.1 SOA PERSPECTIVES
4.1.1 Business Perspective SOA
SOA is actually done by developers and architects. There are many stakeholders whose interests
actively drive the design of the SOA solution.
The business analyst is concerned with bringing IT infrastructure more in line with the business
strategy. This effectively means that SOA solutions should be designed such that the business
analyst has greater insight into the costs and benefits of various IT investments.
CTO of the organization will make sure that the solution should meet the needs of the business
analyst. He also makes sure that existing applications are preserved and integrate well with
newly developed capabilities.
IT manager is concerned with making management of distributed systems easy. He also makes
sure that these distributed systems integrate well to yield greater business value.
Developers and solution architects are concerned with creating highly dynamic composite
applications that meet the goals of the various stakeholders. The service orientation approach is
the best approach today to deal with heterogeneity. It integrates these heterogeneous so well that
it meets the needs of the organization as a whole.
4.1.2 Technical Perspective of SOA
The Enterprise architect view it as a set of architectural principles and patterns addressing overall
characteristics of solutions such as modularity, encapsulation, loose coupling, separation of
concerns, reuse, composability and so on.
-
8/7/2019 SOA-REPORT (2)
30/45
30
A Project manager sees it as a development methodology supporting maximum reuse and greater
time to value.
A Tester or quality assurance engineer Views it as a way to modularize, and consequently
simplify, overall system testing.
A Software developer Views a programming model complete with standards, tools, and
technologies, such as Web services.
4.1.3 IT Department SOA Perspective
From the IT departments point of view, SOA-based integration has following advantages,
y simplifies management of distributed resources across multiple platforms,y requires less hardware,y is more reliable,y is standards-based andy Is less costly.
4.2 CONVERGENCE OF SOA AND WEB 2.0
There are at least two significant connection points which relate Web 2.0 and SOA. One is that
Web 2.0 can be conceptualized as a global SOA. Two, that many traditional brick-and-mortar
business that are currently using SOA as their architectural model will want to connect their
Web/Web 2.0 faces up to their SOA. This makes Web 2.0 not just being the Global SOA but
makes meeting smaller SOAs everywhere not just likely, but inevitable. We're talking serious
convergence of focus here. If true, this means that more than half of all software development,
SOA and otherwise, will revolve around the Web, inside or outside organization boundaries. All
of this means Web 2.0 and SOA will meet each other both coming and going, and begin tobecome each other as well.
-
8/7/2019 SOA-REPORT (2)
31/45
31
Figure 4.1 SOA and Web 2.0 Convergence
4.3 SOA IN AN ENTERPRISE
As an architectural principle for delivering agility and flexibility by decoupling interface and
implementation (business logic), SOA has been in existence for decades. Object-oriented and
component-based development models were established by using the same principle. Recent
technological developments and Web-service standards have made SOA easier by replacing
method calls on object references to message passing.
In large enterprises, services have been delivered in isolation by several projects that are based
on LOB requirements in the organizationnot as a big-bang SOA-definition project. Enterprise-
architecture (EA) efforts in the organizations helped identify the reusable services and leverage
existing investments. Because SOA facilitated interoperability, many legacy applications were
exposed as services and the business functionality was reused.
SOA became the EAI driver across the company, and EAs have evolved into on-premise
distributed systems that are enabled by SOA
-
8/7/2019 SOA-REPORT (2)
32/45
32
4.4 THE CLOUD OPPORTUNITY
Cloud computing presents both a model and new opportunities for technology buyers in an
enterprise. It offers the opportunity to focus on the core capabilities of an enterprise by
outsourcing certain aspects of IT and reducing IT costs. It also accelerates the provisioning and
deployment with the support hassles that are transferred to the cloud-service provider. The Cloud
is altering the way in which organizations build their infrastructure and applications.
The essential characteristics of cloud computing include both the delivery model and the
commercial model. In terms of the delivery model, it should be available as a service over the
Internet and accessible either from a Web browser or as a Web service. Commercially, users pay
for service usage; both the overall maintenance effort and user costs are low.
Technologically, the Cloud is a culmination of standards and technologies that have come
together over the past several years. They include server virtualization, Web Security, and Web
Services. The implication for the enterprise is that dynamically scalable infrastructure is
available transparently, without any IT involvement in building and managing the infrastructure.
4.4.1 Cloud Computing Models
y Infrastructure as a Service (IaaS),y Platform as a Service (PaaS), andy Software as a Service (SaaS)4.4.1.1 Infrastructure as a Service: Delivery of server infrastructure as a service. An enterprise
does not need to purchase servers, networking equipment, or data-center real estate. It is all
managed by the cloud provider who also dynamically scales up or down, based on the
application-workload requirements. Examples of IaaS are Amazon Elastic Compute Cloud (EC2)
and AppNexus.
4.4.1.2 Platform as a Service: Infrastructure and complete development environment and
computing platform for application development and deployment in the Cloud. Examples of
PaaS are the Windows Azure Platform and the Google App Engine.
-
8/7/2019 SOA-REPORT (2)
33/45
33
4.4.1.3 Software as a Service: Web-based deployment model, so that the entire application
software is available through the Web browser as a service. Again, pricing is based on usage.
Examples of SaaS are SalesForce.com, Windows Live Hotmail, and Microsoft Dynamics CRM
Online.
4.4.2 Application Characteristics for the Cloud in an Enterprise
Figure 4.2 Application Characteristics for Cloud in an Enterprise
The cloud adoption in enterprises initially is led by tactical opportunities that offer
implementation speed and cost advantages to these enterprises, although there are a few
misconceptions about when to use the Cloud and the associated technological challenges in
moving toward it. Security, performance, availability, and reliability are the top concerns that IT
managers cite for adopting the Cloud. Cloud providers are addressing these concerns through
appropriate architectural measures and service-level agreements (SLAs) to gain user confidence
in the Cloud.
-
8/7/2019 SOA-REPORT (2)
34/45
34
4.5 MODEL BUSINESS DRIVERS AND APPLICATION SCENARIOS
4.5.1 Rapid global expansion
Global usage of service-based loyalty application Extension of homegrown e-commerce system internationally Readiness to address peak workload for e-commerce New store portal for store staff Centralization of store systems
4.5.2 Branding and superior customer service
New social-media applications for customer feedback and collaboration New CRM system for repairs service Launch of online marketing campaign
4.5.3 Driving growth via new business services and channels
New venture into online home-appliance retailing
Figure 4.3 Model Business Drivers
-
8/7/2019 SOA-REPORT (2)
35/45
35
Figure 4.4 Mapping Application Scenarios to Cloud Characteristics
Figure 4.5 Mapping Application Scenarios to Cloud Types
-
8/7/2019 SOA-REPORT (2)
36/45
36
4.6 POSSIBLE INTEGRATION SCENARIOS
The possible integration scenarios between on-premise and Cloud- based applications are as
follows:
y Browser access only: Usually, SaaS applications are full-service standalone applications thatare accessible via a Web browser.
y Cloud functionality that is exposed as a service for consumption by on-premise or othercloud applications.
y Existing on-premise business functionality or services that are exposed to the Cloud.y Data integration between on-premise and cloud data stores.Such emerging hybrid models of on-premise and cloud applications result in a new class of
distributed applications. SOA-based integration with SOAP or REST Web Services seems to be
the easy answer to this problem; however, there are various other issues that should be handled
for it to work across organizational boundaries and firewalls.
4.7 CONSIDERATIONS FOR CLOUD INTEGRATION
4.7.1 Existing SOA investments: There is commonality in the business objectives of SOA andcloud computing with regard to delivering agility, flexibility, and reuse. The existing core
business services that have been developed within the enterprises will coexist and integrate with
the services in the Cloud. This is again enabled by SOA. The integration solution should address
the challenge in letting outside organizations find endpoints of the on-premise services.
4.7.2 Enterprise-architecture practices: SOA is part of the EA mainstream. The scope of
existing organization practices for EA, such as governance, are preserved and extended to the
Cloud (the Cloud is also part of the enterprise technology portfolio).
-
8/7/2019 SOA-REPORT (2)
37/45
37
4.7.3 Access across firewalls: To expose existing on-premise services to the Cloud, enterprise
IT has to deal with issues such as handling network-address translation and enabling access
through a firewall by opening new ports.
4.7.4 Security-access control: In the distributed application, we need an access-control solution
that works across enterprises that holding their own identity information. The solution should
address key quality-of-service (QoS) requirements, such as system availability and reliability of
integration points.
4.8 CLOUD EXTENSION USING WINDOWS AZURE PLATFORM .NET SERVICES
The Windows Azure Platform is an Internet-scale, cloud-computing services platform that is
hosted in Microsoft data centers. The Windows Azure Platform uses SOA heavily and provides
SOA-based access to data.
.NET Services is one of the components of the Windows Azure Platform; it provides cloud-
based infrastructure services and facilitates creation and deployment of composite applications.
.NET Services comprises an access-control service and a service bus.
y Access controlCloud implementation of claims-based identity federation for performingfederated access-control authorization as a Web service across organizations and protocols.
This service utilizes standard protocols, such as WS-Trust and WS-Federation.
y Service busAllows applications that expose Web-service endpoints to be located andaccessed by clients. This service enables communication between two applications- both of
which might run in the Cloud; one of which might run in the Cloud and the other on-premise;
or both of which might run on-premise, but across different enterprise data centers. It also
addresses the firewall-access issues of enterprise systems and enables connection, without
requiring data centers to open new ports for accessthus, providing location transparency to
integrating applications
-
8/7/2019 SOA-REPORT (2)
38/45
38
4.9 SOA AND GRID COMPUTING
There has been an increase in interest recently within the Grid community towards "Service
Oriented'' Paradigms. Services are often seen as a natural progression from component based
software development, and as a means to integrate different component development
frameworks. A service in this context may be defined as a behaviour that is provided by a
component for use by any other component based on a network-addressable interface contract
(generally identifying some capability provided by the service). A service stresses
interoperability and may be dynamically discovered and used. According to the "Open Grid
Services Architecture" (OGSA) framework, the service abstraction may be used to specify access
to computational resources, storage resources, and networks in a unified way. How the actual
service is implemented is hidden from the user through the service interface. Hence, a computerservice may be implemented on a single or multi-processor machine- however these details may
not be directly exposed in the service contract. The granularity of a service can vary- and a
service can be hosted on a single machine, or it may be distributed. The "TeraGrid'' project
provides an example of the use of services for managing access to computational and data
resources. In this project, a computational cluster of IA-64 machines may be viewed as a
compute service, for instance -- hiding details of the underlying operating system and network. A
developer would interact with such a system using the GridSDK toolkit, derived from Globus,
and consisting of a collection of services and software libraries.
Web Services provide an important instantiation of the Services paradigm, and comprise
infrastructure for specifying service properties (in XML -- via the Web Services Description
Language (WSDL) for instance), interaction between services (via SOAP), mechanisms for
service invocation through a variety of protocols and messaging systems (via the Web Services
Invocation Framework), support for a services registry (via UDDI), tunneling through firewalls
(via a Web Services Gateway), and scheduling (via the Web Services Choreography Language).
A variety of languages and support infrastructure for Web Services has appeared in recent
months -- although some of these are still specifications at this stage with no supporting
implementation. Web Services play an important role in the Semantic Web vision, aiming to add
-
8/7/2019 SOA-REPORT (2)
39/45
39
machine-processable information to the largely human-language content currently on the Web. A
list of publicly accessible Web Services (defined in WSDL) can be found at www.xmethods.net.
By providing metadata to enable machine processing of information, the Semantic Web provides
a useful mechanism to enable automatic interaction between software -- thereby also providing a
useful environment for agent systems to interact.
4.10 SOA BENEFITS
4.10.1 Organizing Distributed IT Resources
Service orientation is an approach to organizing distributed IT resources into an integrated
solution. No matter where information resides be it enterprise local intranet or its over the web,
as long as some service is available, it can be used anywhere. Ultimate fruit of SOA is composite
applications. These applications provide end users with more accurate and comprehensive
information and insight into processes. Also, users have the flexibility of using them in most
suitable form such as via,
y Web,y rich client,y Mobile device etc.SOA enabled Composite applications are so dynamic that enable businesses to improve and
automate manual tasks and allow them to integrate heterogeneous data spread across
organization. This ultimately gives business greater agility and ability to compete in marketplace.
4.10.2 Integrating Distributed IT Resources and Assets
Today Complex, distributed, heterogeneous IT resources are a serious concern for our
businesses. Many a times, we observe that
y our existing IT services dont adequately meet specific business needs,y its maintenance cost is extremely highy its change responsiveness is extremely low
-
8/7/2019 SOA-REPORT (2)
40/45
40
Full systems rip and replace or a complete renovation is not a practical solution anymore. A
better solution is however is to leverage existing IT investments so that overall organizational
goals are effectively supported. With Service orientation, systems become more responsive to
changing business needs, easier to manage and maintain. It also allows helping plan ahead for
change rather than following a reactive approach.
4.10.3 Aligning IT with Business
In todays fast changing world, many times business demands change without any plan. For
these changing conditions, IT department does not have enough time to respond. The reason
being may be IT infrastructure is inflexible in terms of supporting business changes in a
reasonable time. This is where we really need alignment of IT with business. By aligning IT with
business we mean IT infrastructure should be capable enough to adapt changing business
requirements in a reasonable response time.
SOA is an IT architectural style that supports the transformation of your business into a set of
linked services, or repeatable business tasks that can be accessed when needed over a network be
it intranet or internet. With this a dream of IT alignment with business has come true.
4.10.4 Maximal reuse of IT assets
In SOA enabled IT solutions, IT assets are managed in terms of services which are reusable to a
greater extent; this allows us to reuse IT assets to a maximum.
4.10.5 Stronger Connections with Customers and Suppliers
By making dynamic applications and business services available to external customers and
suppliers, not only is richer collaboration possible, but also customer/partner satisfaction is
increased.
4.10.6. Enhanced Business Decision Making
-
8/7/2019 SOA-REPORT (2)
41/45
41
In, Todays world, we see that quick decision making stands at the center of business. SOA
enabled solutions make it possible to access information in various possible ways be it Web, rich
client, mobile device etc. Due to this information is readily available for decision makers.
4.10.7 Greater Employee Productivity
SOA enabled solutions, allows employees gain timely access to the information they need. This
greatly increases employee productivity.
4.10.8. Time-To-Value is Much More Immediate with SOA
The real-world approach to SOA also emphasizes time-to-value. Time to value is more reliable
measure than ROI since any project can have a good ROI as long as it is amortized for a
reasonably long time. With ROI there is always an uncertainty, whether the business can survive
for that long to realize that return. With SOA, time to value is much more immediate.
-
8/7/2019 SOA-REPORT (2)
42/45
42
CHAPTER 5
CONCLUSION AND FUTURE WORK
5.1 SOA FUTURE IN THE EYES OF INDUSTRY EXPERTS
Kerrie Holley, [email protected]
KERRIE HOLLEY, IBM Fellow, is CTO of IBMs SOA Center of Excellence. According to
him:
One improvement with SOA might be the fact that Web Services (despite all its flaws)
introduces a new standard for interoperability. However, there is another important aspect of
SOA, which represents a revolutionary approach different to what weve typically seen before
the acceptance of heterogeneity. In the past, far too many solutions were based on the idea of
homogenization. Yet in systems beyond a certain size, homogeneity is simply not possible.
Homogeneity does not scale, which means that any approach that requires homogeneity will
sooner or later fail. Accepting heterogeneity changes the way we design large systems
landscapes. This mental shift might be a small step, but it can have dramatic consequences
(similar to agile programming, which accepts that requirements change instead of trying to fight
against this fact). Based on this we definitely think that there is a future for SOA (just as there is
a future for brainpower.
Brenda Michelson,[email protected]
BRENDA MICHELSON is an IT strategist, community leader, hands-on practitioner, and the
voice of business driven architecture. According to him,
Service-oriented architecture is much broader than the technology underpinnings that often
describe it. Service oriented architecture provides a means to express business activities as
modular, configurable and composable software services. These business services can be
combined with business events (EDA), rules and policies into business processes (BPM) and
-
8/7/2019 SOA-REPORT (2)
43/45
43
interactions that actually match the intent of the business strategists and process owners. While
SOA offers great promise, achieving the business benefits of SOA requires changes for both
business and IT. Most notably, business and IT must collaborate on business architecture and
business service definition, and embrace the management discipline for a shared services
environment.
John DeVadoss, [email protected]
JOHN DeVADOSS is Senior Director for Technical Strategy in the Application Platform and
Developer division at Microsoft. According to him,
Service orientation is a means for building distributed systems. At its most abstract level, service
orientation views everything from the mainframe application to the printer to the shipping-
dock clerk to the overnight delivery companyas a service provider. Service providers expose
capabilities through interfaces, and service-oriented architecture maps these capabilities and
interfaces so they can be orchestrated into processes.
Nicolai M. Josuttis, [email protected]
NICOLAI M. JOSUTTIS (www.josuttis.com) is an independent system architect, technical
manager, author, and consultant. According to him,
If you can avoid distributed business processing, avoid it but if you have the requirement of
dealing with business processes distributed over multiple heterogeneous systems with different
owner, SOA principles are the only way to be able to be successful and still be flexible. And
because distributed processing will be a key success factor for future businesses, SOA will
remain as a fundamental IT paradigm.
5.2 CONCLUSION
The SOA terminology will converge but it will be a long process hampered by the ongoing
SOA hype. I view SOA-RM as a step in the right direction, but there are some deficiencies and
disputable points of detail. There are no discrepancies between the general SOA concepts and the
Web Services concepts; the definitions in the context of Web Services are indeed specialty
-
8/7/2019 SOA-REPORT (2)
44/45
44
definitions. The terms denote exactly the same concepts, with the only difference that the Web
Services definitions are narrowed by the implementation constraints. Will the definitions Ive put
forward help to take away some of the confusion? I believe they will, but I would also like to
stress that Im not advocating some kind of rigid language in our profession. That is not needed
as long we are involved in a professional debate among peers and are discussing concrete issues.
Then there is no harm done if we, for example, use the words message ormethodwhen actually
referring to an operation, even in writing. More rigor is needed when we communicate with other
professions, like business analysts and management on one side and developers on the other.
And that is, probably needless to say, what architects do (doing) regularly.
The primary goal of Service Oriented Architecture (SOA) is to align the business world with the
world of information technology (IT) in a way that makes both more effective. SOA is about the
business results that can be achieved from having better alignment between the business and IT.
Moreover, the SOA approach lets enterprises reuse software assets, thereby achieving a better
return on their IT Investments. There is a widespread tool support for SOA and as we see that
Microsoft is proving to be a leader in SOA evolution. The Future of SOA is very bright because
it emphasizes time-to-value. With SOA, time to value is much more immediate.
While there are different perspectives on Service Oriented Architectures (SOA), there is
widespread agreement that it is not a product or a technology but an approach, a style of
architecture that uses the service model to enable integration across diverse systems.
After discussing the advantages and promises that SOA delivers we come to conclusion that
SOA definitely as a broader long term future. The future of SOA lies in its power of being
independent from technology. This was a weakness of previous distributed solutions such as
DCOM, CORBA etc. We end the topic by concluding that just as there is a future for common
sense so there is definitely a future for SOA.
-
8/7/2019 SOA-REPORT (2)
45/45
REFERENCES
1.
www.wikipedia.org
2. www.soamodelling.org3. www.itinform.com4. www.stackoverflow.com5. www.service-architecture.com6. Gregor Hohpe SOA World7. Wenguang Wang Service-Oriented Framework