112 & ANTS 聯合書 報討論大會

1. 112 & ANTS聯合書報討論大會 101年5月4日

2. Topics of the day • Component based software design paradigms • Service oriented computing (SOC) • Service oriented component model • A couple more related concepts

3. Topics brought up by • Titles: • iPOJO: an Extensible Service-Oriented Component Framework • Autonomous Adaptation to Dynamic Availability Through a Service-Oriented Component Model Autonomous adaptation iPojo

4. Paper of the day • Title: • iPOJO: an Extensible Service-Oriented Component Framework • Published in: • 2007 IEEE International Conference on Services Computing • 2004~2007 acceptance rate: 19% • Achievements: • Become part of Apache Felix project • Cited by 80 other publications

5. Paper of the day • Title: • Autonomous Adaptation to Dynamic Availability Through a Service-Oriented Component Model • Published in: • 26th International Conference on Software Engineering (2004) • 2004 acceptance rate: 13% • Achievements : • Idea has been employed by various middlewares, platforms, and frameworks • Cited by 166 other publications

6. Authors • Clement Escoffier • PHD in software engineering, Grenoble University • Currently in Akquinet AG • Philippe Lalanda • Professor, Grenoble University • Software engineering, pervasive computing, service-oriented computing

7. Authors • Richard S. Hall • Visiting Assistant Professor, Tufts University • Head coach & software engineer, Sun microsystems • Chair of the Apache Felix project, OSGi • HumbertoCervantes • Professor, UAM-I • Software Architecture consultant, Quarksoft • Software engineering

8. References • H. Cervantes and R.S. Hall. "Autonomous Adaptation to Dynamic Availability Through a Service-Oriented Component Model", Proceedings of the International Conference on Software Engineering, May 2004. • R. Johnson, J. Hoeller, A. Arendsen, T. Risberg, and C. Sampaleanu. "Professional Java Development with the Spring Framework," Wiley Publishing, Inc., 2005.

9. Motivations • PLASH platform – Component architecture • We have rough concepts and ideas • How and what do industry and SE professionals do • Design • Implementation • Benefits and drawbacks analyzed by SE people • What advantages are there that we should have utilized but we haven’t • Issues and cautious that we should be aware of

10. Motivations • Spring framework • Deployed in PLASH platform • What are the features and advantages • Among these, what are already implemented and employed by us • What we overlooked • 8th International Workshop on Service-Oriented Applications, Integration and Collaboration • Sept 9-11

11. Topics and issues covered • Component oriented approach • Service oriented approach (SOC) • Service oriented component model • iPOJO design • Discussions with reflections on PLASH platform • Note: implementations are omitted • For those who are interested: • http://felix.apache.org/site/apache-felix-ipojo.html

12. The need of component based architecture • Avoid monolithic application • Complex, large systems providing wide-ranging functionalities • Scalability • Inter-team development • Across departments and companies • Separation of concerns • Reusability • Substitutability

13. Component based architecture family Component based Service oriented Component oriented Objected oriented Service oriented component model. Implemented by iPOJO

14. Component oriented approach • Main actors: • Component developer • Application assembler • Software artifacts: • Component • Container • External view

15. Component oriented approach • Main actors: • Component developer • Application assembler • Software artifacts: • Component • Container • External view

16. Component oriented approach • No universally agreed definition of component • Widely referenced definition: • Binary unit • Reusable building block • Similar to a class in OO languages • Can be instantiated • An instance is stateful • Contractually defined interfaces • Explicit dependencies • Independent delivery and deployment

17. Component oriented approach • Main actors: • Component developer • Application assembler • Software artifacts: • Component • Container • External view

18. Component oriented approach • Applications are built by composing (assembling) components • Applications assembler: people who compose the application • Component development and application assembly are activities that are clearly distinguished • Component developer and assemblers are usually in different organizations

19. Component oriented approach • Main actors: • Component developer • Application assembler • Software artifacts: • Component • Container • External view

20. Component oriented approach • To support composition, a component provides “external view” • External view: • External structure of its instance • Provided and required interfaces • Modifiable properties • Assembler uses this information to • Create component instance • Customize the instance • Connect various instances

21. Component oriented approach • Hierarchal composition: • When a composition is used inside another composition transparently • Usually adopts factory pattern • Instantiate an instance from a factory • Factory customizes the instance produced • Deployed along with required resources • Libraries • Images

22. Component oriented approach • Main actors: • Component developer • Application assembler • Software artifacts: • Component • Container • External view

23. Component oriented approach • Container • Provides runtime supports for a component instance • Handle non-functional concerns • Remote communication • Security • Persistency • Transactions • Lifecycle management

24. Component oriented approach • Examples of component oriented approach in industry: • Enterprise JavaBeans • CORBA Component model • Common Object Request Broker Architecture • Component Object Model

25. Component oriented approach summary

26. Questions?

27. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

28. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

29. Service-oriented approach • Shares the idea of using reusable blocks • But this reusable building block is service • An idea different from component • A service is a specified functionality • A service can be obtained from • A software unit • A system containing software and hardware entities • Remote source

30. Service-oriented approach • Design paradigm using such approach: • SOC, service oriented computing • Objective • Reduce dependencies among functionalities • Comment: • In the SOCM paper of Cervantes and Hall, hierarchical service was mentioned. By doing so functionality dependencies are established.

31. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

32. Service-oriented approach • Service contract • Service description • Contractually defines functionality • Contains combinations of syntactic, semantic and behavioral information • Used by assembler to compose the application • Published by service providers

33. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

34. Service-oriented approach • Service provider • Implements service contract • Submits service contract to service brokers • Provides services to service customers • “Introduced” by service brokers to service customers • Returns a reference to a service object to the service customer • Substitutable as long as there are other providers implementing the same contract • Does not know who and where the service consumer is • Location transparency

35. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

36. Service-oriented approach • Service consumer • Requests the service by asking the service broker • Knows how to interacts with the service as described in the contract • Must be able to handle situations where • No requested service is found • Multiple matching services are found • Does not not directly instantiate service instances. • Instead, they receive a reference from service provider • Indeed, the service consumer needs not know who and where the service provider is • Location transparency

37. Service-oriented approach • Main actors • Service provider • Service broker • Service consumer • Artifacts • Service contract • Container • Service

38. Service-oriented approach • Service broker • Also known as service registry • Service providers register services here • Maintains and stores various service contracts • Also manages service unregistration(advanced version)

39. Service Broker Service Contract Service Consumer ServiceProvider Service-oriented approach • Approach: Publish-Find-Bind 2. Find 1. Publication 3. Bind & Invoke

40. Service-oriented approach • Other features: • Loosing coupling • Late-binding • Handling service arrival and departure • Dynamism

41. Service-oriented approach • Other features: • Loosing coupling • Late-binding • Handling service arrival and departure • Dynamism

42. Service-oriented approach • Loosing coupling • Talk with contract • Consumers need not know the service implementation • Handling service arrival and departure • Notification mechanism • Concept of service lease • Service availability is only guaranteed for a period of time • Important for implementing dynamism

43. Service-oriented approach • Other features: • Loosing coupling • Late-binding • Handling service arrival and departure • Dynamism

44. Service-oriented approach • Late binding • Consumers may find services as late as during run time • In other words, service oriented assembly may occur prior or during execution • Maintains and stores various service contracts • Also manages service un-regester (advanced version)

45. Service-oriented approach • Comment • Application assembler was mentioned but was not documented as a main actor in this approach. • Loose coupling and late binding allows some freedoms for providers and consumers to find their own suitable matches, which lightens the roles of assembler • A common term for assemble – integrate • Assembly - integration

46. Service-oriented approach • Other features: • Loosing coupling • Late-binding • Handling service arrival and departure • Dynamism

47. What is Dynamism • Dynamism • Capable to deal with the dynamic impacts • Internal • Environmental • Contextual • See next slide • The application needs to support the modification of its architecture during its execution

48. Service-oriented approach • Internal changes • Environment changes • Contextual changes

49. Service-oriented approach • Resilience to dynamics • Services can be registered/unregistered to/from the service broker at any moment • Service consumers cannot rely on the same service returned by broker • Service consumers must be prepared to cope with situation when the service bound suddenly unregisters

50. Service-oriented approach • Comment • Dynamism is hard to deal with • In fact, no detailed explanation in both papers • Level of dynamism • In Escoffier’s other work, he introduced a new paradigm named dynamic SOA and distinguished it from SOA • Implying that the original SOA paradigm had no or very little support for dynamism • In Hall’s presentation of SOCM, he mentioned that dynamic service availability is only a hypothesis