CIAO! meeting, Antwerp
Motivation
In every university or research institute that belongs to the CIAO! Network, there will in principle be doctoral students that are supervised by a professor who belongs to the CIAO! Research Staff. In order to meet the quality standards of the CIAO! Network, these students should be guided to improve their work as much as possible. To this end the CIAO! Doctoral Consortium is constituted.
Objectives
The first objective of the CIAO! Doctoral Consortium is to encourage doctoral students to write, submit and present papers and to help them to improve the quality of the papers. The second objective is to be a platform for meeting each other as well as the members of the CIAO! Research Staff.
Organization
The CIAO! Doctoral Consortium consists of all CIAO! Doctoral Students and all members of the CIAO! Research Staff. Because of the geographical distribution of the CIAO! Network, it is practically impossible to let them meet all together. Therefore a local CIAO! Doctoral Consortium will be set up at every university or research institute that belongs to the CIAO! Network. Out of the local CIAO! Research Staff a Referee Board is selected. This board may invite persons from a CIAO! Company to be member of the Referee Board, provided (s)he has a doctoral degree. One of the members of the Referee Board is appointed to be the chair.
Mode of Operation
A local CIAO! Doctoral Consortium meets as often as is necessary to have every student present a paper once per year. At such a meeting of one full day, at most four students will present a paper. This guarantees that there is always sufficient time for discussions and for fulfilling the platform function. A presenting student has to distribute the paper (of 10-12 pages) in advance such that all members of the consortium have sufficient time to prepare for the meeting.
The MVVEIS workshop at the ICEIS conference
Yesterday and today I was at the workshop about Modelling, Simulation, Verification and Validation of Enterprise Information Systems (MVVEIS) at the International Conference on Enterprise Information Systems (ICEIS). I was here to present my paper “Comparing Methodologies for Service-Orientation using the Generic System Development”.
I especially enjoyed the keynote presentation of Jean-Marie Favre titled “Engineering the Power of Babel the Community Engineering and Software Language Engineering”. It was about software languages in a very broad meaning. When we speak about software languages we tend to focus very much on programming languages like .NET, Java, Cobol etc. Jean-Marie took quite a different approach and took into account all types of languages that have to do with software. This included, for instance LaTeX, HTML, and OWL. He also stated that languages for communicating ABOUT software (e.g. UML, Z) are software languages. In fact, he regarded all software languages as being meant for humans (which is of course true! A computer only “understands” 0010101011101101). Jean-Marie is trying to create a link between the fields of computer science and linguistics. He defines the field of software language engineering as follows: the application of a systematic, disciplined, quantifiable approach to the development, use, and maintenance of these languages.
If you’re interested, take a look at this site: http://planet-sl.org
Why BPEL is a wrong name
Looking at the name Business Process Execution Language (BPEL) one would expect that it is a language for executing business processes. In reality BPEL is a standard for service orchestration. There is a huge difference between the two.
Let me start by making clear what a business process is. Probably the first person to describe a business process was Adam Smith (1776). He described it text-based without the use of any process diagrams.
”One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”
Service interface specification is not enough
Abstracting the functionality a service offers from its implementation is the main idea of SOA. A potential service consumer does not care whether a service is written in Java, .NET, Cobol or is even performed by a human actor as long as he knows what the services does. Many people think an interface specification is enough and that UDDI is a great standard for discovering services. This is, however, not the case.
CfC: Call for Cases on Service Specification
If your organization is struggling with the question how to specify services (and how to find them!) and wants to be part of scientific research, please contact me to see if we can help each other.
My email address is:
My interests are:
- reviewing current service registry implementations (finding out the problems with existing methodologies);
- applying new methodologies to your organization (comparing them to your existing approach);
- writing papers about the case study (can be anonymous).
Let me now if you have common interests!
Ten ways to identify services
By: Jan-Willem Hubbers, Art Ligthart, Linda Terlouw
Originally published in The SOA Magazine
Abstract: SOA is increasingly becoming an unavoidable part of project delivery for many organizations. It is therefore high time that practitioners avoid the dangerous practice of creating ad-hoc services and begin following proven industry principles and methods. In this article we discuss ten approaches for identifying services. The intention is for this list to become an effective starting point for service definition, alleviating project teams from the longwinded discussions about granularity, feeling, intuition and craftsmanship that have historically been part of initial service delivery phases. This collection of methods is the result of research. Therefore, it is important to understand that even though some have become established industry practices, there are still pitfalls and trade-offs that need to be taken into consideration.
jUDDI installation
jUDDI is an open source UDDI. This tool can be used to learn the basics of UDDI, that’s why I use it as an educational tool. It is, however, less suitable for the real work. It cannot be compared to the registries of for example Systinet and IBM. This post prestents the installation procedure for jUDDI (which is not really easy).
The problem of IT (in the Netherlands?)
A complex IT system needs to be build. Two IT architects start a conversation.
“How did you become an IT architect?”, says one of them to the other.
“I studied computer science, worked as an assistant to a very experienced IT architect during several years, followed additional education each year and finally I managed to become an IT architect myself. How about you?”
