Service Oriented Architecture

conceptual landscape

Introduction

This discussion draws extensively on published research in the past two years and supporting sources germane to current SOA issues in collation, to describe a conceptual landscape of prominent SOA concerns.

It presents conclusions from a four-part research paper of the same name to be published in the International Journal of Web Portals (IJWP) throughout 2009.

2

AbstractContemporary architectural approach is for an orchestrated, agnostic,

federated enterprise through the adoption of loosely-coupled open Service interfaces. The Service-Oriented Architecture (SOA) paradigm unifies disparate, heterogeneous technologies. It resurrects legacy technology silos with a Service ‘face-lift’ while maintaining their autonomy.

Somewhat in its infancy as standards and methodologies are evaluated and adopted, the differences between theory and praxis of SOA remain to be fully determined, predominately due to the size and complexity of the conundrum it addresses.

SOA attempts to deliver a potentially Panglossian promise of an IT infrastructure agile enough to cater for rapidly changing Business demands. It offers a panoptic vantage point for enterprise Business state and empowers the Business to define and map IT infrastructure to process.

3

Outline

• Part I – characteristics, evolution, motivation and approach

• Part II – technology: Enterprise Service Bus (ESB), semantics, REpresentational State Transfer (REST), Object Orientation (OO) and, operations and quality

• Part III – industrial contributors and case studies• Part IV – reference architectures and conceptual

model

4

Part I

5

characteristics, evolution, motivation and approach

Part I | definition

6

‘Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains’ (OASIS2006).

‘In reality, SOA is not an architecture, but an architectural pattern from which an infinite number of architectures can be derived - both good and bad’ (Lewis, Morris, Simanta & Wrage, 2007).

Part I | Zachman

7

Zachman's architecture description approach (Zachman, 1987) identifies players and their perspectives of an enterprise architecture framework.

Used to compare Software as a Service (SaaS) against SOA and describe SOA.

The hope is that the comparison will assist designers and developers make more informed architectural decisions (Lublinsky, 2008).

Part I | misconceptions

8

1. SOA provides the complete architecture for a system.

2. Legacy systems can be easily integrated into an SOA.3. SOA is all about standards and standards are all that

is needed.4. SOA is all about technology.5. The use of standards guarantees interoperability

among services in an SOA environment.6. It is easy to develop applications based on services.

Part I | misconceptions

9

7. It is easy to develop services anybody can use.8. It is easy to compose services dynamically at

runtime.9. Services can only be business services.10.Testing applications that use services is no different

from testing any other application.11.SOA can be implemented quickly.

(Lewis et al., 2007)

Part I | misconceptions

10

‘Most of the issues are current areas of research...The solutions will take time to mature’ (Lewis et al., 2007).

‘...[W]e believe SOA may be the best approach available for achieving several critical interoperability, agility, and reuse goals that are common to many organizations. However, we do believe that the difficult reality of building and managing large scale IT systems - even based on SOA - often gets lost in the understandable corporate desire for sweeping improvements and the hype of vendors’ (Lewis et al., 2007).

‘SOA is no more a silver bullet than the approaches that preceded it’ (Coatta, 2007).

Part I | success

11

1. Strong executive level sponsorship and SOA evangelist.2. Educating the business of the value of SOA.3. Established a Centre of Excellence (CoE).4. Start with well-defined business processes and scale up.5. Define completeness of work within Services.6. Quality assurance is key.7. Return on Investment (RoI) is difficult to achieve initially

and is realized over time.8. Deliver substantial business value.

(Kavis, 2008b)

Part I | mistakes

12

1. Failure to explain SOA’s business value.2. Underestimating the impact of organisational change.3. Lack of strong executive sponsorship.4. Attempting to do SOA on the cheap.5. No SOA skills on staff.6. Poor project management.7. Viewing SOA as a project instead of an architecture.8. Underestimating the complexity of SOA.9. Failure to implement and adhere to SOA governance.10. Letting the vendors drive the architecture.

(Kavis, 2008a)

Part I | keys

13

1. Instill SOA discipline in your organisation.2. Plan big but start small.3. Invest in integration infrastructure.4. Design services systematically.5. Invest in meta-data management.6. Anticipate obstacles and don't give up.

(Maurizio, Sager, Corbitt, & Girolami, 2008)

Part I | business motivation

14

1. Business Agility.2. Controlling Integration Costs.3. Business Process Visibility.4. Increased Reuse.5. Business Empowerment.

(Baer, 2008)

Part I | conclusion• SOA definitions are unifying over time and it is

becoming clearer what SOA is and what it is for. This understanding has to penetrate all echelons of the enterprise.

• SOA demands full enterprise adoption if it is to be harnessed successfully. It is a horizontal approach that transcends the bounds of traditional governance and technology silos. New supporting role types and departments need to be created (Mira Kajko-Mattsson & Smith, 2007).

15

Part I | conclusion

• The suitability of the enterprise for SOA has to be assessed fully; potentially in conflict with the need for more benchmark initiatives. Adoption and suitability are both evolutionary. (Hau, T., Ebert, N., Hochstein, A. and Brenner, W., 2008)

• Expectations need to be managed; initial ROI for traditional instance.

16

Part II

17

technology: Enterprise Service Bus (ESB), semantics, REpresentational

State Transfer (REST), Object Orientation (OO) and, operations and

quality

Part II | ESB

18

• The Enterprise Service Bus (ESB) is established as the elongated epicentre of any SOA implementation (Ortiz Jr., 2007).

• An evolutionary approach to adoption should ease the complexities of management and migration, and potential high costs with low initial Return on Investment (RoI). The probable complexity of an ESB should not be underestimated and always juxtaposed with the potential benefits (Ortiz Jr., 2007).

Part II | ESB

19

• An application for ESB is as the backbone for SOA as an integration framework for communications technology (Service-Oriented Communication (SOC) (Chou et al., 2008) and IP Multimedia Subsystems (IMS) (Khlifi & Gregoire, 2007)) for multimedia and voice offering the flexibility of enterprise wide integration.

• The complexity of this kind of utilisation requires careful consideration be made for performance, through-put and resilience. SOA implementations need to be High Performance Transaction Systems (HPTS) (Bussler, 2007).

Part II | semantics

20

• As is the modus operandi of all technological advancement; ‘make it work, then automate it’, dynamic service Discovery, Invocation and Composition (DIC) dominates current SOA technological concern with the primary candidate for resolution being semantic service annotation (Akkiraju, Goodwin, Doshi, & Roeder, 2003).

• The goal is to achieve not just syntactical interoperability but an ‘understanding’ between services (Paolucci & Sycara, 2003).

Part II | service parks

21

• While the domain bounds of interoperability can be breached by the flexibility that semantic description offers, web-wide service orchestration has trust concerns (Dushin & Newcomer, 2007).

• ‘Service Parks’ (Petrie & Bussler, 2008) in one form or other are an inevitable part of the evolution of SOA. These island service parks are of a coarser granularity more conducive to standards agreement and jurisdiction than rogue enterprises, and an appealing stepping-stone to a global service amalgamation.

Part II | intelligence

22

• There is a computational overhead associated with dynamic service synergy.

• ‘Intelligence’ requires computation. It can be enhanced with memory but which is a complex mechanism in itself.

• All these semantic and operational overheads; functional and non-functional assurance, Quality of Service (QoS) (Curbera, 2007), trust, security (be it composite hierarchical credentials or otherwise), dynamic DIC lead to a fragile, fractal structure prone to error and difficult to maintain.

Part II | OO

23

• Object-Orientation clearly provides the basis for many facets of SOA while Object-Process Methodology (OPM) (Dori, 2007) (Dori, 2006) is an expression of the structural and behavioural specialities of each.

• The historical maturation of OO and its now common mechanisms of use provide insightful parallels for SOA; Design Patterns for service identification and migration (Arcelli et al., 2008), and composition for instance (Maurizio, Sager, Corbitt, & Girolami, 2008).

Part II | web 2.0

24

• The definition of Web 2.0 is a hackneyed discussion, resolution requiring only an appeal to Sir Tim Berners-Lee who postulates it as the transition of the general user from passive recipient to active participant as he intended the World Wide Web to be. Web 3.0 (Howerton, 2007)?

• Linux kernel versioning used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases. Is this Internet version stable? A question only for Laplace's Demon.

Part II | hype

25

• No more trite techno-Utopian rhetoric or swings of hype, please (Rosen, 2008).

Part II | SOA et al

26

• Web 2.0, Web-Oriented Architecture (WOA), SOA and REST share an intersection of concerns. As pieces, they do not tessellate soundly to complete the Internet puzzle but their commonality should be exploited and appreciated for the greater good.

• Transcending siloed, isolated thinking for fluid, flexible, cohesive exchange is the dominant motivation behind every one of these approaches but is ironically, not how they themselves are being progressed (Schroth & Janner, 2007) (Howerton, 2007).

Part III

27

industrial contributors and case studies

Part III | industry

28

The Usual Suspects • Oracle (SOA Suite)• IBM• Microsoft (Windows Communication Foundation)• Sun (Java CAPS)• Tibco• SAP (NetWeaver)

Open-Source• Apache (Tuscany, Synapse, ServiceMix)• FUSE (enterprise ServiceMix)•ChainBuilder

Of Note• Fiorano• Active End Points (ActiveVOS)• SOA Trader (service marketplace)

Part III | case studies

29

• A Case Study in SOA and Re-architecture at Company ABC(Wong-Bushby, Egan, & Isaacson, 2006)

• Building a Distributed E-Healthcare System Using SOA(Kart, Moser, & Melliar-Smith, 2008)

• Service Oriented Architecture (SOA) Migration Strategy forU.S. Operational Naval Meteorology and Oceanography (METOC) (Meyer, 2007)

• A Service-Oriented Architecture for Mass Customization: AShoe Industry Case Study (Dietrich, Kirn, & Sugumaran, 2007)

Part IV

30

reference architectures and conceptual model

Part IV | conceptual model

31

OASIS SOA Conceptual Model (OASIS2006)

Part IV | Cmap

32

SOA Conceptual Map Service (Cmap)

w: youngconsulting.com.au:8081/4447

Young Consulting (Australia) / Research / SOA

CmapTools

w: cmap.ihmc.us

ContactEd Young

e: Ed.Young@youngconsulting.com.au

International Journal of Web Portals (IJWP)

w: igi-global.com/journals/details.asp?id=7829

33

thank you

ReferenceArcelli, F., Tosi, C., & Zanoni, M. (2008). Can design pattern detection be useful for legacy system migration towards soa? In Sdsoa

'08: Proceedings of the 2nd international workshop on systems development in soa environments (pp. 63-68). New York, NY, USA: ACM.

Akkiraju, R., Goodwin, R., Doshi, P., & Roeder, S. (2003). A method for semantically enhancing the service discovery capabilities of uddi.

Baer, T. (2008). Soa in any economic climate. Available from https://www.ibmsoa.com.au/paper2.cfm?paper_id=p069

Bussler, C. (2007, March). The fractal nature of web services. Computer, 40 (3), 93-95.

Chou, W., Li, L., & Liu, F. (2008, March). Web services for communication over ip. Communications Magazine, IEEE, 46 (3), 136-143.

Coatta, T. (2007). From here to there, the soa way: Soa is no more a silver bullet than the approaches which preceded it. Queue, 5 (6).

Curbera, F. (2007, Nov.). Component contracts in service-oriented architectures. Computer, 40 (11), 74-80.

Dietrich, A. J., Kirn, S., & Sugumaran, V. (2007, Feb.). A service-oriented architecture for mass customizationa shoe industry case study. Engineering Management, IEEE Transactions on, 54 (1), 190-204.

Dori, D. (2006, March). Soda: not just a drink! from an object-centered to a balanced object-process model-based enterprise systems development. Model-Based Development of Computer-Based Systems and Model-Based Methodologies for Pervasive and Embedded Software, 2006. MBD/MOMPES 2006. Fourth and Third International Workshop, 12 pp.-.

Dori, D. (2007, Oct.). Soa for services or uml for objects: Reconciliation of the battle of giants with object-process methodology. Software-Science, Technology & Engineering, 2007. SwSTE 2007. IEEE International Conference on, 147-156.

35

ReferenceDushin, F., & Newcomer, E. (2007, Sept.-Oct.). Handling multiple credentials in a heterogeneous soa environment. Security &

Privacy, IEEE, 5 (5), 80-82.

Hau, T., Ebert, N., Hochstein, A., & Brenner, W. (2008, 7-10 Jan.). Where to start with soa: Criteria for selecting soa projects. In Proc. 41st annual hawaii international conference on system sciences (pp. 314).

Howerton, J. T. (2007). Service-oriented architecture and web 2.0. IT Professional, 9 (3), 62-64.

Kavis, M. (2008a, November). 10 mistakes that cause soa to fail: Most soa failures are about people and processes, not technology. to achieve success, learn from these mistakes. Available from http://www.cio.com.au/article/253821/10 mistakes cause soa fail?eid=-154

Kart, F., Moser, L., & Melliar-Smith, P. (2008, March-April). Building a distributed e-healthcare system using soa. IT Professional, 10 (2), 24-30.

Khli, H., & Gregoire, J.-C. (2007, July). Ims for enterprises. Communications Magazine, IEEE, 45 (7), 68-75.

Lewis, G. A., Morris, E., Simanta, S., & Wrage, L. (2007). Common misconceptions about service-oriented architecture. In Proc. sixth international ieee conference on commercial-o-the-shelf (cots)-based software systems iccbss '07 (pp. 123{130).

Lublinsky, B. (2008). Dening soa as an architectural style. Available from http://www.ibm.com/developerworks/architecture/library/ar-soastyle/

Maurizio, A., Sager, J., Corbitt, G., & Girolami, L. (2008, 7{10 Jan.). Service oriented architecture: Challenges for business and academia. In Proc. 41st annual hawaii international conference on system sciences (pp. 315).

Meyer, J. F. (2007). Service oriented architecture (soa) migration strategy for u.s. operational naval meteorology and oceanography (metoc). In Proc. oceans 2007 - europe (pp. 1{6).

36

ReferenceMira Kajko-Mattsson, G. A. L., & Smith, D. B. (2007). A framework for roles for development, evolution and maintenance of soa-

based systems. International Conference on Software Engineering: Proceedings of the International Workshop on Systems Development in SOA Environments, 7.

OASIS. (2006, October). Reference model for service oriented architecture 1.0. Available from http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html

Ortiz Jr., S. (2007, April). Getting on board the enterprise service bus. Computer, 40 (4), 15-17.

Paolucci, M., & Sycara, K. (2003, Sept.-Oct.). Autonomous semantic web services. Internet Computing, IEEE, 7 (5), 34-41.

Petrie, C., & Bussler, C. (2008, May-June). The myth of open web services: The rise of the service parks. Internet Computing, IEEE, 12 (3), 96-95.

Schroth, C., & Janner, T. (2007, May-June). Web 2.0 and soa: Converging concepts enabling the internet of services. IT Professional, 9 (3), 36-41.

Wong-Bushby, I., Egan, R., & Isaacson, C. (2006, 04{07 Jan.). A case study in soa and re-architecture at company abc. In Proc. 39th annual hawaii international conference on system sciences hicss '06 (Vol. 8, pp. 179b).

Zachman, J. (1987). A framework for information systems architecture. IBM Systems J., 26 , 276-292.

37