Upload
zia
View
83
Download
0
Embed Size (px)
DESCRIPTION
112 & ANTS 聯合書 報討論大會. 101 年 5 月 4 日. Topics of the day. Component based software design paradigms Service oriented computing (SOC) Service oriented component model A couple more related concepts . Topics brought up by. Titles: iPOJO : an Extensible Service-Oriented Component Framework - PowerPoint PPT Presentation
Citation preview
112 & ANTS 聯合書報討論大會101年 5月 4日
Topics of the day
• Component based software design paradigms• Service oriented computing (SOC)• Service oriented component model• A couple more related concepts
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
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
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
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
Authors• Richard S. Hall
– Visiting Assistant Professor, Tufts University– Head coach & software engineer, Sun
microsystems– Chair of the Apache Felix project, OSGi
• Humberto Cervantes– Professor, UAM-I– Software Architecture consultant, Quarksoft– Software engineering
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.
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
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
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
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
Component based architecture family
Component based
Component oriented
Service oriented
Objected oriented
Service oriented component model.Implemented by iPOJO
Component oriented approach
• Main actors:– Component developer– Application assembler
• Software artifacts:– Component– Container– External view
Component oriented approach
• Main actors:– Component developer– Application assembler
• Software artifacts:– Component– Container– External view
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
Component oriented approach
• Main actors:– Component developer– Application assembler
• Software artifacts:– Component– Container– External view
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
Component oriented approach
• Main actors:– Component developer– Application assembler
• Software artifacts:– Component– Container– External view
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
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
Component oriented approach
• Main actors:– Component developer– Application assembler
• Software artifacts:– Component– Container– External view
Component oriented approach
• Container– Provides runtime supports for a component
instance– Handle non-functional concerns
• Remote communication• Security• Persistency• Transactions• Lifecycle management
Component oriented approach
• Examples of component oriented approach in industry:– Enterprise JavaBeans– CORBA Component model
• Common Object Request Broker Architecture– Component Object Model
Component oriented approach summary
Questions?
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
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
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.
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
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
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
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
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
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
Service-oriented approach
• Main actors– Service provider– Service broker– Service consumer
• Artifacts– Service contract– Container– Service
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)
Service-oriented approach
Service Broker
Service Consumer
ServiceProvider
Service Contract
• Approach: Publish-Find-Bind
3. Bind & Invoke
1. Publication2. Find
Service-oriented approach
• Other features:– Loosing coupling– Late-binding– Handling service arrival and departure– Dynamism
Service-oriented approach
• Other features:– Loosing coupling– Late-binding– Handling service arrival and departure– Dynamism
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
Service-oriented approach
• Other features:– Loosing coupling– Late-binding– Handling service arrival and departure– Dynamism
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)
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
Service-oriented approach
• Other features:– Loosing coupling– Late-binding– Handling service arrival and departure– Dynamism
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
Service-oriented approach
– Internal changes
– Environment changes
– Contextual changes
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
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
Service-oriented approach summary
Approach comparisonComponent oriented Service oriented
Assembly done before execution Prior to or during execution
Run-time discovery and dynamic availability are not explicit assumptions(Must be done on component part instead of the framework/platform)
Dynamic is present (at least for the design)Emphasis on separation between description and implementation
Clearly distinguish between component and instance
Concept of instantiation is not considered by consumer
Packaging (delivery and deployment) is an essential activity
Does not consider delivery and deployment
Questions?
Service-oriented component model
• Introduces concepts from service orientation into a component model
• Principles– A service is a specified functionality– A service is characterized by a contract– Components implement a contract– Bindings between instances follow the SOC dynamic
interaction pattern– Compositions are described in terms of specifications– Service specifications form the basis for substitution
Service-oriented component model
• Principles– A service is a specified functionality– A service is characterized by a contract– Components implement a contract– Bindings between instances follow the SOC
dynamic interaction pattern– Compositions are described in terms of
specifications– Service specifications form the basis for
substitution
Service-oriented component model
• A service is a specified functionality– Same idea as SOC
• A service is characterized by a contract– Same idea as SOC
• Components implement a contract– Component instances provide a service
• Compositions are described in terms of contracts– Same idea as SOC– However, implementation specific service
dependency still exist
Service-oriented component model
• Principles– A service is a specified functionality– A service is characterized by a contract– Components implement a contract– Bindings between instances follow the SOC
dynamic interaction pattern– Compositions are described in terms of
specifications– Service specifications form the basis for
substitution
Service-oriented component model
• Bindings between instances follow the SOC dynamic interaction pattern– Same as SOC, Publish-Find-Bind approach is used– Enables service implementation selection at run
time• Service specifications form the basis for
substitution– Contract enables substitutability
Service-oriented component model
• How does it promote service substitutability?– Compositions are described in terms of contracts– Further strengthen by two levels of dependencies
Comment
• Mentions only advantages– How about any drawbacks?– Both paper spent only half column explaining
SOCM
Service-oriented component model
• OSGi – Open Services Gateway initiative framework– An alliance for open modular assembly of
software – That is, SOCM
Discussions
• MULE and SOCM (OSGi) ?– Interesting blog:
• http://blogs.mulesoft.org/osgi-no-thanks/– No in MULE 2.0– Good news:
• MULE 3 incorporates a new deployment model• Allows services to be commissioned and
decommissioned at runtime
Discussions
• Spring and OSGi?– Spring dynamic module– However, the purpose of this module is to help
Spring applications on OSGi framework– In PLASH, Spring is used to serve as container
• Hence not applicable
Discussions
• PLASH platform is categorized in …– Component oriented?– SOC?– SOCM?
• Combination of component oriented and SOC but not a SOCM
Discussions
• PLASH platform– Uses component to implement service
• Many to many mapping• Implementation – level specification• Contract – The component description metadata proposed
few months ago– Deploy all component prior to execution time– However, these are for services hosted by PLASH server– MULE ESB supports remote services and they can be
dynamic
Discussions
• PLASH platform– Recognizes external service via XML description
(serves like the contract in SOC)– Loosely coupled– External service can change its provider,
implementation without changing PLAH platform– However, PLASH services and underlying
components are ready for handling situation of external service departure
Questions?
Thank you