The document discusses evolving systems and their link to service orientation. It will cover using semantic data in a service-oriented architecture, the theory behind service orientation, and how to combine semantic data and service orientation. It will include elements of theory, technology and code examples. The presentation will be given by Angelo van der Sijpt and will explore these topics.

1. Evolving systems and
the link to service
orienta4on
What will I show?
- A case of using semantic
data
- theory behind service
orientation
- And how to marry those
Also, note that there will be
some theory, some
technology, some code
...and the search for a shorter 4tle
Angelo van der Sijpt
angelo.vandersijpt@luminis.eu
http://www.flickr.com/photos/artolog/313055444/

2. $ whoami
• Angelo van der Sijpt
• Commi?er with Apache ACE
• SoAware engineer at Luminis
Technologies
• angelo.vandersijpt@luminis.eu
• Buzzwords: Java, OSGi, Agile

3. Adaptive Recommended
Learning
Tell about ARLs vision: “we
cannot let students learn in this
way,” in which ‘s tudents’ is
interpreted broadly.
The core pattern looks about
the same for everyone; ramble
ARL about the axes of ‘institute-
personal’ and ‘s chool-work’ ; the
only differences are (mainly) in
presentation.
http://www.flickr.com/photos/shonk/57302289/

4. !"#$%&'
()##*()&)$
+ ,,,
+ ,,, !"#$$%&!'$()*"+,*!
!"##$!"%"& !"#$%&'()%*+",-."$
+ ,,,
+ ,,,
!"#$%&'()("'#&*&+)!',-

5. !"#$%&'()("'#&*&+)!',-
!"#$%&'$'()"*
!"#$%&%'(
)*+",-."/

6. !"#$%&%'(
)*+",-."/
!"#$%&'($)$%*+,
!"#$%#$
!"#$%&'()#*
)#'+,-,.
/#0-.,
!"#$%&'(

7. !"#$%&'
()##*()&)$
+ ,,,
+ ,,, -(.""&/-'"012(342-
()##*()&)$ 52#-"6%&'"012(342-
+ ,,,
+ ,,,
52#-"6%&'&2%#6*67'5%8.
9"%&'-2&2(3"6
!"#$%&%'(
)*+",-."/
!"#$%&'($)$%*+,
!"#$%#$
!"#$%&'()#*
)#'+,-,.
/#0-.,
!"#$%&'(

8. !"#$%&'
()##*()&)$
+ ,,,
+ ,,, -(.""&/-'"012(342-
()##*()&)$ 52#-"6%&'"012(342-
+ ,,,
+ ,,,
52#-"6%&'&2%#6*67'5%8.
9"%&'-2&2(3"6
!"#$%&%'(
)*+",-."/
!"#$%&'($)$%*+,
!"#$%#$
!"#$%&'()#*
)#'+,-,.
/#0-.,
!"#$%&'(

9. !"#$%&'
()##*()&)$
+ ,,,
+ ,,, -(.""&/-'"012(342-
()##*()&)$ 52#-"6%&'"012(342-
+ ,,,
+ ,,,
52#-"6%&'&2%#6*67'5%8.
9"%&'-2&2(3"6
!"#$%&%'(
)*+",-."/
!"#$%&'($)$%*+,
!"#$%#$
!"#$%&'()#*
)#'+,-,.
/#0-.,
!"#$%&'(

10. !"#$%&'
()##*()&)$
+ ,,,
+ ,,, -(.""&/-'"012(342-
()##*()&)$ 52#-"6%&'"012(342-
+ ,,,
+ ,,,
52#-"6%&'&2%#6*67'5%8.
9"%&'-2&2(3"6
!"#$%&%'(
)*+",-."/
!"#$%&'($)$%*+,
!"#$%#$
!"#$%&'()#*
)#'+,-,.
/#0-.,
!"#$%&'(

11. http://www.flickr.com/photos/jeffsmallwood/233853485

12. http://www.flickr.com/photos/jeffsmallwood/233853485

13. !"
&'( #$%
)*!
http://www.flickr.com/photos/jeffsmallwood/233853485

14. !"
&'( #$%
)*!
!"#$%&
"'()*+
http://www.flickr.com/photos/jeffsmallwood/233853485

15. !"#
!"
&'( #$%
)*!
!"#$%&
"'()*+
http://www.flickr.com/photos/jeffsmallwood/233853485

16. !"#
!"
#$
%&
'(
)"
!"
&'( #$%
)*!
!"#$%&
"'()*+
http://www.flickr.com/photos/jeffsmallwood/233853485

17. !"#
)*
!"
'(
#$
%&
%&
'(
#$
)"
!"
!"
&'( #$%
)*!
!"#$%&
"'()*+
http://www.flickr.com/photos/jeffsmallwood/233853485

18. !"#
• “Where is this student compared to his class?”
)*
!"
'(
#$
%&
%&
'(
• “What learning style do I have?”
#$
)"
!"
!"
& #$%
'()
*!
• “Who else has problems with this?”
!"#$%&
"'()*+
• “What should I do now?”
http://www.flickr.com/photos/jeffsmallwood/233853485

19. The profile service
Ramble a bit about profiling:
building a picture of a user
over time, by gathering
data. We don’t know the
questions we’re going to ask,
and we don’t know the data
we want to put in there.
http://www.flickr.com/photos/crazyneighborlady/411869140/

20. • Pluggable
• Evolvable Driven by code: we want
code usage to be leading,
supporting changes in
• Driven by code
underlying data

21. Query q = new Query()
.select(person())
.where(person().firstName(literal("Roy")));
RowSet<Row> rowSet = q.select(model);
Person roy = rowSet.iterator().next().get(person());
roy.lastName();
roy.lastName("Trenneman");

22. !"#$!%&'() 6,78%-59
:,&&2-,;,4
1.'A(B:()-%B5
6@>6$
1.'*+,-./()
0-12%3%4%)5
1.
'0
>? -1 6@>6$:()-%B5
' 2'5 2%3
-() %+
*+,-./() <%.&2)=
>78%-/3%

23. new Query().select(curriculum().label(), learningDimension(),
learningDimension().label(), achievement(),
learningdimension("sublearningdimension"))
.where(
curriculum()
.hasTopConcept(learningDimension())
.label()),
learningdimension("sublearningdimension")
.broader(learningDimension())
learningDimension()
.label(),
p.has(education()),
optional( Point out
- a more involved example
education() - better readable than Sparql
.consistsOf(achievement()), - note how we extend the Person
class here (we have defined a ‘p’
achievement() outside of this scope)
.hasAchieved(learningdimension("sublearningdimension"))),
filter("bound(" + achievement() + ")");

24. Service Orienta4on
Poll: what do you think of
when I say “SOA”?
Explain that SOA is not REST,
not web services, but an
architectural style in its
own. Manifestations from
large to small.
http://www.flickr.com/photos/camknows/4712191684

25. http://www.flickr.com/photos/camknows/4712191684

26. “A Service Oriented Architecture is comprised of
independently defined components, providing
services through agreed‐upon interfaces.
Components can in turn have dependencies on other
services.”
http://www.flickr.com/photos/camknows/4712191684

27. “A Service Oriented Architecture is comprised of
independently defined components, providing
services through agreed‐upon interfaces.
Components can in turn have dependencies on other
services.”
http://www.flickr.com/photos/camknows/4712191684

28. “A Service Oriented Architecture is comprised of
independently defined components, providing
services through agreed‐upon interfaces.
Components can in turn have dependencies on other
services.”
http://www.flickr.com/photos/camknows/4712191684

29. “A Service Oriented Architecture is comprised of
independently defined components, providing
services through agreed‐upon interfaces.
Components can in turn have dependencies on other
services.”
http://www.flickr.com/photos/camknows/4712191684

30. “A Service Oriented Architecture is comprised of
independently defined components, providing
services through agreed‐upon interfaces.
Components can in turn have dependencies on other
services.”
http://www.flickr.com/photos/camknows/4712191684

31. Service Orienta4on
• Mo4va4on
• Isola4on & decoupling
• (Coping with or causing) ' &
dynamic composi4on to ramble about:
Something
difference bet ween SOA and !"#$"#%
• Vocabulary Ser vice Orientation
• Service, component,
mandatory/op4onal
dependency • Excluded
• Rules • Discovery
• Services are self‐contained • Orchestra4on
• Interfaces are defined • Communica4on
beforehand method

32. Services aren’t big
The dependency tree
http://www.flickr.com/photos/artolog/313055444/

33. Services aren’t big
The dependency tree
http://www.flickr.com/photos/artolog/313055444/

34. TODO think up the backstory here,
how do we work in OSGi?
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

35. TODO think up the backstory here,
how do we work in OSGi?
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

36. TODO think up the backstory here,
how do we work in OSGi?
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

37. TODO think up the backstory here,
how do we work in OSGi?
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
!"#$%&'"(
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

38. TODO think up the backstory here,
how do we work in OSGi?
!"#$%&%'$
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
!"#$%&'"(
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

39. !"#$%&
TODO think up the backstory here,
how do we work in OSGi?
!"#$%&%'$
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
!"#$%&'"(
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

40. !"#$%&"
!"#$%&
TODO think up the backstory here,
how do we work in OSGi?
!"#$%&%'$
TODO how do we work in Amdatu?
Describe the notion of a ‘s ervice
component’.
!"#$%&'"(
For services to work, we need to
define how they communicate.
We can as well package that up.
Look, we invented OSGi!; now
describe the layers.

41. More on OSGi
So: we can put semantic data in
here!
• Defines a framework
• Bundles (components) are Java jar files
• Contain code, metadata, and arbitrary data
Hall
et al.
C rea tin g M odu lar
A ppl ica tio ns in J
ava
OSGi IN ACTION
Richard S. Hall
Karl Pauls
Stuart McCulloch
David Savage
FOREWORD BY PETER
KRIENS
MANNING

42. More on OSGi
So: we can put semantic data in
here!
• Defines a framework
• Bundles (components) are Java jar files
• Contain code, metadata, and arbitrary data
Hall
et al.
C rea tin g M odu lar
A ppl ica tio ns in J
ava
OSGi IN ACTION
Richard S. Hall
Karl Pauls
Stuart McCulloch
David Savage
FOREWORD BY PETER
KRIENS
MANNING

43. SOA and data

44. • Code centric
• Data never dies, but code can go
• Plugging axioms and entailments

48. • Allows (de‐)installa4on of components
• Respects the service dependency tree
• Tradeoffs
• Transform data, or pay with code complexity

49. Versioning
Semantic Versioning
• Code: we’re ge[ng there Technical Whitepaper
Revision 1.0
May 6, 2010
• Major/minor/micro
• Ontologies: version from the
start
• Closed system? Place addi4ons in © 2010 OSGi Alliance
All Rights Reserved.
same version
• Open system? Bump version on
Talk a bit about what
every change (but minimize those) ‘backwards compatibility’
means

50. In short
• Code and data can learn from each other
• Evolve code and data together
• Package them together
• Consider your versioning scheme
• Do, or don’t, worry about interchangeability

51. Evolving systems and
the link to service
orienta4on
Angelo van der Sijpt
angelo.vandersijpt@luminis.eu
http://www.flickr.com/photos/98469445@N00/327471676/