• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
315
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Constructing Software For Service Oriented Architecture Jean-Jacques Dubray, Ph.D. Architect [email_address] Lecture, 03/26/2004 The Pennsylvania State University The Smeal College of Business Administration
  • 2. There is a newer version of this presentation available here
    • http://www.ebpml.org/com/an_introduction_to_SOA.htm
    © attachmate 2004
  • 3. Copyright Notice
    • According to US and Worldwide Copyright laws, it is forbidden to use all or part of this presentation without a written consent of Attachmate
    • In particular, you are not allowed
      • To remove attachmate logos or the author’s name
      • Change the title of the presentation
      • Publish part or all of the presentation under your name or the name of another organization
    © attachmate 2004
  • 4. Acknowledgments
    • This presentation was reviewed and commented by
      • Jeff Schneider, CEO of OpenStorm
      • Eric Newcomer, CTO of Iona
      • Paul Brown, CEO of Fivesight
      • Ben Gaucherin, CTO of Sapient
    • I greatly appreciate their feedback
    © attachmate 2004
  • 5. Outline
    • Service Oriented Society
    • The “connected” world
    • From Component Orientation to Service Orientation
    • The Road to SOA
      • Three key concepts in software construction
    • Conclusion
    © attachmate 2004
  • 6. The Service Oriented Society Imagine if we had to do everything we need to get done by ourselves?
  • 7. From Craftsmen to Service Providers
    • Our society has become what it is today through the forces of
      • Specialization
      • Standardization
      • Scalability
    • It is now almost exclusively “service” oriented
      • Transportation
      • Telecommunication
      • Retail
      • Healthcare
      • Financial services
    © attachmate 2004
  • 8. Attributes of physical services
    • Well defined, easy-to-use, somewhat standardized interface
    • Self-contained with no visible dependencies to other services
    • (almost) Always available but idle until requests come
    • “ Provision-able”
    • Easily accessible and usable readily , no “integration” required
    • Coarse grain
    • Independent of consumer context ,
      • but a service can have a context
    • New services can be offered by combining existing services
    • Quantifiable quality of service
      • Do not compete on “What” but “How”
      • Performance/Quality
      • Cost
    © attachmate 2004
  • 9. Context, Composition and State
    • Services are most often designed to ignore the context in which they are used
      • It does not mean that services are stateless they are rather context independent !
      • This is precisely my / the definition of “loosely coupled”
        • Services can be reused in contexts not known at design time
    • Value can be created by combining, i.e. “composing” services
      • Book a trip versus book a flight, car, hotel, …
    © attachmate 2004
  • 10. Service Interfaces
    • Non proprietary
      • All service providers offer somewhat the same interface
    • Highly Polymorphic
      • Intent is enough
    • Implementation can be changed in ways that do not break all the service consumers
      • Real world services interact with thousands of consumers
      • Service providers cannot afford to “break” the context of their consumers
    © attachmate 2004
  • 11. Intents and Offers
    • Service consumer expresses “intent”
    • Service providers define “offers”
    • Sometimes a mediator will:
      • Find the best offer matching an intent
      • Advertise an offer in different ways such that it matches different intent
    • Request / Response is just a very particular case of an Intent / Offer protocol
    © attachmate 2004
  • 12. Service Orientation and Directories
    • Our society could not be “service oriented” without the “Yellow Pages”
    • Directories and addressing mechanisms are at the center of our service oriented society
    • Imagine
      • Being able to reach a service just by using longitude and latitude coordinates as an addressing mechanism?
      • Only being able to use a service if you can remember its location, phone or fax number?
    © attachmate 2004
  • 13. Service Orientation is scalable
    • Consumers can consume and combine a lot of services since they don’t have to know or “learn” how to use a service
    • Service providers can offer their services to a lot more consumers because by optimizing
      • The user interface
      • Access (Geographical, Financial, …)
      • They were able to provide the best quality of service and optimize their implementations
    © attachmate 2004
  • 14. So…
    • Service orientation allows us
      • Complete freedom to create contexts in which services are uses and combined
      • Express intent rather than specific requests
    • Our society should be a great source of inspiration to design modern enterprise systems and architectures or understand what kind of services these systems will consume or provide
    © attachmate 2004
  • 15. The connected (new) world Over the past 15 years, everything got connected to everything else
  • 16. Connectivity Drives the Emergence and Convergence of Technologies © attachmate 2004 Workflow EDI Mainframe Office ? Business Integration J2EE .NET Client / Server Web/Portal EAI B2B BPM WS 1980 1990 2000 2010 XML WS Web LAN Internet SOA
  • 17. Connectivity Enables Global Processes and Information Access © attachmate 2004 Information Business Processes Local Internet 1980 1990 2000 2010 Web XML WS WAN Web LAN LAN Global SOA
  • 18. Seamless Connectivity enables “On Demand” Computing
    • Use software as you need
    • Much lower setup time , forget about
      • Installation
      • Implementation
      • Training
      • Maintenance
    • Scalable and effective usage of resources
      • Provision
      • Billed on true usage
      • Parallelism (CPU, Storage, Bandwidth…)
    © attachmate 2004
  • 19. But Seamless Connectivity is also questioning all our beliefs…
    • An application is NOT a single system running on a single device and bounded by a single organization
    • Continuum Object … Document
    • Messages and Services
      • As opposed « distributed objects »
      • Exchanges becomes peer-to-peer
    • Asynchronous communications
    • Concurrency becomes the norm while our languages and infrastructures did not plan for it
    © attachmate 2004
  • 20. … we are reaching the point of maximum confusion
    • Federation and Collaboration
      • As opposed to « Integration »
    • Language(s)
      • Semantic (not syntactic)
      • Declarative and Model driven (not procedural)
    • Licensing and Deployment models
    © attachmate 2004
  • 21. So…
    • Today, the value is not defined as much by functionality anymore but by connectivity
      • However, we need a new programming model
    • Why SOA today?
      • We are reaching a new threshold of connectivity and computing power
    © attachmate 2004 Mainframe Client Server Web SOA
  • 22. Constructing Software In a Connected World From Components to Services
  • 23. Constructing software in the web era (J2EE, .Net, …) © attachmate 2004 App Server Client DB CCI CCI CCI ERP CRM request response Model ERP EAI b2b Internet CCI: Client Communication Interface Controller View
  • 24. Why do we Want to Move to a New Application Model Today?
    • We are moving away precisely because of connectivity
      • J2EE, for instance was designed to build 24x7 scalable web-based applications
      • Job well done
    • But this is very different from, “I now want my application to execute business logic in many other systems, often dynamically bound to me”
      • JCA (J2EE Connector Architecture) is not enough
      • EAI infrastructures are not enough
    © attachmate 2004
  • 25. A Component now Becomes a Service Running Outside the Consumer Boundaries © attachmate 2004 Consumer DB CCI CCI CCI ERP CRM Service Service Service Registry 1 register SOAP SOAP SOAP XML XML XML 3 invoke 2 Discover and/or Bind Policies
  • 26. From Components to (Web) Services
    • Requires a client library
    • Client / Server
    • Extendable
    • Stateless
    • Fast
    • Small to medium granularity
    • Loose coupling via
      • Message exchanges
      • Policies
    • Peer-to-peer
    • Composable
    • Context independent
    • Some overhead
    • Medium to coarse granularity
    © attachmate 2004
  • 27. Web Services: what is changing?
    • Loose coupling (of course)
      • Web Services don’t require a CCI (Client side Communication Interface)
        • Very few “gears” needed to consume a service
      • Web Services can accept message content they do not fully understand or support
        • XML, WSDL
      • Web services are very late bound
        • Location is independent of the invocation mechanism
        • Directories
    © attachmate 2004
  • 28. Web Services: What is Changing?
    • Peer-to-peer interactions are possible
      • Request / response is an inefficient and very limiting mode of interaction
      • As components coarsen, it is difficult to differentiate a client from a server
    © attachmate 2004
  • 29. What Happens to the Technical Services Typically Provided by an Application Server?
    • Transaction
    • Security
    • Connection pooling
    • Naming service
    • Scalability and failover
    • They become the “Service Fabric”
    © attachmate 2004
  • 30. What about the notion of “Container”? They become Service “Domains”
    • The notion of “container” shifts to the notion of “Domain Controller”
      • A domain is a collection of web services which share some commonalities like a “secure domain”
      • A container is a domain with one web service
      • Web Services do not always need a container
    • Consumers invoke the domain rather than the service directly
    • This concept does not exist in any specification…
    © attachmate 2004
  • 31. A Service Fabric can be more than a Bus with a series of Containers / Adapters © attachmate 2004 Consumer Domain Controller Reliable Messaging Process Registry Tx Registry register Discover and/or Bind Policies DB CCI CCI CCI ERP CRM NEP NEP NEP XML XML XML
  • 32. The road to SOA… © attachmate 2004 NEP NEP NEP NEP Existing business logic, often “model-oriented” Coordination logic (Tx, Process, …) Metadata driven NEP NEP NEP NEP “ Global” business logic (tax, trade, …) and data access NEP NEP NEP NEP User Interface NEPs
  • 33. Shift To A Service-Oriented Architecture
    • Function oriented
    • Build to last
    • Prolonged development cycles
    • Coordination oriented
    • Build to change
    • Incrementally built and deployed
    © attachmate 2004 From To
    • Application silos
    • Tightly coupled
    • Object oriented
    • Known implementation
    • Enterprise solutions
    • Loosely coupled
    • Message oriented
    • Abstraction
    Source: Microsoft (Modified)
  • 34. So Migrating to SOA
    • Would entail
      • Organizing the business logic in a context independent way
        • Typically, model oriented business logic is wrapped behind (web) services
    • Re-implementing the controller with “coordination” technologies
    • … The view must be completely re-invented
    © attachmate 2004
  • 35. From this point on…
    • We will focus on 3 key aspects of the controller
      • The coordination layer
      • Information Entities
      • The relationship between BPM and SOA
    © attachmate 2004
  • 36. The “Coordination” Layer
    • Many, many, many overlapping concepts not layered, not architected
      • Composition
      • Orchestration
      • Choreography
      • Collaboration
    • What is the relationship between these concepts?
    © attachmate 2004
  • 37. Coordination Specification
    • OASIS/WS-CAF
      • Context management
      • Coordination
      • Transaction management
        • As one possible, yet very important example of coordination
    © attachmate 2004
  • 38. What is Context? © attachmate 2004 S1 S2 S3 CTX Service S4 Peer to peer interactions mandate a “context” service (e.g. in this case S3 may need to know the state of interaction between S1 and S4 to provide its service)
  • 39. What is an activity Lifecycle Service? © attachmate 2004 S1 S2 S3 CTX Service S4 ALS Service ALS allow to demarcate units of work shared across several services
  • 40. What is Coordination? © attachmate 2004 S1 S2 S3 CTX Service S4 ALS Service Coordination Service
    • A coordinator is an active component
    • of the architecture
    • It can support a service or provide services itself
    • Multiple purposes:
    • Transaction
    • Orchestration
    • Choreography …
  • 41. What are the Coordination Topologies? © attachmate 2004 A B
    • Binary relationship
    • Context and Activity are most often implicit
    • Self-coordination
    Hub A B C D E F
    • Hub and Spoke relationship
    • Context and Activity are handled by the hub
    • Coordination is handled by the hub exclusively
    Coordinator CTX A B C D E F ALS
    • Multi party peer-to-peer relationship
    • Context and Activity are explicit
    • Context, ALS and Coordination are handled by the fabric
  • 42. Coordination is a key abstraction
    • Rely on generic fabric services for types of coordination
      • Not everything is a process…
    • Different types of coordination can be composed
      • A transaction may include an orchestration definition as part of an activity
      • An orchestration definition may contain several transactions
    © attachmate 2004
  • 43. Information Entity in SOA
    • “ at the heart of Web services is a very complex problem: with distributed applications comes the need for distributed data sharing”
      • Identification and equivalence
      • authentication
      • Authorization and privacy
      • mediation
      • synchronization
    © attachmate 2004 Source: The Dataweb: An Introduction to XDI, Drummond Reed et al.
  • 44. Information Entities in SOA
    • Several dimensions appear when managing an Information Aggregate in a SOA
    © attachmate 2004 Information Entity Privacy Identity Content State Location(s) Replication Specific to SOA
  • 45. Key problems to solve
    • Isolation
      • We cannot be guaranteed that the information we have is the information held by the system of record
    • Containment
      • We cannot be guaranteed that a service consumer is going to apply the same privacy rules to the information provided to it
    © attachmate 2004
  • 46. Web standards vs. Dataweb standards © attachmate 2004 URIs XRIs HTML XML/XDI HTTP XDI/HTTP XDI/SOAP 100% resource addressability Common representation and linking format Common interchange protocol Web Dataweb Source: Drummond Reed
  • 47. Websites vs. Dataweb sites © attachmate 2004 HTML Website A HTML HTML HTML HTML HTML HTML HTML HTML HTML Website B Source: Drummond Reed XDI Link contracts XML/ XDI Dataweb site A XML/ XDI XML/ XDI XML/ XDI XML/ XDI XML/ XDI XML/ XDI XML/ XDI XML/ XDI XML/ XDI Dataweb site B
  • 48. Information Elements and Aggregate Represent a Big Challenge in SOA
    • We have barely scratched the surface
    • Thinking that we can get away by saying that we are simply exchanging messages between services is IMHO a mistake
    • SOA will not exist without its concept of information entity
      • Entity beans were clearly not a good solution
      • .NET offers the concept of DataSet which I like better
    © attachmate 2004
  • 49. SOA and BPM
    • SOA is about constructing software components that can be reused in context unknown at design time
      • Composition versus Extension (OO)
    • BPM is about being able to precisely model and possibly change the context in which enterprise components are used
    • But how the two meet?
    © attachmate 2004
  • 50. Elements of BPM © attachmate 2004 Entity Activity State Event Actor Content performs Initiates changes generates Services Represented by
  • 51. How is BPM perceived today in the SOA community?
    • Two approaches
      • Event Oriented
        • BPML, BPEL
        • Pi-Calculus (Also Event Calculus)
      • Activity Oriented
        • WfMC
        • Petri nets
    • IMHO, the approaches must be combined and state must be part of the model
    • “ Turing complete” is the excuse for remaining “pure” (e.g. event oriented only)
    © attachmate 2004 Source: Paul Brown, FiveSight,
  • 52. BPEL
    • “ BPEL is an XML language for defining the composition of (web) services into (new) services” (Paul Brown, FiveSight)
    • BPEL is above all a simple Orchestration language not a Business Process Language
    • BPEL would require that every process
      • Either has a “center” of execution
      • A process is composed of a large set of orchestration definitions interacting with each other
        • In pi-calculus, even a variable is a process…
    • BPEL assumes that business processes can be fully captured in a single definition, including all possible exception paths
      • Not sure this is the right assumption
    © attachmate 2004
  • 53. A business process does not have a “center”…it is de facto “ peer-to-peer ” © attachmate 2004 OAGIS 8.1 Scenario 50
  • 54. A very simple example
    • A buyer orders some goods from a supplier
    • The supplier performs a series of steps to fulfill the order
      • Approve the order
      • Update the order entry system
      • Update the billing system
    © attachmate 2004
  • 55. Orchestration languages are a critical piece of the puzzle
    • They allow us to implement complex services which involve:
      • Long running (from a few hours to a few months),
      • And event driven business logic
    • They are not about modeling Business Processes by themselves
      • Different orchestration (i.e. different services) can run within the same business process
      • And vice versa
    © attachmate 2004
  • 56. A Business Process can be Viewed as a Multi-Party Choreography (not orchestration) of Peer Services © attachmate 2004 User Activity Buyer Supplier SFA Sales person Start ERP Order Order Information Entity Mapping Routing Quote RFQ RFQ RFQ Order Invoice Accounts Account SalesTax.com CreditCheck.com Orders Billing Invoice Sales Order Events Activity
  • 57. Services in a SOA are orchestrated (BPEL) ! This is one of the best model to re-use existing business logic © attachmate 2004 Quote Service Orchestration Definition RFQ Nack Quote Sales Tax <<send>> quote updateDB Transition Message flow RFQ Quote Ok? No sendNack Order <<invoke>> calculateSalesTax <<invoke>> GetQuote Ok? No <<receive>> RFQ Entity State Entity
  • 58. A Choreography Provides a Model of the Event Flow Between Activities © attachmate 2004
  • 59. So … © attachmate 2004
    • Orchestration
      • « … is an emerging [concept] that would give programmers a way to formally describe processes underlying business applications so that they can be exposed and linked to processes in other applications  »
    • Choreography
      • Is a concept that specifies how these processes are linked together across the enterprise
      • Choreography can be « active » when mapping and routing are necessary
    • They are both a form of Coordination
  • 60. Bringing BPM and SOA together
    • The foundation is becoming sound with strong theoretical support
      • A big piece still missing: “state” (IMHO)
      • Shift from Orchestration to Business Process Definition
    • Once the foundation is in place we should see Domain Specific Languages (DSL) appear that are a lot closer to the way the users (not the programmers) think about a Business Process
    © attachmate 2004
  • 61. A Technical Model for Constructing Software in SOA
    • We need to adapt the foundation of modern application architecture
      • Model-View-Controller
    • Model  Services
    • Controller  Coordination
    • View  ?
    © attachmate 2004
  • 62. The Model-View-Controller pattern Revisited © attachmate 2004 View Model Query UI Controller Task Engine Business Process Controller Task Request SelectTask Service Request ChangeState Controller Model Changed Model Changed SelectView WS WS WS WS
  • 63. SOA requires a Complete Separation of the Business Logic and UI © attachmate 2004 View ERP PLM CRM UI Controller Task Engine Business Process Controller Service Request WS Query Engine WS WS WS WS WS WS
  • 64. It is likely that BPM will be the main paradigm for the « Controller » in a SOA © attachmate 2004 Registry Context ALS View ERP PLM CRM Task Engine WS WS WS WS WS WS Orchestration Engine Orchestration Engine Orchestration Engine Business Process Execution Integration Server (Decoupling for B2B and EAI) WS
  • 65. Conclusion The Future Belongs to Whom Can Master Connectivity
  • 66. Service Orientation is a New Computing Paradigm
    • Not as a new name for
      • API
      • Component
    • A genuine set of concepts with which we can construct new kinds of software
      • This is as significant if not more than Object Orientation
    • In particular SO forces us to think about enabling the same piece of code to be leveraged
      • by large numbers of consumers
      • in unforeseen context
    © attachmate 2004
  • 67. SOA is still far ahead of us
    • We still need to shape what SOA means
      • I have emphasized 3 concepts but there are a lot more and a lot more not even uncovered today
      • BPM and SOA will complement each other
    • We need lots of work to achieve and deliver the SOA value and go beyond “toy” applications of SOA
      • At best we are capable of delivering web services today
    • Standards work is both a curse and a blessing
      • They open the road but blur the space and bring confusion because of the lack of … coordination
    © attachmate 2004
  • 68. We can expect
    • A new “gold rush” to own and publish application “services”
      • Mainframe and Client Server applications (ERP, CRM, SCM…) will be impacted dramatically
    • Far richer and smarter software
      • Could also become a nightmare if we look at all the security breaches that occur today
    • However, some key enabling technologies are still missing …
      • Standards “convergence” is now of primary importance
    © attachmate 2004