SYNOPSIS

On
Service Oriented Architecture:
A Design and Implementation Model
Presented to the Department of Computer Science
Punjabi University, Patiala for registration of
Degree of
DOCTOR OF PHILOSOPHY

Submitted by
Ashish Seth

Supervisor
Dr. Himanshu Aggarwal
Reader, University College of Engineering (UCoE)
Punjabi University, Patiala.

Co-Supervisor
Dr. Ashim Raj Singla
Assistant Professor,
Indian Institute of Foreign Trade (IIFT), New Delhi

INDEX
CONTENTS

PAGE No.

1: INTRODUCTION

02 - 05

2: SURVEY OF LITERATURE

06 - 10

3: NEED OF THE STUDY

10 - 11

4: OBJECTIVES OF THE STUDY

11 - 12

5: SCOPE OF THE STUDY

6: RESEARCH METHODOLOGY
7: PROPOSED CHAPTERISATION
8: BIBLIOGRAPHY

13
13 - 15
16
16 - 19

INTRODUCTION
Service-oriented architecture (SOA) provides methods for systems development
and integration where systems group functionality around business processes and
package these as interoperable services. SOA also describes IT infrastructure which
allows different applications to exchange data with one another as they participate in
business processes. Service-orientation aims at a loose coupling of services with
operating systems, programming languages and other technologies which underlie
applications. SOA separates functions into distinct units, or services, which
developers make accessible over a network in order that users can combine and reuse
them in the production of business applications. These services communicate with
each other by passing data from one service to another, or by coordinating an activity
between two or more services. SOA offers an architecture, which unifies business
processes by structuring large applications as an ad hoc collection of smaller modules
called "services". Different groups of people both inside and outside an organization
can use these applications, and new applications built from a mix of services from the
global pool exhibit greater flexibility and uniformity.

Figure-1 - The basic service oriented architecture

The basic SOA is not architecture only about services; it is a relationship of three
kinds of participants: the service provider, the service discovery agency, and the
service requestor (client). The interactions involve the publish, find and bind
operations, (see Figure-1). These roles and operations act upon the service artifacts:
the service description and the service implementation. In a typical service based
scenario a service provider hosts a network accessible software module (a
implementation of a given service). The service provider defines a service description
of the service and publishes it to a client or service discovery agency through which a
service description is published and made discoverable. The service requestor uses a

find operation to retrieve the service description typically from the discovery agency,
i.e., a registry or repository like UDDI, and uses the service description to bind with
the service provider and invoke the service or interact with service implementation.
Service provider and service requestor roles are logical constructs and a service may
exhibit characteristics of both.
This architectural approach is particularly applicable when multiple applications
running on varied technologies and platforms need to communicate with each other.
In this way, enterprises can mix and match services to perform business transactions
with minimal programming effort. SOA as architecture relies on service-orientation as
its fundamental design principle.
Role of SOA in Organization - SOA has gained ground as a mechanism for defining
business services and operating models (e.g., Business-Agile Enterprise) and thus
provide a structure for IT to deliver against the actual business requirements and adapt
in a similar way to the business. The purpose of using SOA as a business mapping
tool is to ensure that the services created properly represent the business view and are
not just what technologists think the business services should be.
At the heart of SOA planning is the process of defining architectures for the use of
information in support of the business, and the plan for implementing those
architectures. Enterprise Business Architecture should always represent the highest
and most dominant architecture. Every service should be created with the intent to
bring value to the business in some way and must be traceable back to the business
architecture. Thus SOA within business is focused on a strict governance process and
the use of semantics to improve the usefulness of services in business process
innovation. SOA into business can be thought of as a set of layers , each of which has
an objective to integrate business process and services to meet the business objective
in dynamic fashion (see figure 2 )

Figure 2 SOA Layers focuses on Business Process and Services

Enterprise Middleware Services The middleware services are the integration fabric,
which the various service providers and consumers use. These provide the decoupling
facilities, which enable service consumers and providers to discover each others
capabilities, without needing any apriori knowledge of other platforms. The
middleware provides the mediation services, which enable all parts of the system to
dynamically make the best use of any of the existing facilities (access rights
permitted) as they become available. The key functions, which the middleware must
provide fall under three categories:
(1) Service registry/discovery. As it is undesirable to manually provide each
Component with an a priori knowledge of what other services are available on the
enterprise network, an automated discovery of services must be provided. This must
be dynamic, allowing flexibility for adding, removing or modifying services, as the
business requirements evolve.
(2) Service access control. Just because service platforms belong to a single enterprise
does not mean they can share all information freely, and that service access rights are
universally granted. Moreover, the cost of providing services internal to the enterprise
may require metering and billing from one department Therefore this coordinates
authentication, authorization and accounting functions.

(3) Information exchange. The various components of the overall system should be
decoupled in space, time and synchronization. The service bus performs these
functions.
Service A Service is an implementation of a well-defined business functionality that
operates independent of the state of any other Service defined within the system.
Services have a well- defined set of interfaces and operate through a pre-defined
contract between the client of the Service and the Service itself. From a dynamic
perspective, there are three fundamental concepts that are important in understanding
what is involved in interacting with services: the visibility between service providers
and consumers, the interaction between them, and the real world effect of interacting
with a service. (See figure 3)
Service Provider

Visibilt
y

Service Consumer

Interaction

SERVICES

Real World
Effect

Figure 3 Service Model

UML
Unified Modeling Language is adopted by major software development companies to
represent various aspects of the systems. Models are blueprints for the systems, the
result for the modeling process is the ability to trace the business needs to the
requirements to the model to the code, and back again, without getting lost along the
way. UML allows people to develop several different types of visual diagrams that
represent various aspects of systems. They are as follows

Use case diagram

Sequence diagram
Collaboration diagram
Class diagram
State transition diagram
Component diagram
Deployment diagram

Use case Diagram shows the interaction between use cases, which represent system
functionality, and actors, which represents the people or systems that provide or

receive information from the system. It represents the requirements of system from
user perspectives, use case are the functionality that system provides
Sequence Diagram are used to show the flow of functionality through the use case
Collaboration Diagram shows exactly the same information as the sequence
diagram. However, this diagram shows this information in a different way and with a
different purpose. People look at this diagram for different purposes, which would not
been possible in sequence diagram
Class Diagram shows the interactions between classes in the systems. Classes can be
seen as the blue prints for objects. This diagram shows the static picture of class and
their relationship
State Transition Diagram provides a way to model the various states in which an
object can exist. This is used to model the more dynamic behavior of a system. They
may not be created for every class; they are used only for very complex classes. They
are created for documentation only
Component Diagram show a physical view of your model, it show s the software
component in your system and the relationship between them
Deployment Diagram shows the physical layout of the network and where the
various components will reside. Project manager, users, architect, and deployment
staff to understand the physical layout of the system and where the various
subsystems will reside.

SURVEY OF LITERATURE
An issue that emerges with this study is how do organizations choose which SOA
infrastructure to acquire and what pieces they will need to build themselves? How
does an organization test the infrastructure sufficiently to guarantee the level of
security, governance and management provided meets their requirements? How is
interoperability between different vendor infrastructures handled? In order to
undertake a project to develop a service or an application from services there is a need
to know the scope and size of the work involved. This will help in determining the
cost and effort for such a project.
According to Liam OBrien, ET al. (ACM 2008) there are various aspects to
the introduction of SOA from mining and reusing legacy components as services in an
SOA-based environment to acquisition and development of an SOA infrastructure.
When an organization wants to introduce the use of SOA there are various aspects that
it needs to consider. These include: (1) The identification and mining of services from
6

its existing/legacy systems. (2)The integration of common/shared services provided

by one government agency and used by other agencies) services with existing/legacy
systems. (3) The acquisition and development of an SOA infrastructure (including
middleware). (4) The development of services and development of applications from
services.
Similarly Olaf Zimmermann, et al.(ACM 2005) suggest combination of business
dynamics and domain-specific functional characteristics creates many challenges for
IT. It is identified that an SOA-based approach with process choreography is perfectly
valid for the order entry management scenario and it must also considered for other
technical benefits included separation of concerns through strict layering, improved
resource management via compensation and runtime reuse of shared application
functionality made available as business and application services. More formal
services are also investigated for modeling and asset management approaches to
facilitate successful reuse of business services. Furthermore Luciano Resende,
Raymond Feng, IBM (ACM 2007) provides the solutions that are composed of
services that offer business functionality as a unit or as a whole. These services will
access data from different data source types and potentially need to aggregate data
from different data source types with different data formats. In this type of
environment, handling of different forms of data poses a big challenge for application
developers, and the challenge increases in size when you consider the broad diversity
of programming models in use.
Service Data Objects (SDO) is a specification for a programming model that unifies
data programming across data source types and provides robust support for common
application patterns in a disconnected way. Similarly,Apostolos Malatras, et al.
(Emerald Vol 6 No, 2, 2008) presents the design of an enterprise-based architecture
The proposed architecture is compliant with established practices in the building
automation field and focuses on catering for a wide spectrum of building and
enterprise level services. The architectural framework proposed assembles all
underlying functionality and hides complexity from the upper-layer applications, by
presenting to the building manager a unifying point of interaction for every operation
regarding building services, while allowing for new service composition supporting
novel applications. According to S. Navabpour, et al. (IEEE 2008) SOA has
7

considerable business and scientific value and will attract users and developers.
Similarly Kostas Kontogiannis, et al. (IEEE 2007) investigate an initial classification
of challenge areas related to service orientation and service-oriented systems.
From a business perspective, service-oriented systems are a way of exposing legacy
functionality to remote clients, implementing new business process models by
utilizing existing or third-party software assets, reducing the overall IT expenditures
while potentially increasing the potential for innovation through software investments
From either perspective, and despite their initially slow adoption and the conflicting
standards proposed to support them, service-oriented systems are becoming the defacto approach to bridging the gap between business models and software
infrastructure and flexibly supporting changing business needs. Mike P. Papazoglou
,et al (Springer Verlag 2007) also work on unifying the principles and concepts of
SOA with those of event-based programming. The authors proposes an approach to
extend the conventional SOA to cater for essential ESB requirements that include
capabilities such as service orchestration, intelligent routing, provisioning, integrity
and security of message as well as service management.
According to Florian Irmert,et al(ACM 2008) In a SOA environment services as well
as applications build up complex dependencies. Therefore it is crucial for selfmanaging SOA applications to adapt services at runtime without interference of the
application execution and the service availability. For a seamless integration they
strive for a transparent and atomic replacement of a service implementation in respect
to the other services/applications. Similarly Bao rong Zhong,et al (IEEE 2008)
suggest The decision support system for oil production based on SOA is a complete
SOA system. it also has many advantages, such as easy integration, good
maintainability.
Enterprises bus (ESB) for future upgrades does well in expansion. Enterprises Service
Bus is of key status in SOA based enterprise integration application environment. It is
responsible for wrapping legacy application to service, synchronous or asynchronous
transport, and supporting the enterprise business integration across different
organizations. According to Jianqiang Hu, et al(IEEE 2008) Major contribution of
ESB are as follows: (1) presenting unified transport adaptation and service adaptation
8

to improve the interoperability of enterprise applications across different

organizations; (2) defining multiple SOAP scheduling algorithm and SOAP security
framework for B2B integration and ecommerce development. Some authors argue
that in the basic SOA model access to metadata is too static and results in inflexible
interactions between requesters and providers. Others authors specify extensions to
the SOA model to allow service providers and requestors to dynamically expose and
negotiate their public behavior, resulting in the ability to specialize and optimize the
middleware supporting an interaction. We can introduce a middleware architecture
supporting

this

extended

SOA functionality,

and

describe

conformant

implementation based on standard Web services middleware In essence; services act

as layer of abstraction between the business and the technology. Business agility is a
fundamental business requirement.

Boris Shishkov, et al.(IEEE 2006) suggest

improvements with respect to the business-application alignment in the design of

application software. Authors propose a model-driven service-oriented approach
which is essentially concerned with consistency as the target quality to ensure
business-application alignment; they show how different business and application
models that progressively capture more details can be consistently derived from an
initial business model.
The Service Component Architecture (SCA) is an emerging technology as a
standardized programming model for SOA applications, and therefore the SCA policy
framework has also been discussed in the research community. In response to current
pursue of achieving business agility and technology flexibility through SOA, we are
in position to conclude what an SOA is?, what it really means to an enterprise, where
it is right now, where it is leading to, how to practice it, the expected benefits. It
includes discussion in SOA concepts, technologies, and best practices based on
practice experience, survey from public sources, as well as initial ideas and
contributions. SOA enables agile businesses through composable business processes
and services that will be supported by flexible and composable IT services. The
commonly accepted standards will ensure interoperability, shareability, and
reusability. SOA can be applied to the full spectrum of enterprise business and IT,
which include business service specification, IT strategic planning, enterprise
architecture, solution development, and business operation.

Also, SOA can be considered as a practical modeling approach for enterprise

architecture (EA) development. It can help to bridge EA with solution architecture
and implementation by layered service descriptions across business modeling,
application modeling, and technology implementation; so that it can help bring EA
into reality. The concept of SOA is not new, which can be traced back to the Common
Object Request Broker Architecture (CORBA). The recent popular component-based
and service-oriented architecture has extended its scope to business domain; Web
Services enable the SOA concept being applied in web environment. The
recommended SOA adoption steps are discussed in three stages: SOA initiation, SOA
workgroup formation, and SOA practice. SOA initiation includes SOA planning, and
establish baseline for cross organizational SOA adoptions. The SOA workgroup
usually will be an extension of existing EA team, and will serve as the core for SOA
practice. The SOA practice includes the development and documentation of strategic
plan, governance, and approaches; the extension of enterprise architecture; the
coordination of cross organizational SOA implementation; service institutionalization;
service extension for enterprise external services; etc.

NEED OF THE STUDY

1. While successful examples of individual automated enterprise services and
systems exist there is an evident lack of holistic, integrated technical solutions
that can be applied in small and medium size enterprises
2. Slow adoption of SOA despite good prospects and IT implementation for
sustainable and technical advantage.
3. Shortage of studies, research thrust and limited expertise in the area of SOA
keep the application of SOA in SME limited, Also country like India whose
major economy is dependent on the small and medium enterprises,
Government of India is emphasis to promote the growth in this sector. This in
itself is a large potential for research if some technical framework is there that
can integrate all activities comprising Supply Chain Management (SCM),
Customer Relationship Management (CRM), Technical and Enterprise
applications tools..
Keeping above points in mind and existing research gaps, the need for such a
SOA framework is evident due to the numerous benefits it can bring to both small
10

and medium size enterprises. The following study is proposed to be undertaken

Service Oriented Architecture (SOA):

A Design and Implementation

Model

OBJECTIVES OF THE STUDY

The following objectives have been defined for the present work
1

To investigate series of processes/activities (value chain activities) in Small

and Medium size Enterprises (SME)

To propose an SOA based design and implementation model for value chain
activities (as identified in objective 1)

To identify critical success factors for the proposed SOA model (Risk
Analysis)

To test and identify the interdependency of activities/processes within the

proposed model.

To present Use Case Diagram using UML (Unified Modeling Language) for
the proposed model.

Proposed Architecture
The following architecture is proposed for the current research work. The research
work will focus on the service composite part, where different services are combined
considering the governance of overall architecture (see figure 4).

11

Discovery

Service Endpoints

Service
Registry

Applications

SOAP

Servic
e
Compo
site

Business Values
Chain Activities

SERVICE ORCHESTRATION
WSDL
Service
1

Service
2

Service
3

Service
4

Service
5

Service
6

ERP

SCM

CRM

Figure 4 Proposed SOA Architecture

In the proposed architecture, the service on the left accesses the service registry to
discover another service and interacts with it by sending a message, for example
placing an order. This message is often part of a longer conversation between the
services, for example an order, followed by an acknowledgement, an invoice,
payment notice, etc. Some of these messages might be encrypted, or require
authentication. In the above figure the service provider is a composite service, i.e., a
service that uses other services to fulfill its responsibilities. For example, an order
service might need to access inventory or pricing services in order to accept an order
or issue a quote. The implementation of such a composite service is frequently
performed by an orchestration engine, an element optimized to execute a multi-step
process, which includes interactions with other services. A rules engine may be
appended in the architecture to guide the orchestration engine in the execution of the
process by incorporating business rules, such as orders over a certain amounts being
handled with priority. The endpoints manage the translation between the
asynchronous world of messaging and the synchronous, oriented-oriented application
program. Because different applications and services tend to use incompatible data
formats a translation of the message is often required along the way.

12

SCOPE OF THE STUDY

The scope of our work is to provide a reference model/framework for an

overall, integrated enterprise-wide SOA for SME to address technical values
of an organization in a holistic manner.

The work will further be realized by examining the state-of-the-art in relevant

frameworks and technologies for its development and deployment. The focus
is on providing smooth integration of diverse systems and services

By using the UML notion of middleware abstraction that can help in making
smooth SCM, CRM, BI activities, which is needed in small and large
enterprises.

RESEARCH METHODOLOGY
Following methodologies will be followed:
1. The five layer SOA architecture (see figure 5) is used to design and implement
the proposed model for current research work

Figure 5: Five layer SOA architecture

The explanation of the five layers SOA as used in s organizations is as follows:

Front End The Front End (FE) layer represents the front-end systems of the ICT
environment. Each front-end system in this scope can access one or more services
through a front-end adapter.
Front End Adapter The Front End Adapter (FEA) layer represents the services
within the scope, which offer their services to the front-end systems.

13

 Composite The Composite layer represents the services within the scope, which
combine the functionality of other services.
Back End Adapter The Back End Adapter layer represents the services within the
scope which represent the services offered by the back end systems. A FEA service
always invokes another service, either on the Composite layer or directly towards a
Back End Adapter service.
Back End The Back End layer represents the back end systems of the ICT
environment. Each back end system in this scope can be accessed by one or more
services through a back end adapter.
2. On the basis of literature survey and existing models, we identify and fill gap in our
proposed model. Secondary data for research will be collected from related books,
publication, annual reports, and records of organization under study. For the primary
data, questionnaire cum personal interview method from randomly selected managers
working at these selected organizations using SOA systems would be employed
3. Questionnaire will be prepared based on our proposed model and then the response
will be taken from industry person to evaluate it. Data will be collected through
questionnaire-cum-interview technique. Questionnaire would be pre-tested on some
of the managers and thus pre-tested questionnaire would be administered to all the
sampled respondents. Appropriate statistical methods would be applied to analyze the
data to arrive useful conclusions. SPSS packages will be used for the analysis of the
data.

14

Flow chart for Research Activity during research

Feasibility Study
Identify the need and limitation of
available solutions
Determine the alternatives

System Analysis
Activity- Determining SRS by meeting
managers/executives working in the area of
SOA
End product an SRS for the problem

System Design
Activity - indentifying the activities
/processes and interdependency among
them
End product - An Case diagram/Sequence
diagram/collaborative diagram using UML

System Testing
Activity critical success and risk factors
be identified
End product test cases for proposed
model

SOA based Framework

(Capable for providing technical
solution to SMEs)

15

PROPOSED CHAPTERISATION
Chapter
No.
1.

Chapter Title
Introduction

2.

Review of Existing Related Work

3.

Research Methodology and Profile of Organizations Under Study

4.

Design and Implementation Model for SOA Systems

5.
6.
7.

Study of the Inhibiting and Success Factors in SOA Design and

Implementation
Testing of the proposed SOA Design and Implementation Model
Conclusions and Recommendations
Bibliography
Appendices

BIBLIOGRAPHY
[1] Alaa G., (2009), Derivation of Factors Facilitating Organizational Emergence based on Complex
Adaptive Systems & Social Autopoiesis Theories, Emergence: Complexity & Organization Journal,
Vol 11 No. 1, pp. 19-34
[2]Amelia Maurizio, Louis Girolami and Peter Jones, (2007)EAI and SOA: factors and methods
influencing the integration of multiple ERP systems (in an SAP environment) to comply with the
Sarbanes-Oxley Act, Journal of Enterprise Information Management, Vol. 20, No. 1,.pp 28-36
[3]Annika Granebring and Peter Revay (2007). Service-Oriented architecture is a driver for daily
decision support. Emerald, Vol. 36, Issue 5/6, pp 622-635,
[4] A. Mukhija and M. Glinz. (2005). Runtime adaptation of applications through dynamic
recomposition of components. Proc. of 18th International Conference on Architecture of Computing
Systems, pp 99- 112
[5]Bao rong Zhong, Hong Du, Hua yun Yu, (IEEE 2008). The Research and Implementation of
Decision Support System for Oil Production Based on SOA, Second International Conference on
Genetic and Evolutionary Computing, , Pp 86 94,
[6]Boris Shishkov, Marten van Sinderen and Dick Quartel, (IEEE 2006). SOA-Driven BusinessSoftware Alignment. Proceedings of the IEEE International Conference on e-Business Engineering
(ICEBE06), Pg: 86-94

16

[7] Bieberstein, N. , (1997). Application Development as an Engineering Discipline: Revolution or

Evolution? IBM Systems Journal, Vol. 36
[8] C. Nott and M. Stockton, (March 2006), Chose an ESB Topology to Fit Your Business
Model,IBM developerWorks, IBM Corporation
http://www.ibm.com/ developerworks/webservices/library/ws-soa-esbtop/.
[9]Chen, Y., Zhou, L., & Zhang, D. (2006). Ontology- supported Web service composition: An
approach to service-oriented knowledge management in corporate financial services. Journal of
Database Management, 17(1), pp 67-84.
[10] Crawford, C., Bate, G., Cherbakov, L., Holley, K., & Tsocanos, C. (2005). Toward an on demand
service architecture. IBM Systems Journal, 44(1), pp 81-107.
[11] De Pauw, Lei, M., Pring, E., & Villard, L. (2005). Web services navigator: Visualizing the
execution of Web services. IBM Systems Journal, 44(4), pp 821-845.
[12] Duke. A, Davies, J., & Richardson, M. (2005). Enabling scalable service oriented architecture
with semantic web services .BT Technology Journal, 23(3), pp 191-201.
[13]Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development, and
extreme programming: The state of research. Journal of Data- base Management, 16(4), 80-89.
[14]Florian Irmert, Thomas Fischer, Klaus Meyer-Wegener, (ACM 2008). Runtime Adaptation in a
Service-Oriented Component Model, Proceedings of the 2008 international workshop on Software
engineering for adaptive and self-managing systems, SEAMS08 pp: 97-104,
[15] Ferguson, D., & Stockton, M. (2005). Service oriented architecture: Programming model and
product architec- ture. IBM Systems Journal, 44(4), pp 753-780.
[16]Fumiko Satoh, Shinichi Hirose, (IEEE 2008 ). Pattern-based Policy Configuration for SOA
Applications, Proceedings of the 2008 IEEE International Conference on Services Computing - Volume
1 pp 13-20
[17]George T. Heineman and William T. Councill, (June 2001). Component-Based Software
Engineering Putting the Pieces Together, Addison-Wesley, Boston, MA ,880,.
[18]G. Flurry and R. Reinitz, (September 2007). Exploring the Enterprise Service Bus, Part
2: Why the ESB is a Fundamental Part of SOA, IBM developerWorks, IBM Corporation,
http://www.ibm.com/developerworks/ library/ar-esbpat2/
[19]Hess, H. M. (2005)Aligning technology and business: Applying patterns for legacy transformation.
IBM Systems Journal, Vol. 44, 1-. http://www.research.ibm.com/journal/sj44-1.html.
[20]Jianqiang Hu, FengE Luo, Jun Li, Xin Tong, Guiping Liao, (IEEE 2008). SOA-based Enterprise
Service Bus, Proceedings of the 2008 International Symposium on Electronic Commerce and Security
ISECS, pp 536-539
[21]Jianqiang Hu, FengE Luo, Jun Li, Xin Tong, Guiping Liao, (ACM 2004). Cooperative Middleware
Specialization for Service Oriented Architectures, Proceedings of the 13th international World Wide
Web conference on Alternate track papers & posters, pp 206 215,
[22]Kostas Kontogiannis, Grace A. Lewis, Dennis B. Smith Marin Litoiu,( IEEE 2007). The Landscape
of Service-Oriented Systems: a Research Perspective, International workshop on Systems Development
in SOA Environments (SDSOA07)
[23]Lewis, G; Morris, E.; OBrien, L.; Smith, D. and Wrage, L.; (2005). SMART: The service-oriented
migration and reuse technique, Technical Report CMU/SEI-2005-TN-029, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, PA,

17

[24]Liam OBrien, Paul. Jon Gray (ACM 2008). Business Transformation to SOA: Aspects of the
Migration and Performance and QoS Issues. Proceedings of the 2nd international workshop on
Systems development in SOA environments, pp 35-40
[25] M. Keen, S. Bishop, A. Hopkins, S. Milinski (2004). Patterns: Impelmenting an SOA using an
enterprise service bus, IBM corporation, , http://www.redbooks.ibm.com/abstarcts/sg246346.html
[26]Mike P. Papazoglou Willem-Jan van den Heuvel Re (2006). Service oriented architectures:
approaches, technologies and research issues, The International Journal on Very Large Data Bases,
Volume 16 , Issue 3, pp 389-415
[27] Niemann M., Eckert J., Repp N., Steinmetz R., (AMCIS 2008). Towards a Generic Governance
Model for Service-Oriented Architectures, Proceedings of Americas Conference on Information
Systems, pp 190-205
[28]Olaf Zimmermann, Vadim Doubrovski, Jonas Grundler, Kerard Hogg (2005). Service-Oriented
Architecture and Business Process Choreography in an Order Management Scenario: Rationale,
Concepts, Lessons Learned, Conference on Object Oriented Programming Systems Languages and
Applications (OOPSL05), October 16-20, Pg 301 - 312
[29]Ravichandran T., Leong Y., Teo H., Oh L., (2007). Service-Oriented Architecture and
Organizational Integration: An Empirical Study of IT-Enabled Sustained Competitive Advantage,
Proceedings of International Conference on Information Systems, (ICIS), pp 108-122
[30]Ren M., Lyytinen K., (2008). Building Enterprise Architecture Agility and Sustenenace with SOA,
The Communications of the Association for Information Systems (CAIS), Volume 22, Article 4, pp. 7586.
[31] Ricadela, A., The dark side of SOA, information week , 2006, pp 54-58.
[32]S. Navabpour, L. Soltan Ghoraie, A. A. Malayeri, J. Chen, J. Lu, (IEEE, 2008). An Intelligent
Traveling Service Based on SOA, IEEE Congress on Services 2008- Part-I , pp 102-120
[33] Schmidt, M., Hutchinson, B., Lambros, P. (2005). Enterprise service bus : making service oriented
architecture real. IBM Systems Journal,, 44(4) , pp 781-797
[34]S.Bose, L.Walker,A.Lynch, N.Bieberestein (2005). Impact of Service Oriented Architecture on
Enterprise Systems,Organizational Structures, ans Individuals. IBM System Journal, Vol. 44, No. 4, pp
127-138
[35]Sriram Anand, Srinivas Padmanabhuni, Jai Ganesh, (2005). Perspectives on Service Oriented
Architecture, Proceedings of the 2005 IEEE International Conference on Services Computing -, IEEE
Computer Society, Volume 02, Page 17.
[36] Tewcomer E., Lomow G (2008). Understanding SOA with web services, Pearson Education,
India
[37] Vrstraete, C. (2004). Planning for the unexpected (business agility).
Engineer, Vol 83 No. 3, pp 18-21

IEEE manufacturing

[38] Wolfgang Reisig (2005). Modeling- and analysis techniques for web services and business
processes. In FMOODS, of Lecture Notes in Computer Science, volume 3535 pp 243258,.
[39] Progress Software, Why runtime governance is critical for SOA: a SOA Primer, 2005,
[40]Wabral, L., Domingue, J.. (2004). Approaches to semantic web services: an overview and
comparisons. Lecture Notes in Computer Science., Springer Volume 3053, pp 225239
[41] Walker, L. (2007). IBM business transformation enabled by service oriented architecture. IBM
systems journal, 46(4), pp 651-667.

18

[42]Z-Martin Keen, Oscar Adinolfi, Sarah Hemmings, Andrew Humphreys, Hanumanth Kanthi, and
Alasdair Nottingham: ( 2005). Patterns: SOA with an Enterprise Service Bus in WebSphere Application
Server V6. IBM Document No. SG24-6494-00
[43] Zimerman, O., Krogdahl, P and C. Gee (2004). Elements of service oriented analysis and design:
An interdisciplinary modeling approach for SOA projects. www.ibm.com/developerworks/library/wssoad l/index.html
[44] Zhang, D. (2004). Web service composition for process management in e-business. Journal of
Computer information System., 45(2), pp 83-91

19