112 & ants 聯合書報討論大會 101 年 5 月 4 日. topics of the day component based...

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

http://apache-felix.18485.n6.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=343585

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


• 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


• 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


• 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


• 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


• Container– Provides runtime supports for a component

instance– Handle non-functional concerns

• Remote communication• Security• Persistency• Transactions• Lifecycle management


• 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


• 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


• 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 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 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 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 broker– Also known as service registry– Service providers register services here– Maintains and stores various service contracts– Also manages service unregistration (advanced

version)


Service Broker

Service Consumer

ServiceProvider

Service Contract

• Approach: Publish-Find-Bind

3. Bind & Invoke

1. Publication2. Find


• Other features:– Loosing coupling– Late-binding– Handling service arrival and departure– Dynamism


• 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


• 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)


• 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

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


– Internal changes

– Environment changes

– Contextual changes


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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

http://blogs.mulesoft.org/osgi-no-thanks/



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

112 & ants 聯合書報討論大會 101 年 5 月 4 日. topics of the day component based...

Documents