Services, SOA, SOSE and the Future

Sheikh Zeeshan Shakeel, BS (CS) University of Karachi, MS-(SPM) NU-FAST Karachi Pakistan
OMS & FIX Implementation Team Lead at MIXITTM Technologies,
[email protected], [email protected]

Abstract.
With the advent of services or web services, oriented architecture or SOA has changed the way distributed systems
used to be integrated. There has always been a need to make such IT assets which at least reusable because reusable
IT assets are what results in greater cost saving. Also, SOA make it possible what was missing for a long time, we
call it IT-business alignment. Services stand at the heart of Service oriented architecture. In this particular document
we try to answer what is service, what is SOA, Service oriented software engineering. We take a look at the benefits
of SOA with respect to different stakeholders be it business analyst or an IT professional or an enterprise. We try to
clarify the misconceptions that many people have regarding SOA. We also try to provide a brief insight upon SOA
history that is where we started from and how did we reach to SOA. There is a brief discussion on SOA life cycle as
well. Finally we talk about SOA future and to endorse our argument we try to give comments from SOA gurus from
all around the world. We believe this paper will prove to be a good resource in getting started with some solid
understanding of SOA and its related concepts.

Keywords: Web Service, Service, SOA, SOSE, Composite applications

1. Introduction

Service Oriented Architecture (SOA) is considered as an IT problem solver. Many problems exist today be it
prolonged development cycles, poor overall quality of code, inability to meet current and future business
requirements, etc. all of them can be solved by proper implementation of SOA. SOA has been around for a decade
or so, and it has made huge advances during this period of time, especially in the areas of asset reuse, integration and
security etc. A lot is being said about services, SOA and SOSE. Before we really take the insight regarding the
benefits let me first define what actually service, SOA and SOSE are all about.

1.1. Service in Service Oriented Architecture

Service-Oriented Architecture is a practice of deriving an information system design from a business design
enabling IT and business growing side by side resulting minimum time to value for the business. The business
process and the tasks from which it is composed can be collectively thought of as services. Thus, the business design
is essentially a composition of services and the policies and conditions that must be applied to their use which form
the information system design.

There are several questions come into mind when we talk about service oriented architecture. For instance, what is a
service? Is it a method within an application? Are all functions services within an application? Researchers say that
coming up with a single, mathematically precise definition that applies universally to the entire situation is
impractical, unrealistic and very difficult. It is also said that, in practice, such precision is not necessary to achieving
value and success from SOA.
The fundamental assumption in the application of SOA to information technology is the principle of loose coupling.
In general, ―a service is a repeatable or reusable task within a business process”. [8] So the set of tasks that make
up a business process are called services and the business process, therefore, can be thought of as a composition of
services.

1.2. Service Orientation and SOA

Service-orientation is a way of ―integrating business as a set of linked services”. [8] Services are defined in all the
lines of business or LOB’s. Also the business process itself is defined in terms of services. Main services are further
decomposed into basic more granular services. These services are then used to interlink LOB’s. Similarly, the same
principles of composition can be used to create links with business partners to both automate those relationships and
to gain more efficiency from them. The ultimate consequence of service orientation is flexibility: the ability to
iteratively optimize business design, unhampered by inflexible IT structures.

A Service-Oriented Architecture, then, is an architectural style for creating an Enterprise IT Architecture that
exploits the principles of service orientation, loose-coupling, integration, composite systems to achieve a tighter
relationship between the business and the information systems that support the business. It has become a de-facto
standard create enterprise wide reusable IT assets.

So far we have defined SOA in terms of business perspective. In Technically terms, SOA is a way of designing a
software system to provide services to either end-user applications or to other services through published and
discoverable Interfaces.

According to W3C’s Web Services Glossary (2004),

―SOA is a set of components which can be invoked and whose interfaces descriptions can be published and
discovered. A basis of SOA is the concept of service as a functional representation of a real-world business activity
that is meaningful to the end user and encapsulated in a software solution‖. [8]

In the last eight years, there has been significant improvement in the concepts and technologies used to build
information systems. The foundation of this evolution is Service Oriented Architecture and its tagline is
composition, i.e. the ability to build assets that can be reused in contexts even which were unknown at the time they
were designed and implemented.
1.3. Service Oriented Software Engineering or SOSE

At the heart of the SOSE paradigm is the concept of service, as well as the way to expose system capabilities to
consumers as services through the Service-Oriented Architecture (SOA). In this regard, the Web services technology
is just a way to efficiently realize the concepts of services and SOA. The service forms a contractual agreement
between provider and consumer. Service-oriented software engineering (SOSE) is concerned with theories,
principles, methods, and tools for building loosely-coupled application services that provide particular business
functionality and are distributed within and across organizational boundaries.

Building service-oriented solutions require addressing the concerns of both the service provider and the service
consumer. From the perspective of service provider, it is critically essential to determine what components of the
system can be exposed as services that offer a high business value for consumer and at the same time it should be
decoupled from the rest of the system. This decoupling is essential since it allows the services to be used anywhere
without the dependency of other system functions thereby making it a real reusable IT asset.

From the service consumer perspective, it is a fundamentally important to determine what parts of the business
functions can be completed by calling a services over the web or what parts can be done by composing an in-house
service. Balancing the needs of service provider and consumer is crucial to achieving the true benefits of service
orientation. This also increases business agility and makes inter- and intra-enterprise integration very flexible and a
dream come true.

In its true sense, Just as Software Engineering is a methodology to build software, service oriented engineering is a
kind of methodology to build large scale enterprise-wise, service-oriented, loosely-coupled systems. These
methodologies and practices yield in systems which are flexible, adaptable to quick business changing demands and
have least time-to-market.

1.4. SOA based Enterprise Architecture results in Composite Applications

SOA based Enterprise Architecture results in composite applications. A composite application is a set of related and
integrated services that support a business process built on top of SOA. Composite application can be thought of as
an application that brings together the functionality and services of related intersecting applications. For example, a
government regulatory application regarding the credit history of a person can be made. This application can bring
in the credit history of client from all the banks be it any bank in the country or even the banks outside the country
as long as the relevant services are available, his mortgage details, any loans and also the cash present in all his
accounts. This is only possible though composite applications which are purely based upon web services.
2. SOA Technology Side: What Works and What Doesn’t

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.

2.1. Technology Constraint: Technology Dependent Systems Generally Don’t Work

First and foremost, it’s a proven fact that tightly-coupled distributed systems generally do not work. The property of
being tightly-coupled leads to solutions that don’t extend and are difficult to adapt. Also they don’t 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 just to provide the capability of having reusable IT assets. In today’s fast
emerging technology world, you can’t 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 that’s 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 that’s 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.

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

2.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.
3. Actors in Service Orientation
Following are the actors involved in service orientation,
 Service Provider
The service provider is responsible for supplying service objects that implement service
functionality.
 Service Requester
The service requester is a client for a particular service.
 Service Registry
Service Registry is a repository of services which can be dynamically published and discovered.
 Service Object or Service
It’s a reusable IT asset implementing some functionality satisfying business need.

Figure 1: Actors in Service Orientation [8]

4. SOA Life Cycle

The core IT assets of any organization include the following,

 data,
 legacy applications,
 line-of-business applications and
 packaged applications

SOA 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 cycle as defined by Microsoft Corporation [9],

Figure 2: SOA life cycle as defined by Microsoft [9]

Expose

The expose phase is concerned with creating the services and taking the decisions regarding which methods or tasks
to expose as services. While creating services it needs to be taken into account whether the service should be fine-
grained or coarse-grained.

A service is a fine-grained service if there is a one-to-one mapping between the service and the business process
while it is course-grained if multiple services are required to perform a business function or process.

How the services need to be implemented it’s also a question of concern here. Whether a service is to be exposed as
a local service running on company local network or it is to be exposed over the web as web service. These and
many other relevant questions need to be answered here.
Compose

After the services have been created in expose phase of SOA life cycle, they can be combined to form more complex
services called composite services. This is done so as to take the advantage of existing services. The best part of
SOA is that services exist independently of other components or services thereby making them reusable as and when
required without the dependency of other services.

Consume

After the services have been created and composed then they must be made available for consumption by either
other IT systems or by end users. Different people can consume the service different ways. Users can consume the
composed service through a number of ways,

 Web portals,
 rich clients,
 Office business applications and
 mobile devices etc

While making the service available for consumption there are several questions that need to be asked that come
under the umbrella of SOA governance? SOA governance defines the policy regarding how the service will actually
be created? What technology to be used for service creation? Where the service will be published? Who will use the
service?
5. Programming Tools to Build SOA Solutions

Following is a brief analysis of the programming tools that are being used to build SOA solutions. This research is
with respect the size of organization or industry corresponding to the particular tool. This research was done by [10].
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. Figure 3 depicts this with
more clarity.

Figure 3: Programming Tools Used by Industry Size [10]

For more details on this research see [10]

6. Platforms to Execute SOA Solutions

Following is a brief analysis of the SOA platforms that are being used to execute SOA solutions. This research is
with respect the size of organization or industry corresponding to the particular SOA platform. This research was
done by [10]. 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 4 depicts this with more clarity.

Figure 4: SOA Platform Used by Industry Size [10]

For more details on this research see [10]

7. 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‖. [7] 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 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.

That’s how starting from multiple job’s 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.
Figure 5 shows this transition to SOA based approach as follows,

Figure 5: SOA History [7]

For more on this see [7].

8. Guidelines to SOA Implementation

Following are the guidelines from for SOA Adoption,

 Try to satisfy business needs rather than just ―doing SOA”.

 Successful SOA implementation requires adopting a hybrid approach that makes use of both top-down and
bottom-up approach. Top-down approach does not divide the problem to a right level. Although it does
take some integration issues into consideration but fails to judge individual sub-problem complexity. So it’s
not well-suited to real world. Bottom-up approaches are not manageable either. That’s why organizations
that take hybrid approach are actually able to perform successful SOA adoptions.
 Avoid ―build it and they will come‖ approach. In today’s business demands change too quickly making a
long awaited solution inappropriate to satisfy current business needs. That’s why SOA solutions are
supposed to be built incrementally rather than whole sole ―rip and replace‖ solution.
 SOA iterations should be quick enough to realize faster time-to-value. The old ―Trust me‖ approach no
longer holds. Also make sure these rapid iterations demonstrate appropriate value.
 Last but not the least; ―Snowball” approach is what is mostly desired. We start with a snowball and then
keep building it until a larger snowball is constructed. This is probably the most helpful way with respect to
leveraging SOA to drive business value.



9. SOA Benefits
9.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,

 Web,
 rich client,
 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.

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

 our existing IT services don’t adequately meet specific business needs,

 its maintenance cost is extremely high
 its change responsiveness is extremely low

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.

9.3. Aligning IT with Business

In today’s 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.
9.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.

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

9.6. Enhanced Business Decision Making

In, Today’s 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.

9.7. Greater Employee Productivity

SOA enabled solutions, allows employees gain timely access to the information they need. This greatly increases
employee productivity.

9.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.
10. SOA Perspectives
10.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.

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

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.
10.3. IT Department SOA Perspective

From the IT department’s point of view, SOA-based integration has following advantages,

 simplifies management of distributed resources across multiple platforms,

 requires less hardware,
 is more reliable,
 is standards-based and
 Is less costly.
11. SOA Misconceptions

Different people have different misconceptions regarding SOA. Following are the most common among them,

Is SOA a product that can be purchased or sold?

It’s not a product that can be purchased or sold. Just as software engineering a philosophy to build software
applications so is SOA is a design methodology to build reusable composite systems or applications.

Does SOA Implementation require a business process overhaul?

SOA does not require a complete technological and business process overhaul rather SOA solutions are incremental
and built on top of current investments.

Are SOA and Web Services just the Same?

SOA is also often equated with Web services, and the terms used interchangeably. While it is true that SOA is made
easier and more pervasive through the broad adoption of Web services, the two are different not the same thing.

SOA is an approach to designing systems—it’s a design philosophy to build reusable IT systems or composite
systems. In contrast, Web service is an implementation methodology that uses specific standards and language
protocols to execute on a SOA solution.
12. SOA in Our Local Industry

Following we see SOA as it is realized and followed in our local Pakistan’s Software Industry. While the
concept underlying SOA and its implementation is not new but our local industry is still in realization phase.

Most of the entities are trying to do SOA rather than targeting business needs, this is the most common problem with
most of the technical people. Since there is a strong desire for learning new tools and technologies that why many a
times web service implementation decision are also driven by thrust of getting hands on knowledge of new web
service technology rather than satisfying a real business need. When such an approach is followed, definitely we see
no real advantage of using SOA. According to researchers and SOA gurus, SOA decisions should be driven by
organizational need.

Also, merely composing some web services is not enough for SOA implementation. Same is true for Object
Orientation; merely creating few functions within a class does not really mean that one has really grabbed object
oriented principles. For SOA, one really needs to go through some SOA patterns and practices.
13. SOA Future in the Eyes of Industry Experts

Following are the comments of SOA gurus [13] that help us understand where SOA future is going,

13.1. Kerrie Holley, [email protected]

KERRIE HOLLEY, IBM Fellow, is CTO of IBM’s 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 we’ve 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.‖

13.2. 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 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.‖

13.3. 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
company—as 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.‖
13.4. 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.‖

For further details on the comments given by above experts see [13]
14. Conclusion
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.
15. References
1. One of the best forums for SOA learning http://www.infoq.com/soa
2. SOA for beginners http://www.ibm.com/developerworks/webservices/newto/
3. Introduction to ESB
http://www.ibm.com/developerworks/websphere/library/techarticles/0509_flurry1/0509_flurry1.html
4. Microsoft SOA FAQ’s http://www.microsoft.com/biztalk/solutions/soa/soafaq.mspx
5. Microsoft approach to SOA http://www.microsoft.com/presspass/features/2006/oct06/10-04SOA.mspx
6. SOA VS Object-Orientation http://blogs.sun.com/jag/entry/soa_buzzworld_whiplash_or_real
7. SOA as an architectural style http://www.ibm.com/developerworks/architecture/library/ar-soastyle/
8. Service-Oriented Software System Engineering: Challenges and Practices by Zoran Stojanovic and Ajantha
Dahanayake. Idea Group Inc (2005)
9. Microsoft SOA overview http://www.microsoft.com/biztalk/solutions/soa/overview.mspx
10. Web Services Vendor: Who is on the Radar Screen of IT Buyers? Exploring opportunities for today and the
Future by Carey Azzara, Chief Research Officer [email protected], www.hurwitz.com
11. IBM SOA Foundation: An Architectural Introduction and Overview version 1.0 by Rob High, Jr.SOA
Foundation, Chief Architect, Stephen Kinde,SOA Foundation, Architect, Steve Graham SOA Foundation, Architect
12. The Future of SOA: What worked, what didn’t, and where it is going from here? By Mamdouh Ibrahim
IBM, Kerrie Holley IBM, Nicolai M. Josuttis, Brenda Michelson, Dave Thomas and John deVadoss
Microsoft.
13. SOA What? Michael J. Carry BEA Systems
14. Migrating to SOA’s by way of Hybrid systems by John Hutchinson, Gerald Kotonya, James Walkerdine,
Peter Sawyer, Glen Dobson, and Victor Onditi
15. Service Oriented Architecture (SOA): A New Paradigm to implement dynamic e-business solutions by
Joseph Bih, Tayleer Junior College, email: [email protected], [email protected]
16. Scaling Down SOA to Small Businesses by Enrique Castro-Leon, Jackson He and Mark Chang Intel
Corporation.
17. Web 2.0 and SOA: Converging concepts enabling the internet of services by Christoph Schroth and Till
Janner, SAP Research CEC St. Gallen, Switzerland, [email protected]
18. Composite Software Construction by Jean-Jacques Dubray, InfoQ Enterprise Software Development Series