Thanks for your answer! This seems to really interessting.

I have researched this area for the past few months and did not find many interesting technical articles. Of course it is difficult to derive a components abstraction quite general that is at the same time representative for the diverse middleware in today's SOAs. The best two articles in my opinion are:

- Baresi, Luciano, et al. "Style-based modeling and refinement of service-oriented architectures." Software and Systems Modeling 5.2 (2006): 187-207.

- Tang, Longji, et al. "Modeling enterprise service-oriented architectural styles." Service Oriented Computing and Applications 4.2 (2010): 81-107.

Also we are studying the book

- Bahree, Amit, et al. Pro WCF: practical Microsoft SOA implementation. Apress, 2007.

which is also very helpful.

Thanks for that information!

Honestly, your statement that there are not too many articles on this topic brings me some relieve. I was questioning myself lately whether I was using the right search strategy.

Nevertheless, one of my strategies which brought at least some progress was wading through the different modeling standards in this area. Things like

- The architectural models in W3Cs Web Service Architecture (http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/)

- The Metamodel of SoaML (http://www.omg.org/spec/SoaML/1.0/Beta2/PDF/)

- The OASIS Reference Model (http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf)

- The Paper Farcas et al: “Addressing the Integration Challenge for Avionics and Automotive Systems From Components to Rich Services“ (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5433050&tag=1)

Maybe this is interesting to you, too. I’ll sure I’ll come back to you as soon as I got through these articles.

Marco

Hi,

Have a look at the Trivadis Integration Architecture Blueprint at http://www.packtpub.com/article/trivadis-integration-architecture-blueprint

Hi JF Martin,

thanks for the hint. I'll go through that!

Marco

Hi Marco,

I guess that we work in a similar area... I am developing a plataform to suport dynamic service composition based on quality of service. In fact, the kind of service composition that I am interested in is something similar to what Service Component Architecture (SCA) proposes.... In this context, I saw some interesting papers presenting how to implement such an environment using component models (e.g. fractal)...

Regards,

Fábio

Fabio and all,

I don't want to be too negative, but before starting a research project in this direction in 2013, please do a THOROUGH search of related work and critically check whether the thing you want to achieve is a significant step forward to the approximately 100 reasonable papers on QoS-based service composition that exist today. And I am not just talking about different, you need to be objectively better in something than all those existing papers. I am reviewing way too many papers that basically do the same thing all over again, using varying algorithms and background technologies.

As for the OP's question - the concrete anatomy of a SOA varies by vendor / consultant / researcher that you ask. I would expect to find at least services, clients, a message bus, facilities for service governance (monitoring), and a composition engine in the broadest sense (can be BPEL, TIBCO, or just some scripting) in any SOA. Service description is rather not a defining part of a SOA - just think of RESTful services. Discovery is, hmm, not really important in practice, I would say. Maybe the model that we had in a recent paper (actually a different topic, but does not matter) is at least some inspiration to you, even if it is probably not exactly what you want: http://www.infosys.tuwien.ac.at/staff/sd/papers/PESOS%202013%20Ph.%20Leitner%20The%20Dark%20Side.pdf

Hi Phillipp,

First of all, thank you very much for your considerations! I have been reading lots of very interesting papers that your research group has been producing along the last years (VRESCO, DAIOS, etc...) These are really nice research contributions!

Despite all the contributions in the field, I think that what I am considering is (at least, I expect it to be) a little bit different... In fact, the central part of my proposal is an infrastructure that is able to support dynamic QoS-aware service composition using dependency injection ideas.

I think of a service composition in the same way that is proposed in SCA. However, SCA itself does not address a dynamic environment, and expect that those wirings between service components are stable. On the other hand, platforms like iPojo and Spring-DM address this aspect. However, they consider basically availability as a trigger to change bindings.

What I propose is a dependency injection mechanism that is able to support other QoS aspects in order to evaluate the wiring between elements. In fact, these new qualitiy attributes could even be defined at runtime. While a composition is in execution, it is managed MAPE-K like composition manager that evaluate the bindings and eventually change them.

Well, this is the general idea... What do you think about it? Again, thank you very much for your considerations!

Best regards,

Fábio

It is an OK idea, and certainly a nice paper, but really, when you are at the beginning of your PhD (I assume you are), I suggest to think a bit 'grander' and more out of the box. What you propose is a technical combination of something that is technically mature (SCA) and something that is already well-understood in research (QoS aware composition). Sure, it can be done and it may not have been done by anybody else so far, but why is it interesting? Why would the research community care about it (for most researchers, whether you base your solution on SCA or BPEL or Windows WF or whatever is at best a sidenote, and of little relevance)?

You can use this is a starting point, but I would really suggest trying to come up with something a little more radical in the long run.

In general, that really what I am doing (combining a structural composition with QoS concerns). However, there is another ingredient: the MAPE-K loop that is embeded into the composition container.... So, I think it opens some possibilities concerning more then just monitoring and selection... I think I can also explore analysis, planning and execution policies... I know that there are some autonomous propositions as well, but I don't think that we have definitive answers in this field. So, would you mind if I elaborate a bit more about my point of view?

I have read about QoS-aware composition in both worlds, SOA and Component-based Software Development (as I believe that SCA combine ideas from both worlds)...

In SOA world, I saw nice contributions from your group, Baresi's group, Liangzhao Zeng, Benatallah & Dumas, etc... However, I believe that QoS aware composition is a very broad area. The main contributions that I saw are centered around service discovery and selection, and service monitoring techniques. Even in these areas, I feel that there is space for interesting contributions...

For example, in service selection, I think that it is possible to explore not only the QoS data per si, but also metadata related to the QoS data. For example, maybe I could consider that QoS data captured by a nearby peer would be more representative then data captured by other distant peers. Besides that, existing approaches usually use the workflow language as a valuable input in order to make an "optimum" service composition plan... On SCA based scenarios, however, things are a bit different since we don't have this flow explicitly... In that particular context, it could be possible to use "behavior specifications" in order to guide the composition process...

In the monitoring field, I saw some very interesting solutions. They usually use data from the server or client side, or from an intermediary. A part of these papers use a tradictional approach to monitoring (that is, they usually use some kind of instrumented stub that sends requests and collect data, which are stored and used it to compute metrics). Despite the relevance of the proposed solutions, just a few of them enable us to gather unforeseen QoS data really dynamically. In this context, it is usually required that I stop/start a stub (and sometimes even the entire application) in order to do so.

Other point that I consider that we don't have a definitive answer (probably because it doesn't exist) is: what should I do when the monitored data indicates that the services that I am using are not delivering the expected quality? Well, there are various possibilities here, maybe each one represented by a different policy... For example, I could just notify the consumer (and this is the usual answer, but not necesseraly the best one), but if I consider that my composition is running inside a kind of container, I could instruct this container (at high-level) to just replace the service, or keep using it, or even stop the Service Based Application. Well, I think that it would be interesting to enable different solutions (policies) out of the box.

Well, obviously, this is just my point of view... I consider that you pointed out a very important concern and that I must be careful while stating my contributions in the thesis. Please, if you have other important considerations and references let me know. Thank you for your insights again!

Regards

Fabio,

It sounds that you are looking for material that comes close to what my just graduated PhD student Toni Ruokolainen has partially worked with in some of our joint publications, although his dissertation then took a different focus.

BR