Petals BPM Choregraphy

New features mainly deals with collaboration and choregraphy design which are part of BPMN 2.0 specification. A complete release note is available at http://research.petalslink.org/display/petalsbpm/PetalsBPM+v1.0-alpha-3+release+note.

There is also a deployment module which allows to deploy your workflow directly to a SOA infrastructure. This is what I explained last year during the last OW2Con conference:

1. Model your process
2. Import services from your services infrastructure with the help of the governance module
3. Create mappings between model and services
4. Deploy the ‘runtime model’ to the infrastructure
5. Run it!

So what if the services infrastructure is in the Cloud? You ‘simply’ run your business process in the Cloud, from the design phase to the runtime one.
While waiting for this all-in-cloud solution, you can start looking and trying Petals BPM directly at http://bpmneditor.ebmwebsourcing.com/ or download it at http://research.petalslink.org/display/petalsbpm/Downloads

Feel free to contact developers at http://research.petalslink.org/display/petalsbpm/Community or on the Petals Forum.

Ratatam is a small OS X application which displays your Instagram friends photo feed. It updates the feed in the background periodically and notifies you (growl-based notifications for now) when new photos are available. You can comment and like photos directly from Ratatam.
I really think that these three features are enough when having other things to do on your Mac. Just launch it, put it on your desktop like you do with Twitter, and follow your friends photo activity.

Ratatam Feed

Ratatam.App is available for download on the Mac App Store and it costs only $0.99 (0.79€).

Oh wait, I have some promo codes to give to my best Instagram contacts and to you: Tweet a link to the RatatamApp page (http://christophehamerling.com/apps/ratatamapp/) with some cool comments. Put the link to your tweet as comment on this blog post. I will get the email from the comment form and send a promo code to use on the Mac App Store to the first 10 comments.

Feel free to share this with your contacts!
@chamerling

A really (but really) simple delicious.com client for Mac OS X.

This comes from the fact that I don’t like all these browser extensions, what I just need is to bookmark some pages and then come back to them later. Let’s say that getting the last 20 pages I bookmarked is enough. So DeliceApp just provide this: Access to your last bookmarks from your OS X status bar (OK I know, QuickHubApp is already in the status bar…) and create bookmarks from your current Safari page or tab.

It is so simple that the app is available for free on the Mac App Store.

In order to get a promo code, you have to Tweet something like:

Have a look to http://wp.me/pcSx0-nn to get a free copy of QuickHubApp @github OS X client (cc @chamerling)

or something more creative which contains ‘QuickHubApp’, ‘http://quickhubapp.com’, and ‘@chamerling’.

To receive the promo code, you also have to comment this article with the reference to your tweet. Put your email address in the form so I can mail you the code directly within the next days. First ten comments will get a free version.

You are right, I need to smile more, be less tired and have a demo of the BPM editor working on low resolution displays… BTW, the demo of the DSB Monitoring & Management console used to deploy and monitor BPEL process works.

Looking back...

I did lot of things last year and to be honest I am quite tired right now, but who is not? Here are several new 2011 things:

• The Montpellier Java User Group has been launched. We did 4 sessions mostly around Google technologies: GAE, GWT and Android. We also talked about Maven and did a session on user experience. Even if I do not have enough time to allocate to the JUG, I met really nice techies who also code during nights like me.
• Some resolutions are usually to lose weight, do sport, etc. Not for me. I already do enough sport so I chose to learn something new each year. I am a Java developer since more than 8 years and I wanted to do something new in 2011. So I started to develop Cocoa stuff during nights and finally I released QuickHubApp, an OS X menulet (and more) to ease the GitHub user life.
  But Java is still here and I managed to develop things using the Play! framework. According to the wordpress.com statistics, this is a topic which always drive hundreds of readers per article to my blog.
• On the professional point of view, I now work full time on the FP7-Play research project. The goal is to create an event marketplace using many high level technologies and bringing the Petals Distributed Service Bus to the event level. Finally there is no real Cloud stuff inside, which is really sad for me.
• I still believe that Open source is really important for all the Petals products and so I gave another talk at the OW2 annual conference about SOA, Cloud and BPM.
• I also (twitter) met some cool guys, you should follow @k33g_org. Philippe we will probably not meet this year in Lyon, but maybe you should come to Montpellier and give a talk at the JUG?

So what are this year resolutions and coming things? There are many:

• Learn more new things. I think that this year will be a Ruby or a Scala one (or both).
• We have some new things to release at the JUG level: What do you think about some mobiles apps and a better and richer web site?
• QuickHubApp will continue to grow. I have so many ideas for it!
• I also have new OS X app under development, more details soon.
• This item is confidential for now, it will probably be announced within the next weeks but it will cause a real big change!

All of this previous topics will be driven by non technical nor professional constraints. This year will be the year I buy a house and we also move from three to four. ‘Pink’ Release is planned for May:

To be released in May 2012

WTF, my server is dead again!?

This app is a simple heartbeat manager looking at remote HTTP services and notifying you by email when something becomes unreachable. It uses the background Job feature of the Play framework and just does HTTP GETs on the specified list. That’s all, that’s simple, but that’s can be useful sometimes…

The code is located at https://github.com/chamerling/heartbeat-manager

So, I discussed with GitHub guys through their support channel (Here I want to say that I am really impressed on how fast and professional is the GitHub support team!). Of course, they also told me that they will never use QuickHub if OAuth is not provided. After discussions with the guys, I started to implement a workaround to provide OAuth support in QuickHub by using the OAuth Web flow and adding some stuff to QuickHub.

Let’s see how we can do that in a generic way so that you can use it in your app if needed since every serious Internet service also provide OAuth support… Note that I will not give many details about OAuth itself but I will use some terms, so have a look to OAuth documentation for more details.

Register a Web application

The first step is to register your application to the developer portal. Here you need to provide some information such as the app name and its callback URL. Even if we are developing a desktop app and not a Web one, we need to be able to provide this HTTP based callback URL. We will see in the next section what is inside this application. By registering our application, the service will generate and give us some keys to be used in the next steps, mostly to recognize us when calling the service.

Create a Web application

We need a Web application to handle callback calls from the service we want to use OAuth. This application will only be used at authorization time and just have to be able to receive the service call, get the code sent by the service, then call the service again with the code and our application keys (there is a secret one to be used here). As a result, the service will send you back your OAuth token to be used in all the future service calls. This token is used to authenticate your service calls, no more password stuff inside! Here is a quick sequence diagram showing all the exchanges between actors…

On the QuickHub side, I chose to create this Web application by using the Play Framework I already mentioned several times in this blog. I used the Heroku paas to provide the Web application publicly.

As showed in this Gist (https://gist.github.com/1466592), the callback method is really simple (as usual with Play!): just get the code and call GitHub with it and your application keys. When all lis done, just display a result page with a specific URL. Here it starts with ‘quickhubapp://oauth?’. Let’s see what it means in the next section…

Add custom URL handlers to your desktop app

Once the desktop application is authorized, our Web application redirects the user to a Web page which embeds a button targeting an URL starting by ‘quickhubapp://oauth?’. Here you already understand that by clicking on such a link must drive you to something special. The cocoa framework allows developers to register specific URL handlers for their applications. So we need to register QuickHub handlers so that OS X knows that every link  with the quickhubapp scheme must me routed to QuickHub. This is as easy as showed in this Gist https://gist.github.com/1466628.

This code snippet just tells QuickHub to invoke the getUrl method when it receives a quickhubapp event. Up to the getUrl method to handle things. In QuickHub, I just extract the OAuth token in order to persist it locally for future use.

Done!

So now we are able to use OAuth Web flows for desktop applications. In the best of the worlds, every service provider may provide a real desktop flow to be used without the need to create this additional web application. In the real world, it is not the case but as you see it can be bypassed quite easily.

I will provide more technical details on the second section ‘Create a Web application’ with real sample and code in the next weeks.

1. The DSB Manager Web application is used to manage the Distributed Service Bus. It uses the DSB Web service API to interact with node instances running somewhere…
2. The DSB Manager is used to bind business services to the DSB (let’s forget JBI, the user does not care about it…). DSB services are also exposed. Every DSB node provides the same business API with the help of the distributed endpoint registry it uses.
3. The DSB Manager uses the DSB BPEL API to deploy BPEL processes to the DSB. Up to the DSB to use the right internal endpoint when the process is executed. Services can be hosted on any node, it is the role of the DSB to route messages to the right endpoint on the right node. The BPEL process is exposed as Web service and can be invoked by any Web service client. Here I just use SOAPUI client.
4. We can monitor what happens when invoking a service! For now the DSB Manager uses Web service notification to subscribe to some monitoring topic hosted on the DSB node. When a message is exchanged between the client and the services involved in the process execution, notification are automatically published to the DSB Manager which has just subscribed. The monitoring uses Web sockets for live display in the browser…
5. Last thing is just a test to show more monitoring data when many calls are exchanged between consumers and providers.

Related articles

• Back From OW2Con 2011 (chamerling.org)
• Some Play Framework, Service Bus, WS Notification and Web Sockets… (chamerling.org)
• Let’s talk at OW2Con 2011 (chamerling.org)

We have more than 500 connectors!

Wow! Great, let’s have a look to that! What is a connector? In the Petals ESB context connectors are the bindings represented in the upper part of this well-known image

Petals ESB

So, we have almost 8 connectors. Looks that we are poor… So let’s look in details what is a Talend connector: http://www.talendforge.org/components/.

Can you see that? A Talend component is almost an operation in a service, or let’s say that it is an input/output from a data source. So a service is not as generic as a Petals service but it is a specialized service i.e. we can also have tons of ‘components’ for Petals ESB, it just means that we have to provide configuration artifacts for all the services that we find: Salesforce, Amazon EC2, S3, all the databases in the world, etc, … Oh no, wait! Don’t you see the Talend component on the bottom of the figure just above? Yes we have a Talend connector so we have 500+ components in Petals ESB

No really, Talend guys really do an incredible work and their recent press releases are really impressive. Congrats!

My son is an open source fan

So let’s go back on my talk, where I planned to show things working… Unfortunately, I was not able to show anything due to some low resolution problems and this was really a shame; next time I will prepare a video in case of something like that happens. I am going to record these videos this week to show that we have interesting things under development : We can create business processes with Petals BPM and deploy them on the service bus in order to execute and monitor the process itself in a distributed way.

While waiting these videos, here are the slides of my talk. There are sort of ‘zen’ slides so the talk I gave was really important to understand all… So come and see me next time, or just send me comments.

For the other parts of the conference, as usual, there were really interesting presentations and discussions around OW2, open source and Cloud. One fun thing which I learnt was that OW2-Jonas is used in MS Azure Cloud solution as support of J2EE apps (can I also inform that Microsoft was a big sponsor of OW2Con? Yes, really, they gave money for an open source conference, that’s fun). Well, there were so many interesting things and I can not list all here. But open source is really something companies should have a look if they do not did it already, they will be surprised to see how active and professional is the community behind it.

Related articles

• Let’s talk at OW2Con 2011 (chamerling.org)

(No this is not the vodafone/SFR icon, it is the Quickhub one… Must really find a designer, last time it looked like a FB icon).

Since I am currently working on my talk at #OW2Con 2011 (coming later this week) dealing with BPM, Services and the Cloud, I wanted to host some Web services on several places. I never had time to test Heroku but I just took this precious time today. After looking some examples, I created a Maven project template (no I do not have time to create an archetype, maybe there is one somewhere) which uses Jetty and Apache CXF to expose JAXWS annotated classes as Web services. So now, using heroku to freely expose your services is easy as:

1.  Sign up to heroku
2. Download the heroku client for your platform
3. Clone/Fork the repository at https://github.com/chamerling/heroku-cxf-jaxws
4. Add your own services
5. Login to heroku ‘heroku auth:login‘
6. Create the app on heroku ‘heroku create -s cedar‘
7. Push your services to heroku ‘git push heroku master‘. There is a git hook somewhere which just automatically compile and start your application after you pushed it.
8. Open your CXF services summary page ‘heroku open’

The resulting prototype is quite simple but works, and since I am not a front-end developer at all, it uses Twitter Bootstrap as CSS… The code is available on GitHub at https://github.com/chamerling/play-twall and is not perfect at all but just works: Twitter configuration is available in the Play! application.conf file and the Twitter connection is created in the Bootstrap…

Looks like I should start creation sort of “Coding a nice thing in one hour” collection…

So, here we are! QuickHub has been finally validated by Apple and I have chosen to try to sell it at the lowest possible price ($0.99).

The first version of QuickHub stands in the OS X status bar and allows you to directly access to :
- Your Repositories
- Your Organizations/repositories
- Your Issues
- Your Gists

It also notifies you using Growl when something changes on the previously mentioned items. For now clicking a menu item opens in your browser. It is quite simple but it was really the first idea to provide something which can quickly allows you to access your GitHub stuff.

While Apple reviewed QuickHub, I started to add some features to it. The 1.1 version will allows you to do more things (hopefully), and especially to create gists directly from QuickHub, preview some artifacts and have more better user experience with some better interface… I hope to publish it in the next days.

For now, any feedback is appreciated. You can comment here, on my personal twitter @chamerling or on the official QuickHub one @quickhubapp. Share it with your friends/co workers/followers and let’s see what happens. You can directly access to the Mac App store or have a look to the QuickHub Web site.

Christophe

We showed several things to the European Commission reviewers and we were also able to show an early prototype (this one was originally planned to be show at mid project ie in 6 months…). I made a video capture of the demo, which really needs to be explained…

• There is the idea of a market place for events : The event marketplace. From there users are able to subscribe to things they are interested in. For now it is just a simple Web application which subscribe on behalf of the user to events through topics. This subscription is sent to the Play paltform using Web standards. Here we use OASIS Web service Notification to create this communication link.
• Events are collected from several sources by events adapters. In the video above, we can see the user setting this FB status which is collected by the Play system and transformed into a notification which is published to the platform. There are also some Twitter adapters and Pachube ones which collects data in real time and publish them to the platform. This time again, we use Web standards for adapters communication.
• Now, what happens in the video? The user logs in to event marketplace and subscribes to FB events. The user then publishes something to its FB wall (note that it is not mandatory to have the same user in the event marketplace and in FB. A user can subscribe to FB events and receive events from all the FB statuses collected from the FB application users). After the event propagation delay, the event marketplace display the event to the user.

So do we need such machinery to do things like that? No, if you want to do some other simple mashup portal. There are several components which are under active development: Storage and processing. Yes we store all events in the Play platform. This storage will be huge, but it is one of the project goal: Providing efficient and elastic storage in some P2P way. The need for this storage comes with the other important aspect of the project: Complex Event Processing. We will soon be able to create complex rules on top of events and be able to generate notifications based on past and real time notifications because we have efficient storage and real time stuff inside the platform. I am not an expert of this domain, so I can not give more details about that point but capabilities are huge! For example, we can express something like “Hey Play, can you send me a SMS me when there is my favorite punk rock band playing just around and I am not on a business trip and X and !Y or Z”. All of this intelligence coming from the processing of various sources I push since months in the platform coming from Twitter, FB, last.fm and other data providers.

Now let’s take some time to work on my OW2Con talk. The session name is pretty cool : Open Cloud Summit Session.

Il s’en est passé des choses depuis mon arrivée, tellement que je ne peux pas tout citer… 5 ans que je travaille sur Petals ESB à divers niveaux. Je suis passé par beaucoup d’étapes: développement, mise en place des outils, tentative de gestion de l’équipe, architecture, support, POCs, conseil, poseur de rustines, procréateur …
5 ans après, je développe toujours. J’ai bientôt 33 ans, je ne suis pas chef et j’en suis très content: Je gère mon projet recherche dans lequel je hacke Petals ESB tout les jours pour fournir Petals DSB; je m’amuse à faire du Cloud; je participe à l’aventure open source à travers le consortium OW2; je rencontre des gens passionnés par ce qu’ils font régulièrement; je code!

Bref, bon anniversaire à moi. Pour les collègues Toulousains, la prochaine fois que je viens c’est bien sur apéro.

All this stuff has been developed focusing on extensibility and easier development. This is mainly because the ESB can be hard to extend for newbies, there are so many things inside… Today the DSB is not only a Distributed Service Bus, it is also a framework so that developers can easily extend the DSB without the need to know how it works inside. Some examples? Want to expose a kernel service : Add the JAXWS @WebService annotation. Want to subscribe to Web service notifications : Annotate you Java method with @Notify. Want to be notified about new endpoints : Add the @RegistryListener annotation. That’s all, you do not have to search for the Web service server to expose your service, nor read all the WSN documentation to receive notifications, … Simple, efficient.

There are other things you can do, mostly all is detailed in the DSB page.

While last year I spoke about some conceptual things around the Distributed Service Bus and the Cloud, this year I will go one step further with some live demonstrations not only dealing with service bus stuff, but also with some BPM tools and the Cloud stack we actively develop in the research team at PetalsLink. Here is my talk proposal:

All the services are moving to the Cloud, so are business processes. In this talk, we will show how to create collaborative business processes using an open source SaaS BPMN Editor. But designing business processes is not enough, why not running them in the Cloud? We will see that we can rely on a completely Cloud-aware SOA software infrastructure combining several open sources solutions such as a Service Bus and IaaS framework. The resulting ‘Cloud Service Bus’ allows the integration of in-house services in order to benefit from Cloud-based features such as elasticity, load balancing, service clustering and migration. This Cloud Service Bus will serve as the runtime basis of the business processes producing a Petals Cloud Stack solution. All in the Cloud, all open source!

I really hope to have time to work on some cool things to add more foggy-cloudy stuff and have things running on a real cloud infrastructure. I have many ideas in my mind these days and it is really really really cool.

Oh and I will also talk a bit about what we are currently building in the Play FP7 project. We have to show things in two weeks at the European Commission and these things are really interesting to share with OW2 attendees and staff.

BTW, I think that there is some free beer social event this year at OW2Con, see you there of course!

1. Lancer Quicktime Player (fournit avec tout Mac)
2. Fichier>Nouvel Enregistrement de l’écran
3. Enregistrer
4. Il n’y a pas de 4

This time, let’s go one step further. We have a Service Bus which is Web service notification enabled like last time. We can bind services to the bus, expose service endpoints as Web services, blahblahblah… But, this time, I am interested on having some real time monitoring of service invocations. It means that each time a message goes through the service bus (a service invocation in fact), I want to know (almmost) immediatly the service response time.
Hopefuly, the PetalsLink Distributed Service Bus I develop and use provides many extension points. One is the capability to add modules to the routing engine ie the software module each message must be able to go through on service request and response. So adding some router module which catch all the messages, timestamp them and then send this monitoring data to someone is quite easy. At the implementation level, this monitoring router module publishes monitoring reports to the service bus notification engine topic dedicated to monitoring stuff.

So, a client interested in monitoring data just has to register itself as subscriber to the monitoring notification topic. Every time a message is published in the topic, it will be delivered to all the subscribers. Up to the subscriber to display data as soon as it can. This is where Play, Web sockets and some cool javascript library came in. Since I never developed javascript stuff, I tried to find an easy to integrate solution to create some moving plots, asking twitter. I finally found the Smoothie Chart library which is really easy to use and updates graph in real time.

The high level architecture of the system can be defined as

The following video shows the result of the complete stack: Each time a message a service is invoked with SOAPUI, a Web service notification is sent to a Play application which subscribed to the monitoring topic, the Play application then pushes the data to the client by using a Web socket. Finally, the javascript code on the client side feeds the Smoothie chart which updates automatically. At the end, it is quite simple and efficient.

Oh, I forgot to say something: This took me 2 or 3 hours to create all this stuff… The code has been published on github in the dsbmanager-webapp project.

Martin Delemotte, CTO chez Kazelys (et accessoirement membre fondateur du JUG Montpellier), société qui édite Vadequa, est venu parler de sa grosse expérience avec GAE devant 80 personnes (oui ça grossit petit à petit!). Présentation des principaux services, contraintes fortes de la plateforme, astuces et conseils étaient au menu de cette soirée pleine d’échange avec le public intéressé. Les questions fusent, les réponses sont claires, parfois simples (ou pas) : “Ca, ça ne va pas être possible…, mais nous allons voir comment faire autrement”.

Il est clair que la majorité des personnes ont été refroidies par les contraintes de la plateforme, mais il est évident que ces contraintes qui sont introduites par le maitre du monde – Google de sont petit nom, sont bénéfiques intellectuellement parlant pour le développeur en question. Il est aussi clair qu’il faut bien réfléchir avant de se lancer dans le développement d’une solution reposant sur GAE. Le simple test bidon que tout le monde a pu faire depuis que GAE est là n’est bien sûr pas suffisant pour se donner un avis sur la plateforme. Sortir de GAE n’est aussi pas si simple, pour peu que l’on ai pas bien désigné son application (oui il faut wrapper, ne pas être dépendant directement des APIs, ne pas utiliser de service spécifique que seul Google fournit, …). Bref, que des points techniquement et intellectuellement intéressants.

Chaque seconde, une machine meurt dans le Cloud

Martin Delemotte – 28 sept 2011

Les slides de la session seront bientôt disponibles sur le site, en attendant quelques photos pas trop floues…

Prochaine soirée dans deux mois sur HTML5, CSS3 et UX. Le mois prochain, on laisse la place à l’Agile Tour…

Yet another ‘nightly project’ (thanks to current house build project and the lack of sleep it brings). This time I needed to be able to manage the so-famous Service Bus from some Web enabled tooling. I already developed such tool in a research project but the fact is that the licence of some libraries are not compatible with the petalslink open source approach. The second thing is that it is GWT based (which bores me, has almost 100 libraries dependencies and takes 10 minutes to compile). So this application is a good candidate to compare development productivity between GWT and the Play Framework. Here is a summary of the application creation:

• I bootstraped the application yesterday during lunch between 1PM and 2PM. I was already able to invoke most of the interesting service bus actions with the help of service bus SOAP API.
• I added some pages and actions last night, let say that since it was between 11PM and 1AM I was not very productive…
• I fixed some bugs this morning

As a result, I think I worked around 3 hours on this application. I think I spent one hour to resolve a dependency conflict between Play and a CXF dependency but as a result I have a good result which is almost equivalent in functionality to the GWT based application. I still miss some operations but I do not need them for now… I feel ashamed to say how long it tooks me to create the GWT version…

Deploy

Let’s talk about deployment… I did not have time to play with heroku to push this application in the cloud. Tis will be a future step but since I use Play and git, I am able to push the code to github and then pull it on an OVH server I rent. I am able to provide this instance for some project partners if they want to manage the service bus. The time it took? 5 minutes (wget play, git clone and play start…).

Code

The Play enabled application is available on github at chamerling/dsbmanager-webapp.

In the previous post I was introducing some tests I did with Play Framework and Web sockets. To summarize, it was just ‘about’ receiving messages on the Play! application and pushing them to the browser. This time, let’s go one step forward: Let’s add some infrastructure stuff to do something more real…

In the current case, I want to introduce a service bus which allows to create a real integration between service consumers and producers (I need to write another article in response to this nice videocast about integration from Zenexity guys ‘EAI & ESB n’apportent rien si les applications ne sont pas intégrables et interopérables’, but I really need more time to explain my thoughs…).
Using a service bus in the current case (and not for this case in fact…) must bring some added value. Here I choose to show that a service bus, even if it is not so lightweight at all, can provide some real cool features that you can have out of the box. Now, let’s add some event stuff to switch to an event-based world where we can have tons of event producers and let’s say thousands of event consumers. Since I can not setup such hude amount of actors, let’s say that we have one event producer and two event consumers:

• The event producer wants to publish some stuff somewhere. To illustrate, let’s say that we have a weather sensor connected to our platform.
• The platform provides a list of topics which producers can use to publish data. One is the weather topic which will be used by the producer above.
• The event consumers want to be notified on new weather data i.e. as soon as the weather sensor publish new data. To keep it simple, they need to subscribe to the weather topic provided by the platform.

To recap, in the event context, the event producer only knows the service he has to push weather data to, the event consumers just have to subscribe to a topic they are interested in. All the knowledge stuff about producers, consumers, topics and all the mapping is delgated at the service bus level. Yes, true it is exactly like in some topic-based messaging stuff because at the end of the day, it is topic-based messaging stuff…

The Stuff

Now we can speak about the stuff we are going to use in the software point of view for notificaiton actors…

• The event producer will not be a sensor but a Play! application. The application sends Web service notifications message to the service bus on a given topic.
• The service bus is (of course) the Petals Distributed Service Bus with some Web service notification modules inside.
• The event consumers are 1/A Play! application exposing a Web service to receive notification it subscribes to and 2/ A local java application displaying OS X notifications using Growl (let’s use JavaGrowl I published some days ago…). Note that the Play! application which have subscribed to notifications pushes them to their clients (browsers) using the funky Websocket stuff.

Let’s look at what really happens in a short video:

• I use the Play! powered application play-soap-wsnclient to subscribe to notification on behalf of the play-soap-websocket Web application.
• In Eclipse, I start a Web service notification powered Web service which subscribes to the same notification topic. Its listener is configured to use JavaGrowl to display incoming notifications.
• I use play-soap-wsnclient to send notification messages to the notification service hosted on the service bus.
• Once received, the service bus forwards the notification to all the subscribers using internal routing and WSN stuff.
• The play-soap-websocket Web application receives a notification and push it to the client browser using Websocket.
• At the same time, the Java application also receives a notification and display it using Growl.

One (or more) step(s) further…

And what if we have something which is not a Web service which subscribes to notifications? With the help of a service bus like Petals ESB/DSB, we just have to add a component which knows how to speak with the subscriber. For example, let’s say that SOAP is bad and that REST is the best thing ever. Can we have REST services receiving notifications? Yes, we can! Let’s just add the REST connector to the service bus. Another protocol/transport/format? Develop and add the new one. This is where the service bus can also help you. Hopefully, there are also other things which are possible with a service bus, we will see it later in other posts if I have time (as usual): Let’s think about business processes, service orchestration, transformation…
Next time we will have a look on what we can do if we use the distributed feature of the service bus, for example, receiving some notifications on one node and be able to notify subscribers which are bound to other nodes…

Source Code

• The event producer Play! application is on GitHub at play-soap-wsnclient
• The event consumer Play! application is also on GitHub at play-soap-websockets
• The Distributed Service Bus is not on GitHub but is open sourced on PetalsLinkLabs

The result is really amazing: We can simply push these SOAP messages to clients in less than 100 lines of code. There are some problems with some messages lost due to some conception problems but which are not Play ones. In fact, the current prototype just send the messages to all the clients but what should be done is creating streams per client with some ID to identify them…

The source code is available on GitHub at [https://github.com/chamerling/play-soap-websockets](https://github.com/chamerling/play-soap-websockets)

A quick screen capture with SOAPUI sending messages to the Play! SOAP service. The Play application pushes the SOAP message to the clients (Two browsers).

While Petals ESB does not provide any solution to invoke services directly from the kernel/component Java code, the DSB now provides a solution for that… By using this DSB feature, we can really use the power of service oriented architecture directly in our code. No more direct calls to services, you just need to call the client and say which service you want to invoke. The service bus will resolve the endpoint and route the message to the right place by using the right way/path. By using this way, you do not have to care if you need to speak with a SOAP service, a JMS queue or a REST service: Just call the service, the DSB will do the rest.

Now some code…

So, let’s have a look on the client code and first, let’s imagine that you have a web service which is bound to the service bus. Once bound, a DSB endpoint is available inside the DSB, and all messages which are sent to this endpoint will be forwarded to the final web service. One basic approach is to create a web service hosted by the service bus which ‘consumes’ the DSB service. As a result, a SOAP message sent to the DSB web service will be forwarded to the DSB endpoint which will forward it again to the final web service. Allright, but this is just for external SOAP clients and it is impossible to invoke anything firectly from the service bus kernel.
Now, let’s call the DSB endpoint from Java code… To put ourselves in a **real** case, let say that you are DSB kernel developer and that you want to say hello to the world (oh s*** really?) by using the *HelloWorldService* which is bound to the bus. Let’s code this client:

https://gist.github.com/1186183

So, just get a *org.petalslink.dsb.service.client.Client* from the *org.petalslink.dsb.service.client.ClientFactory* factory, create your *org.petalslink.dsb.service.client.Message* and send it by using the *sendReceive* method. That’s all… Let’s try to clarify what it means with a simple schema:

Hacker inside!

It looks so simple… I just deeply hacked the petals service bus kernel to provide such a thing. Why? Because the service bus is also deeply based on the JBI specification: Creating a client means that the client need to be able to receive responses and acts itself as a service on the service bus point of view. It is also built using all the component context stuff. No component context means no way to send/receive messages (component contexts are just created when JBI components are installed).
So it is really important to release the client when you do not use it anymore: There are tons of listeners and threads in the different layers which are just used to receive messages. If you do not release the client, there will be unused resources for a long time.

This is a really nice tool and not only one other fashion tool. There are tons of interesting features and thousands mature and interesting projects are already there.

I remember a discussion almost one year ago where someone in my company was saying that git was not ready for industry. To be honest, I was not using git at this moment and did not have time to look at it, so my opinion was… no opinion. But what I can say today is that, after some months of use and with all the work GitHub guys did and with all the projects which migrated to this platform, it is probably more than ready to be widely used by all (not only GitHub, but git too).

So to come back to the main goal of this article, I was asking on twitter some days ago, what is the best tool to use to publish GitHub gists?

Vous utilisez quoi comme client pour faire vos gist@github sur OSX?—
Christophe Hamerling (@chamerling) August 17, 2011

Even if I got some retweets, I did not have any answers (probably since I do not have any impact on Twitter or maybe my followers are not GitHub users…). So I asked it to GitHub and the first answer is just what I need: A command line tool written in Ruby (which is published by the GitHub CEO itself) and which is named gist. Using it is sooooo simple, just launch your terminal (I still use it everyday for many things) and the gist command will do the rest. As a result, you will get the gist link you can send to your peers. Sharing a gist just take 3 seconds…
And you what are you using to gist? or even are you using Git?

(Tout le code source de cet article est disponible sur Github : http://github.com/chamerling/chamerling.org-samples/tree/master/cxf-serviceprovider-072011)

Une première solution simple est d’implémenter javax.xml.ws.Provider, de rajouter deux/trois annotations et le tour est quasiment joué:

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;

/**
* @author chamerling
*
*/
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

/*
* (non-Javadoc)
*
* @see javax.xml.ws.Provider#invoke(java.lang.Object)
*/
@Override
public SOAPMessage invoke(SOAPMessage in) {
return null;
}
}

Reste à l’exposer avec CXF en utilisant org.apache.cxf.jaxws.JaxWsServerFactoryBean. Cette approche simpliste a le mérite de marcher, il ne reste plus qu’a manipuler les SOAPMessage dans l’implémentation de la méthode invoke.

Besoin de l’opération qui est appelée? Ajoutons javax.xml.ws.WebServiceContext en tant que javax.annotation.Resource. Ce contexte sera automatiquement rempli pour nous par CXF et accessible dans le corps de la méthode invoke. Par exemple, on peut travailler de la sorte:

/**
 *
 */
package org.chamerling.blog.cxf.serviceprovider;

import javax.annotation.Resource;
import javax.xml.namespace.QName;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.WebServiceProvider;
import javax.xml.ws.handler.MessageContext;

/**
 * @author chamerling
 *
 */
@WebServiceProvider
@ServiceMode(value = javax.xml.ws.Service.Mode.MESSAGE)
public class SimpleServiceProvider implements Provider {

	@Resource
	WebServiceContext wsContext;

	/*
	 * (non-Javadoc)
	 *
	 * @see javax.xml.ws.Provider#invoke(java.lang.Object)
	 */
	@Override
	public SOAPMessage invoke(SOAPMessage in) {
		System.out.println("Operation : " + getOperation());
		System.out.println("Message In :");
		try {
			in.writeTo(System.out);
		} catch (Exception e) {
			// bad
		}
		System.out.println();
		return null;
	}

	private QName getOperation() {
		QName result = null;
		if (wsContext != null && wsContext.getMessageContext() != null) {
			Object o = wsContext.getMessageContext().get(
					MessageContext.WSDL_OPERATION);
			if (o != null && o instanceof QName) {
				result = (QName) o;
			}
		}
		return result;
	}
}

Et invoquer le service:

package org.chamerling.blog.cxf.serviceprovider;

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.apache.cxf.jaxws.JaxWsServerFactoryBean;

import junit.framework.TestCase;

/**
 * @author chamerling
 *
 */
public class SimpleServiceTest extends TestCase {

	public void testExpose() throws Exception {
		String url = "http://localhost:9999/foo/bar/SimpleService";
		final JaxWsServerFactoryBean ssf = new JaxWsServerFactoryBean();
		ssf.setAddress(url);
		ssf.setServiceBean(new SimpleServiceProvider());
		ssf.create();

		HelloService client = getClient(url);
		client.sayHello("Rock N Roll!");
	}

	/**
	 * @param url
	 * @return
	 */
	private HelloService getClient(String url) {
		JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
		factory.setAddress(url);
		factory.setServiceClass(HelloService.class);
		Object client = factory.create();
		return HelloService.class.cast(client);
	}
}

Dans ce cas, on a une opération affichée qui est {http://serviceprovider.cxf.blog.chamerling.org/}invoke et le message SOAP

Rock N Roll!

Pas très convaincant pour l’opération avec cette approche… Le mieux est de pousser un peu plus loin et partir du contrat de service (WSDL) de notre Provider. CXF permet de le spécifier via ses factories lors de la construction du service. Cette utilisation plus avancée est détaillée en partant de org.chamerling.blog.cxf.serviceprovider.CXFExposer. L’approche utilisée dans CXFExposer permet aussi de cacher toute la tambouille JAXWS à l’utilisateur, au final il a besoin d’implementer seulement org.chamerling.blog.cxf.serviceprovider.Service

package org.chamerling.blog.cxf.serviceprovider;

import javax.xml.namespace.QName;

import org.w3c.dom.Document;

/**
 * @author chamerling
 *
 */
public interface Service {

    /**
     * Get the WSDL description
     *
     * @return
     */
    String getWSDLURL();

    /**
     * Get the service URL ie where to publish it...
     *
     * @return
     */
    String getURL();

    QName getEndpoint();

    QName getInterface();

    QName getService();

    /**
     * Invoke the service
     *
     * @param request
     * @param action
     */
    Document invoke(Document in, QName operation) throws ServiceException;

}

Petals BPM (previously Geasy BPMN Editor) is an open source, web-based BPMN 2.0 editor developped with GWT.

Petals BPM

Tout est dit en une seule phrase… Petals BPM est un des produits que nous sommes en train de développer activement au Labs. Cette Web application open source, développée en GWT permet de créer et d’éditer des process BPMN 2.0, d’importer et d’exporter en BPMN 2.0, XPDL, mais aussi exporter vers un fichier BPEL 2.0.

Beaucoup de choses à venir autour de ce produit, j’espère assez rapidement. Ca sera bien sur décrit ici.

<project>
<!--...-->
  <plugins>
  		<plugin>
		        <groupId>org.apache.maven.plugins</groupId>
		        <artifactId>maven-dependency-plugin</artifactId>
		        <version>2.2</version>
		        <executions>
		          <execution>
		            <id>src-dependencies</id>
		            <phase>package</phase>
		            <goals>
		              <!-- use copy-dependencies instead if you don't want to explode the sources -->
		              <goal>unpack-dependencies</goal>
		            </goals>
		            <configuration>
		              <classifier>sources</classifier>
		              <failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
		              <outputDirectory>${project.build.directory}/sources</outputDirectory>
					  <includeGroupIds>org.ow2.petals</includeGroupIds>
		            </configuration>
		          </execution>
		        </executions>
		      </plugin>
   <!--...-->
  </plugins>
</project>

En attendant les slides que tout le monde attend avec impatience, quelques photos de la soirée.

Mise à jour : Les slides de la soirée sont disponibles!

On notera encore une fois une troisième mi-temps riche de retours, de contacts et d’échanges. Merci encore pour les quelques retours des participants via Twitter ou le Google Group.

La soirée Android du JUG de Montpellier hier était vraiment très intéressante et instructive! Merci à toute l'équipe! @montpellierjug @etaix—
Jérémy DECOOL (@jdecool) June 23, 2011

Bravo à @etaix pour la qualité de sa prez' au @montpellierjug hier soir. Félicitations à l'équipe, c'etait une affaire rondement menée !—
Curved Cat Games (@curvedcatgames) June 23, 2011

Très bon retour d'expérience du développement sur Android d'Éric Taix (http://bit.ly/jP5IOo) au @montpellierjug—
Sylvain Fraïssé (@sfui) June 23, 2011

[INFO] ------------------------------------------------------------------------
[INFO] Building dsb-kernel
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [spoon:recompile {execution: default}]
[INFO] org.objectweb.fractal.fraclet.annotation.processor.FractalComponentProcessor
[WARNING] FractalComponentProcessor >> No value found for property 'generatorClass' in processor org.objectweb.fractal.fraclet.annotation.processor.FractalComponentProcessor
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] fail to execute</code>

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23 seconds
[INFO] Finished at: Mon Jun 20 23:27:21 CEST 2011
[INFO] Final Memory: 50M/123M
[INFO] ------------------------------------------------------------------------

Ahah, qu’a cela ne tienne, le même en mode debug donc…

[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: fail to execute
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: fail to execute
at net.sf.alchim.spoon.contrib.maven.AbstractSpoonMojo.execute(AbstractSpoonMojo.java:96)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.NullPointerException
at spoon.support.reflect.declaration.CtAnnotationImpl.convertValue(CtAnnotationImpl.java:160)
at spoon.support.reflect.declaration.CtAnnotationImpl.getElementValue(CtAnnotationImpl.java:253)
at spoon.support.reflect.declaration.CtAnnotationImpl$AnnotationInvocationHandler.invoke(CtAnnotationImpl.java:69)
at $Proxy31.name(Unknown Source)

Yeah cool, une NPE. Ah dommage, sur $Proxy31.name… Genre le proxy généré par Spoon. Et donc bon, on fait quoi la? On revert tout et on tente de bouger les interfaces une par une pour voir qui fout son bordel? Mouais… Trève de blahblah, après avoir passé quelques dizaine de minutes à bouger, compiler, reverter, voici la conclusion: Définir des constantes dans des interfaces qui sont dans des dépendances et les utiliser dans les annotations des implémentations n’est pas possible, par exemple, dans une implémentation du style :

@FractalComponent
@Provides(interfaces = { @Interface(name = "service", signature = ServiceBinderRegistry.class) })
public class ServiceBinderRegistryImpl implements ServiceBinderRegistry {

@Requires(name = BINDER_PREFIX, signature = ServiceBinder.class, cardinality = Cardinality.COLLECTION, contingency = Contingency.OPTIONAL)
private final Map<String, Object> binders = new Hashtable<String, Object>();

On ne peut pas avoir BINDER_PREFIX dans l’interface ServiceBinderRegistry qui est dans une dépendance, par contre ca marche bien quand l’interface est dans le même projet… Quand on tombe la dessus à minuit, c’est rude…

PetalsLinkLabs Stack

Following the successes of the 2009 and 2010 editions of OW2 Annual Conference, we are very pleased to launch now OW2Con 2011, that will take place on November 23 and 24 in Orange Labs’ innovative and professional conference site “Issy Innovation Garden” in Paris.
The event will offer two days of high-level technical presentations around open source middleware technologies and generic applications. This will be a unique opportunity for attendees and sponsors of the event to meet with peers and network with the international open source community at large. All sessions will take place in English language, including technical and business presentations, and featuring the OW2 Open Source Cloudware Initiative. Parallel sessions (BoFs, side events, third parties projects) will complete the program. Among the main novelties that will be included in the OW2Con 2011 program, the “SQUAT” project (Software Quality Assurance and Trustworthiness) is a major one. Unique program of this kind, SQuAT has the aim to improve the quality of code by generalizing quality tests on OW2 technologies and setting up a quality label. Additionally, one year after the launch of the Open Source Cloudware Initiative and the involvement in current or future collaborative projects, OW2 has reaffirmed its position as a main actor in the open source cloud computing area that will be demonstrated during the conference.

Source, http://www.ow2.org/view/Events/OW2AnnualConference2011

 

Tant qu’on y est, PetalsLink s’agrandit et cherche des consultants pour développer le business sur Paris. Des postes en R&D sont aussi ouverts sur Toulouse.

Image via Wikipedia

La prochaine soirée du JUG Montpellier vient d’être annoncée, elle se déroulera le 22 juin 2011 et aura pour unique thème la plateforme Android. Cette soirée complète permettra de partir des bases et d’approfondir au maximum le sujet :

• Partie 1: Cette 1ère partie sera consacrée à l’introduction de la plateforme Android, le marché du mobile, les fondamentaux de la plateforme et de la programmation.
• Partie 2: Cette 2ème partie s’attachera à présenter les bonnes pratiques, l’utilisation de librairies facilitant le développement. Nous reviendrons ensuite sur les annonces du Google IO 2011, les modèles économiques possibles pour finir sur les alternatives.
• Partie 3: Echange dans un bar Montpelliérain.

L’intervenant principal de la soirée sera Eric Taix, Responsable R&D chez ESII Media Acceuil

Eric Taix est aujourd’hui responsable du développement chez ESII Média Accueil et un expert J2EE. Ses 20 ans d’expérience auprès d’éditeurs, de sociétés de service (FiSystem, Cap Gemini) et de startup lui ont donné de solides compétences dans le développement logiciel et la plateforme Java. Passionné de technologie, il croit fermement dans la communauté Java, le partage des connaissances ainsi qu’à l’expertise des équipes. Il participe d’ailleurs activement à des projets open-source du monde Java et Android.

L’ouverture des inscriptions est imminente, stay tuned!

Oh!?

Gartner predicts that by 2012 20% of businesses will own no IT assets. A key aspect of this trend is the move towards cloud-enabled services. Open source solutions are key enablers of this trend. This talk will explore how a fully open sourceSOA-based solution can use the Cloud to open and extend enterprise software infrastructure.

The attendee will first learn how a Cloud-aware SOA software infrastructure can be built combining an Enterprise Service Bus [http://petals.ow2.org] and a Cloud infrastructure framework [http://opennebula.org]. This creates a ‘Cloud Service Bus’ which will allow the integration of in-house services in order to benefit from Cloud-based features such as elasticity, load balancing, service clustering and migration. Then, the talk will go one step further: by using the Cloud framework capabilities, the Cloud Service Bus can be extended to a hybrid approach combining both public and private Clouds. This shows the attendee how to bring the advantages of modern cloud based solutions to legacy enterprise applications while keeping sensitive data and services inside the enterprise. A Cloud-based SOA solution needs to be governed, monitored and managed in a totally transparent way akin to a traditional SOA solution; throughout the presentation the talk will show how the Cloud Service Bus approach does not break the SOA paradigm.

This work is part of the Open Source Cloudware Initiative launched by the OW2 Consortium [http://www.ow2.org/view/Cloud/] and uses research work from the SOA4All [http://soa4all.eu] and Play [http://play-project.eu] European Commission Cordis FP7 research projects.

A suivre, en vrai, autre part…

Athènes - Mai 2011

SOA4All

Toute personne déjà venue sur ce blog devrait connaitre un minimum ce projet qui m’a occupé ces trois dernières années. C’est bon je ne devrais plus en parler trop puisque il est maintenant officiellement terminé depuis la fin du mois dernier. La revue finale s’est déroulée aujourd’hui à Bruxelles. Pas de présentation technique pour cette fois, j’ai même pas eu besoin de dire un mot… La session du matin était assez spéciale pour un projet recherche: essayer de vendre le projet a un investisseur (avec un vrai investisseur, mais qui venait sans son chéquier). Bref un jeu de rôle que je trouve un peu grotesque et qui au final n’a rien donné a part trop de travail pour les speakers.

Regardons ce que ce projet a pu m’apporter, apporter à PetalsLink et aux produits associés, les points forts, les points faibles, etc, (en essayant de faire court):

• + Mon premier projet de recherche européen. Je suis entré dedans dès le début après avoir passé 2 ans a bosser sur Petals ESB à temps plein en tant que développeur, product leader et compagnie. J’avais par le passé travaillé sur un projet ANR pendant presque 3 ans aussi sur le thème du grid computing (cf http://grid-tlse.org).
• + Petals ESB n’avait jamais été trituré de la sorte (ndlr: faut que je trouve un autre mot que trituré, je l’ai déjà utilisé hier plusieurs fois). La version utilisée dans SOA4All diffère énormément de la version communautaire OW2. En plus de l’ajout de nombreux services, il a été aussi customisé dans tout les sens pour qu’il soit non plus ‘Enterprise Service Bus’ mais ‘Internet Service Bus’. Les protocoles et contraintes de la version entreprise n’étant pas forcément les mêmes que ceux d’Internet.
• + Le Distributed Service Bus qui en découle est maintenant une base pour de nombreux projets de recherche chez PetalsLink, donc on en entendra encore parler sur ce blog.
• - Les partenaires du projet avaient une toute autre vision de ce qu’est un middleware, dès la première réunion on a entendu plusieurs fois ‘The middleware is the Internet’. Donc là forcément çà commence pas trop bien.
• + Heureusement, l’INRIA était là. J’avais déjà eu le plaisir de travailler avec l’INRIA Lyon sur Grid-TLSE, et généralement ces personnes là savent de quoi elles parlent et savent ce qu’est un middleware. On travaille d’ailleurs ensemble sur de nouveaux projets dont Play.
• - ‘SOA pour tous‘ mais pas pour le projet lui même… Le but du DSB était aussi de fournir cette brique SOA de base. On se retrouve avec des développeurs qui font tous leurs Webapps dans leur coin et qui s’intégrent ‘à la mano’. Dommage il faut recompiler tout si le service est déployé ailleurs…J’ai presque honte de dire la taille de l’installer graphique que j’ai été chargé de faire pour installer les différents modules; allez 800Mo et encore tout les modules ne sont pas présents.
• + C’est fini, maintenant on va pouvoir faire des vrais projets midleware, SOA et compagnie.

Play

Le projet Play a commencé depuis un peu plus de six mois (je ne parle toujours pas de Play! Framework mais vous devriez vous intéresser à ce Framework Web, le premier tuto est assez bluffant quand on a l’habitude de faire du Spring, du Struts, du GWT ou tout autre Framework Web, Play! est en train de percer et de botter le cul aux autres). Bien que le projet soit encore au début (durée 36 mois), l’activité est assez intense et promet de bonnes choses dans un futur proche. Pour faire rapide, il est question de développer une plateforme événementielle qui utilisera des technos issues/basées sur le Distributed Service Bus, de Complex Event Processing, de P2P, d’adaptation contextuelle, le Cloud, etc, etc, etc… Bref, beaucoup de choses à faire et un Bus de Service, qui va évoluer encore et encore. Ah et on parle aussi de gouvernance au niveau service et évènements, ce qui est un peu plus nouveau pour la partie évènementielle.
Donc la réunion de la semaine dernière à Athènes (ça change de Bruxelles…) a encore une fois tenue ses promesses: du contenu en masse, des cas d’usage qui évoluent pour utiliser au mieux la plateforme et le concept d’Event Marketplace qui se précise. Je pense que je parlerais mieux de tout ça d’ici peu de temps mais les bases sont posées.

Codons!

Ces voyages au sud et au nord de l’Europe m’ont laissé le temps de coder (surtout quand le TGV tombe en panne entre Montpellier et Bruxelles), un article sur une nouvelle feature du DSB a vu le jour hier soir, j’en ferais un autre plus précis dans les jours qui viennent.

Ce que l’on pouvait faire jusqu’à présent, c’est utiliser l’API Web service exposée par le DSB pour invoquer le service pour peux que le service soit annoté comme il faut (pour rappel, cette API Web service utilise Apache CXF pour exposer automatiquement les composants Fractal qui sont annotés avec JAXWS). Bien, mais par défaut on utilise deux ports pour les communications inter noeuds: Le port utilisé par Apache CXF, et l’autre par la couche de transport du DSB (en fait c’est le cas dans Petals ESB, mais dans le DSB, la couche de transport étant par défaut une implémentation en Web service, on utilise le même port pour les deux). En allant un peu plus dans les détails, même si on utilise le même port pour les deux modules dans le DSB, ceci n’est plus vrai si une nouvelle implémentation de la couche de transport utilise autre chose que CXF (pour info, dans le DSB, une implémentation de la couche de transport en XMPP existe aussi). C’est donc la qu’on arrive a la solution d’utiliser le canal de communication du DSB pour toute invocation entre noeuds, comme on sait déjà échanger des messages avec le DSB, pourquoi s’en priver?

C’est bien beau de vouloir exposer des services, des composants Fractal, ou quoi que ce soit, si on veut rester en Java et ne pas avoir besoin de se triturer le peu de cerveau qu’il nous reste, autant penser à utiliser tout ou partie d’une solution qui existe deja. En allant dans ce sens, comme on doit au final avoir une sorte de serialization des messages, autant utiliser quelque chose qui sait deja le faire, j’ai nommé le couple inséparable JAXB+JAXWS. Ceci impliquera seulement d’annoter ses interfaces et de créer des types propres et JAXB-aware mais au final, je ne pense pas que cela soit une contrainte forte… C’est bien beau tout cela mais JAXB + JAXWS tout seul ca ne fait pas grand chose. C’est la qu’entre en jeu Apache CXF. Puisque l’utilisation de JAXWS est simple avec CXF, autant s’intéresser un peu à la bete. Pour le coup cà tombe bien, dans CXF il y a deja une notion de transport multiple: HTTP, XMPP, JMS et si on regarde bien on a même JBI (les potes de chez JonAS ont d’ailleurs implémenté un transport CXF utilisant les EJB ou un truc J2EE dans le style si ma mémoire est bonne). Tiens donc, il y a un transport JBI? Ca tombe (presque) bien, le DSB est basé sur Petals ESB qui est JBI compliant. Oui mais en fait non. J’aurais presque pu l’utiliser mais le but est d’implémenter quelque chose d’assez ‘JBI independant’. Le tout est maintenant d’implémenter un nouveau transport pour le DSB et grace au code source de CXF et à cette page http://cxf.apache.org/custom-cxf-transport.html on comprend assez bien comment faire. Dans la terminologie CXF, le client est le ‘conduit’ et le serveur est la ‘destination’. Il suffit donc d’implémenter nos propres conduit et destination pour pouvoir échanger des messages avec CXF.

Une fois CXF configuré avec nos conduit et destination, ou plutôt une fois la bonne transport factory implémentée, on devrait pouvoir faire quelque chose du style:

// 1. Initialize CXF Bus with factory
Bus bus = BusFactory.getDefaultBus();
DestinationFactoryManager dfm = bus.getExtension(DestinationFactoryManager.class);
DSBTransportFactory petalsTransportFactory = new DSBTransportFactory();
petalsTransportFactory.setBus(bus);
petalsTransportFactory.registerWithBindingManager();

// 2. Start service
System.out.println("Starting CXF server...");
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setAddress("dsb://host/serviceA");
sf.setServiceClass(HelloService.class);
sf.setServiceBean(new HelloService() {
    public String sayHello(String input) throws PEtALSWebServiceException {
        System.out.println("SAY HELLO INVOKED!");
        return pre+input;
    }
});
sf.create();

// 3. Create the client and invoke
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress("dsb://host/serviceA");
factory.setServiceClass(HelloService.class);
HelloService hello = (HelloService) factory.create();
String out = null;
try {
    out = hello.sayHello(in);
} catch (PEtALSWebServiceException e) {
}

Je passe les détails d’implémentation (que j’ai eu le plaisir de faire dans un bon vieux TGV en panne entre Montpellier et Bruxelles) pour le moment, mais ce qui se passe se résume à:

1. On configure CXF en lui ajoutant notre Transport Factory. Au niveau de l’implémentation, il y a ce qu’il faut pour que lorsque une client ou une server factory est configurée avec une adresse qui commence par ‘dsb://’, ce soit notre DSBFactory qui soit automatiquement appelée par CXF.
2. La création du service se fait comme si on créait un Web service sur http sauf que là c’est un ‘Web service sur DSB’.
3. Idem que pour 2 mais on génère un client qui nous permettra d’appeler le service créé auparavant.

En résultat, pour peu que le client (en 3) et le serveur (en 2) soient exécutés sur des noeuds séparés, le DSB se chargera d’acheminer la requête et la réponse comme il faut entre les acteurs et ceci de façon complètement transparente. Au niveau de l’implémentation coté kernel du DSB (ceci vaut aussi pour Petals ESB), il suffit de connaître quand même un peu le coeur pour créer des fakes de composants JBI en farfouillant dans les APIs disponibles, de savoir jouer avec le DeliveryChannel, le ComponentContext, le NormalizedMessageRouter, ajouter quelques modules de routage, savoir recevoir des messages et y répondre, et surtout implémenter le Conduit et la Destination CXF en s’inspirant de ce qui existe déjà et en mettant les doigts dans le cambouis. Pour les curieux, je vous conseille de jeter un oeil au code de CXF assez compréhensible et pas mal fait du tout.

Enfin pour étendre cela aux services techniques du coeur du DSB, il suffit, au runtime, de scanner les services disponibles offerts par les composants du kernel et automatiquement créer les services comme décrit dans l’étape 2. Chose que l’on sait déjà faire dans le DSB via le scan pour exposer les services en Web service sur HTTP avec CXF (oui toujours lui, avant je m’en prenais a Axis2…).

Et voila donc une belle et simple façon de simplifier la vie du développeur du DSB (c’est à dire moi). Il va être maintenant possible d’invoquer n’importe quoi de n’importe où avec une API Java. Pour peu que l’on plugge quelques modules au bon endroit, on peut imaginer faire des choses assez sympa: Le Cloud en fait partie.

Note: Le code sera disponible d’ici la fin de la semaine sur le SVN du DSB. Surement sous https://svn.petalslink.com/svnroot/trunk/research/commons/dsb/modules/dsb-kernel, je mettrais a jour l’article en fonction…

Image via Wikipedia

Je reçois encore trop souvent des mails me demandant où est passé le code des produits Petals (Petals ESB, Petals Master, EasyWSDL et compagnie) et comme les sites associés ne sont pas encore à jour je vais donner rapidement les informations ici.

Plus la peine de chercher le code sur les SVN respectifs d’OW2. Nous faisons bien sur toujours partie du consortium mais pour des raisons de facilité et de maintenance/évolutions client, tout est maintenant hébergé sur un SVN corporate, un accés HTTP anonyme en lecture est possible sur http://svn.petalslink.com/ (login ‘anonymous’ et mot de passe ‘anonymous’). Et non toujours pas de Git pour cette partie là!

Coté documentation, les sites *.ow2.org n’étant pas à jour, il existe un wiki qui est riche d’information sur chaque brique Petals, il se trouve là http://doc.petalslink.com/.

Pour finir, il y a aujourd’hui beaucoup de choses en cours d’incubation provenant des divers projets de recherche auxquels PetalsLink participe activement. Toutes les informations sur les projets, sur ce que l’on y fait mais surtout sur les prototypes et futurs produits sont disponible sur le Wiki de l’équipe R&D http://research.petalslink.org/.

Toujours est il que les faits sont là. Les moteurs ont beau crawler le Web à la recherche de services Web (les vrais avec un WSDL!), ils depuis un certain temps dans une phase stagnante. Pour preuve, le nombre de services trouvés par le moteur Seekda est aussi plat que la pleine Toulousaine, on devine un peu plus de 25000 Web services publics trouvés et ce chiffre est le même depuis presque 3 ans:

Source : Seekda.com

Il y a bien de nouveaux services découverts de temps en temps, mais bon, il me semble que c’est plus de l’ordre du prototype ou du test que d’autre chose, la preuve en image:

Oh la belle calculette...

Bref, le déclin est annoncé. Pour preuve, on peut aussi regarder l’intérêt que portent les utilisateurs aux APIs SOAP et REST par le biais des tendances de recherche Google (via http://www.google.com/insights/search/#q=soap%20api%2Crest%20api&cmpt=q). Bien sûr l’internaute ne dicte pas la mort de SOAP et la percée de REST, mais il est clair que ce qui est ‘trendy’ de nos jours est bien REST :

SOAP vs REST

Et vous dans la vrai vie, vous êtes plutôt SOAP ou REST?

The purpose of the competition is to develop awareness for the OW2 code base among students and technicians, and to provide an opportunity for contestants to demonstrate their talent in computer programming. What’s more, the contest aims at promoting teamwork and the ability of college students in science and technology to study and use OW2 open source projects. Based on principles of “freedom, sharing and creativity”, and aiming at improving international communication and cooperation, the competition is overseen by IT professionals and academics from around the world.

Bref, j’ai soumis deux sujets à l’OW2 programming contest :

1. Petals ESB et IaaS, ou comment interfacer un bus de services avec une couche IaaS pour qu’il en tire les avantages de la couche infrastructure (je pense principalement à l’élasticité).
2. Console Web de Monitoring & Management pour Bus de Services, le but étant de développer une Web console un minimum dynamique avec GWT et ses extensions. Comme base de travail, une version utilisant GWT-ext qui n’est pas conforme à nos attentes au niveau licence sera fournie.

Il y a une tonne d’autres sujets proposés par les partenaires (dont beaucoup sur Jonas, Jasmine et compagnie), jetez-y un coup d’oeil, ça vaut le coup de voir les idées qui trottent dans la tête des gens.

This video describes the current trends in the Future Internet of services and the Web of Data. The project SOA4All considers resources to be services usable via the Service Web. In order to address the current limitations of service computing at Web scale and to lower the entry barrier for the average Web service workers, SOA4all combines Web principles, Web 2.0 technology, context
management and semantics into a novel service delivery platform. The applicability of such a platform is manifold, and industrial partners such as SAP, BT and TIE have already demonstrated the benefits of SOA4All technology in the Public Sector, Telecommunications and eCommerce.

Pour plus d’informations et pour les inscriptions à cette première soirée, ca se passe sur le site tout beau tout neuf développé pour l’occasion (je reviendrais sur ce qui à été utilisé plus tard) : http://www.jug-montpellier.org/. N’hésitez pas à venir jeter un coup d’oeil, dire bonjour, vous instruire et boire un coup!

Image via Wikipedia - Un stand sympa!

Dernier jour de la conférence In The Cloud 2eme édition à Paris. Journée que je souhaite dédier à la visite des stands et à l’écoute de quelques conférences.

Quand je disais plusieurs fois que l’on pouvait tout mettre dans le Cloud, ce salon en est la preuve. Tout le monde fait du Cloud (ou prétend en faire) aujourd’hui. J’ai quand même pas mal rigoler en voyant des stands où des vendeurs de câbles pour datacenter avaient revêtu le plus beau des costards. Il y avait bien évidement les IBM, SFR, EMC et autres acteurs de solutions d’hébergement d’entreprise mais aussi quelques fournisseurs de datacenters. Au final, rien de bien transcendant…

Coté talks, je commence la journée par le talk sur ‘Business Process as a Service‘. Je m’attendais a quelque chose de très technique. Au final la conférence dévie vers les réseaux sociaux, la messagerie instantanée et autres sujets déconnectés du thème (en tout cas par rapport à ma vision des processus métiers). Ah oui, tiens j’ai appris que je faisais partie de la ‘génération Y‘ (ignare que je suis), j’ai du entendre ce terme une bonne trentaine de fois.
OK bon, passons à la suite, le sujet à l’air sympa ‘Comment sécuriser le cloud computing, cette mine d’or des hackers?‘. On parle 30 secondes de la dernière attaque en date sur le ministère de l’économie puis à chaque intervenant de donner son avis sur la sécurité dans le Cloud, ou plutôt sur la sécurité en général. Il est vrai que la sécurité reste de la sécurité, qu’elle soit pour le Cloud ou pas. Je m’attendais à des choses bien plus spécifiques encore une fois même si le Cloud est vague.
Allez dernière conférence de la journée ‘Quel modèle de déploiement pour le Cloud (public, privé, hybride) ? A quelle fin? Comment les orchestrer?‘. Comment dire… On tourne un peu en rond, je suis sur qu’un article sur wikipedia sur le public, privé et hybride existe déjà et résume à lui seul cette dernière conférence. Rien sur l’orchestration (administration?).

Au final, une conférence bien orientée business de part l’armé de commerciaux déployée sur les stands. Très peu de stand très technique comme je les aime (mis à part celui d’OW2), des conférences d’assez bas niveau bien que les intervenants soient de qualité (la faute aux animateurs/modérateurs). Pour faire simple, techos passez votre chemin.

Je passe le buffet, non intéressant technologiquement parlant, mais qui finalement attire du monde… L’après-midi est donc consacré à la réunion de l’initiative Cloud Open Source menée chez OW2. Découpée en 4 domaines:

1. Domain 1: Self-sizing et Green PaaS
2. Domain 2: Distributed interoperability architecture/Massively Distributed Services
3. Domain 3: BI4 CLoud, Business Intelligence For Cloud
4. Domain 4: Massively Distributed Cloud

Une description détaillée est disponible sur le wiki de l’initiative

Nous, chez PetalsLink, leadons le domaine 2. Le but est de permettre à des domaines et des Clouds de services dinteropérer et d’utiliser les caractéristiques offerte par la couche IaaS pour construire une offre PaaS SOA. En quelque sorte, on peut imaginer avoir dans quelques mois un bus de service déployé dans le Cloud et offrant les possibilités d’intégration et d’architecture faiblement couplée que l’on à aujourd’hui avec un bus de service tel que Petals ESB. Avoir cette offre au niveau PaaS signifie que l’utilisateur/développeur n’aura pas à manipuler et à manager le bus tel qu’il doit le faire aujourd’hui mais simplement utiliser les APIs et les clients fournis pour importer ses services, déployer ses business process, etc… Tout cela dans une approche élastique, scalable, multitenante, … bref Cloud (J’y reviendrais bientôt dans un article dédié, j’attend juste le résultat pour le talk a OSCON…).

La journée se finit par le meeting du TC (Technology Council), responsable de la définition de l’architecture technique d’OW2, de créer des synergies entre projets, de définir les règles et démarches à suivre. Les discussions du jour tournent sur la maturité des projets (et la mise en maturité des projets en incubation), la qualité logicielle que doivent respecter les projets OW2. Bref des changements à venir dans les prochaines semaines afin d’encore augmenter la crédibilité du consortium et de ses projets.

Demain, dernier jour à Paris: Tour des stands et conférences.

Pour ma part j’y serais les trois jours, probablement sur le stand OW2 ou sera présenté les travaux sur l’initiative Cloud lancée l’an dernier (OSCi Open Source Cloud initiative):

La communauté démontrera pendant le salon les solutions et travaux menés dans le cadre de son Initiative Cloudware et de sa participation au projet R&D CompatibleOne. L’Initiative OSCi anime un effort collaboratif visant à définir le futur d’un cloud computing ouvert et interoperable. Le projet CompatibleOne a pour vocation le développement d’un socle standard pour répondre au manque d’interopérabilité des plateformes Cloud existantes, en leur apportant notamment les outils technologiques nécessaires de portabilité.La communauté sera représentée sur le salon par l’équipe OW2 ainsi que par ses partenaires UShareSoft, ActiveEon et les membres du projet CompatibleOne (source http://www.inthe-cloud.com/info_societe/36/ow2.html).

The intent of the semantic web is to enhance the usability and usefulness of the internet and its interconnected resources.

What Is The Semantic Web?

Je pense vraiment que ce genre d’approche est la plus intéressante à mettre en oeuvre. Il est clair que les entreprises ne sont pas prêtes (et ne le seront sûrement jamais) à basculer tout leur système dans le Cloud public. On pense principalement au problème qu’il peut y avoir au niveau de la sécurité des données. Par contre, on peut imaginer qu’une partie des ressources (au sens large) peut potentiellement être déportée dans un Cloud public. Dès lors que l’on fait cohabiter du Cloud public et du Cloud privée, on passe donc dans le Cloud hybride. Simple? Pas tout a fait. Bien que le concept soit à mon avis le plus intéressant, il est aussi le plus dur à mettre en oeuvre.
Heureusement, des frameworks Cloud, tels que OpenNebula (brièvement présenté dans un précédent article) permettent de créer et de gérer des Clouds hybrides de façon transparente. Dans un de leur récent article, l’équipe qui est dérriere OpenNebula présente quelques cas d’usages qui répondent au besoin du Cloud hybride. Dans ‘Scaling out Web Servers to Amazon EC2‘, ils présentent comment on peut load-balancer une application Web en utilisant des ressources privées et publiques sur Amazon EC2. L’intérêt est ici de pouvoir fournir une qualité de service ‘constante’ en utilisant des ressources privées et d’avoir la possibilité de répondre à des pics de charge momentanés en utilisant des ressources publiques louées ponctuellement.

Cette approche est un bon compromis. Je ne crois vraiment pas au ‘tout public’. En me plaçant au niveau purement technique, je n’y vois aucun intérêt et si c’était le cas, Petals* serait déjà dans le Cloud depuis un bon moment. Par contre au niveau business, on pourrait alors dire que l’on fait du Cloud comme certains de nos concurrents…

Une approche SOA dans le Cloud hybride est donc plus dans la mouvance de ce que je veux pousser et développer cette année. Construire un bus de services pouvant s’adresser et utiliser les fonctionnalités du Cloud hybride me parait vraiment un bon challenge, et qui plus est, qui peut le plus peut le moins…

Ca a l'air compliqué, mais je vais quand même y aller

Pour résumer et dans le désordre, en 2010 :

• J’ai changé de mode de travail mais pas de travail! Je suis depuis bientôt un an en télétravail depuis Montpellier pour PetalsLink. De ce point découle beaucoup de choses, entre autres l’activité grandissante de ce blog.
• Mon premier gros talk en Anglais devant une centaine de personnes à l’OW2 Annual-conf :
• J’ai rejoint le comité technique du consortium OW2. Cela va me permettre de m’impliquer encore plus dans le consortium et dans l’open source (même si je l’étais déjà…).
• Je suis passé au Cloud! Ou plutôt je leade l’activité Cloud depuis quelques semaines.
• J’ai rencontré quelques personnes très intéressantes notamment via Twitter et OW2 et en particulier @esdaniel, @gregmignard, @el_barbu, @sauthieg, @emathias… Merci à vous pour les échanges passés et à venir. Pour ceux que je n’ai pas encore rencontré physiquement, ce sera sûrement pour bientôt (sauf l’expatrié au Sénégal mais n’oublie pas que je crois en toi ).
• Un nouveau projet de R&D a commencé pour moi: Play. On est parti pour faire de la SOA, de l’EDA, du Cloud, …
• J’ai rencontré des Montpelliérains prêts à se lancer dans l’aventure d’un JUG local.

Il en manque sûrement mais c’est déjà pas mal. Cette nouvelle année doit donc être tout aussi prometteuse. Pour le moment, je prévois pas mal de choses et j’ai quelques envies et idées dans la tête que j’aimerais concrétiser. Certaines ne sont pas encore mûres donc je n’en parlerais pas mais ce que je peux dire aujourd’hui :

• Il faut lancer le JUG Montpellier au plus tôt. On planche sur une première session pour se faire la main en février.
• Concrétiser la solution Cloud de la suite SOA PetalsLink : ASAP
• Faire encore au moins un gros talk en anglais dans une grosse conférence. J’en ai une en vue, affaire à suivre…
• Finir le projet SOA4All. On est quasiment au bout. Il y a eu un gros travail sur Petals ESB ces 3 dernières années dans le contexte de ce projet. Les détails  et le bilan dans les prochains mois.
• Quelques points que je ne dévoile pas encore…

Que cette année soit Cloud!

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 8,200 times in 2010. That’s about 20 full 747s.

In 2010, there were 50 new posts, growing the total archive of this blog to 106 posts. There were 48 pictures uploaded, taking up a total of 8mb. That’s about 4 pictures per month.

The busiest day of the year was March 15th with 71 views. The most popular post that day was Setting timeout on generated JAXWS CXF Clients.

Where did they come from?

The top referring sites in 2010 were petalslink.com, planet.petalslink.com, jeteletravaille.fr, javablogs.com, and petals.ow2.org.

Some visitors came searching, mostly for cxf timeout, jaxwsproxyfactorybean timeout, petals esb, jax-ws timeout, and jaxws timeout.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Setting timeout on generated JAXWS CXF Clients September 2009

Bilan de 6 mois de télétravail August 2010
9 comments and 1 Like on WordPress.com,

Axis2 : Rerouter vos appels de services sans modifier vote code client March 2010
3 comments

Maven2 : Deployer ses artefacts sur un repo alternatif en FTP ‘a la mano’ March 2010
2 comments

Mapping WSDL JBI March 2010
2 comments

Fully open source (not open core), thoroughly tested, customizable, extensible and with unique features and excellent performance and scalability to manage hundreds of thousands of VMs:

• Private cloud with Xen, KVM and VMware,
• Hybrid cloud (cloudbursting) with Amazon EC2, and other providers through Deltacloud (from ecosystem),
• Public cloud supporting EC2 Query, OGF OCCI and vCloud (from ecosystem) APIs,…
• and much more.

Dit comme ça, on ne voit pas forcement la différence avec le concurrent direct qu’est OpenStack. Deux frameworks pour le Cloud qui se positionnent de la même façon… D’ailleurs, un représentant de chaque produit était présent à la conférence OW2 le mois dernier et les présentations était assez identiques. Bon OK, OpenStack se la joue plus à l’américaine : “Eh les gars, nous on est issue de la NASA OK?!”……
OpenNebula lui est un projet qui est en partie financé par des projets de recherche Européens depuis 2005, quand on connaît le niveau de ce genre de projets financés, on a peu de doutes sur les capacités d’un produit issu de là. On a beau pas être américains, on sait aussi faire décoller des fusées… Bref, fermons la parenthèse anti-amerlocs.

2005? On parlait déjà Cloud à cette époque? Non, on parlait grille et calcul haute performance. C’est pour adresser ces domaines que OpenNebula a été créé. Elle a évoluée au cours des années car finalement c’est toujours un peu la même chose… On change le nom et on rajoute deux/trois trucs par ci par là… Ce n’est donc pas étonnant de voir une infrastructure de type cluster du type Frontale + Noeuds:

(Par la suite, ONE = OpenNebula; VM = Machine Virtuelle)

• Le binaire de ONE est installé et lancé en tant que daemon sur la machine frontale (ONED). C’est lui qui fournit les APIs Cloud propriétaire et celles qui peuvent être pluggées par dessus (du type Amazon EC2, OGF, etc…).
• Dans le comportement par défaut, les images permettant de lancer les machines virtuelles sont partagées entre les noeuds via un bon vieux système de fichiers réseau de type NFS.
• La frontale doit pouvoir se connecter à tout les noeuds en SSH ie partage de clés.
• Les Hypervisors sont les plateformes de virtualisation qui permettent de lancer des machines virtuelles sur les noeuds. Les plus connus (et supportés par défaut par ONE) sont, par exemple, Xen, KVM et VMWare.
• Les Drivers permettent de créer la communication entre le daemon tournant sur la frontale et les hyperviseurs.

D’après cette liste, on comprend mieux la philosophie d’OpenNebula. Il s’agit d’utiliser des hyperviseurs existants, de les envelopper, de leur rajouter des fonctionnalités et de les gérer intelligemment. Cette gestion intelligente doit bien sur se caler par rapport aux attentes de niveau infrastructure Cloud (IaaS) en offrant de l’élasticité, de la migration de VMs entre noeuds, etc…

Une fois les hyperviseurs installés et en état de marche (c’est vraiment la chose la plus dure à faire et celle sur laquelle j’ai perdu un temps fou à cause d’une machine trop vieille…), l’utilisation de base depuis la frontale est assez simple:

1. Déclarer les noeuds physiques ie ceux qui hébergent les hyperviseurs et qui feront tourner les VMs
2. Déclarer un ou plusieurs réseaux virtuels. On définit ici principalement les addresses IPs qui seront assignées et utilisées par les VMs.
3. Soumettre une image système et son descripteur au scheduler. Le scheduler a pour but de faire migrer l’image vers le bon noeud physique afin de pouvoir démarrer une VM sur ce noeud.
4. Pas de 4… Enfin si mais pour des utilisations poussées, je passe pour le moment…

Dans une utilisation simple en mode Cloud privé, c’est à peu pres tout. On peut démarrer, arrêter et migrer des VMs assez facilement. ONE se charge d’assigner les bonnes addresses IPs pour peu que l’image système soit configurée pour le faire (via quelques scripts système). On peut donc créer son Cloud privé de type IaaS avec ONE pour pas un euro (modulo le temps à appréhender le monstre) et avoir un total controle dessus.

Ca à l’air très simple… Oui l’utilisation est simple, c’est la mise en place qui l’est moins. Tout du moins pour préparer les noeuds et les hyperviseurs. Je suis tombé sur des soucis avec la mise en place de KVM sur une machine trop vieille et qui ne fournit pas la virtualisation niveau processeur. Je passe car je n’ai pas le courage mais j’ai perdu pas mal de temps. Les développeurs qui sont très réactifs ont passé du temps avec moi pour essayer de voir ce qui collait pas. Résultat, je laisse tomber KVM que je commençais à maîtriser pour passer à Xen qui est moins simple mais qui est censé marcher mieux. Encore quelques dizaines de cafés en vue…

"c bien comme truc mais il faut etre bac +15 pour installer une machine" C'est pas de moi… @opennebula—
Christophe Hamerling (@chamerling) December 16, 2010

Dédicace à mon sysadmin préféré

Le ‘Cloud Summit’ de la première journée était je pense la partie la plus attendue et la plus suivi. Ce thème excite évidement beaucoup de monde en ce moment, et chez OW2, l’initiative Cloud est bien lancée avec de premiers résultats et prototype prévus pour l’an prochain.
Coté speakers, le niveau était là, ce qui m’a beaucoup amusé, c’est la présence de représentants des projets OpenNebula et OpenStack, deux solutions de virtualisation de ressources pour le Cloud qui se ressemblent fortement. Mis a part une solution EU et une autre US, les différences sont assez minimes (tout du moins dans ce qui a été présenté). Affaire a suivre sur le Net ou ici car j’aurais l’occasion de mettre en oeuvre très prochainement ces frameworks pour les travaux Cloud que je mène actuellement…

De la deuxième journée, je retiens principalement les présentations relatives aux projets OW2 : Jonas, XWiki, Talend, Bonita.
La démo combinée de Talend et de Bonita est simple mais efficace. Effectivement, on se doutait déjà que les deux produits marchait sans problèmes, là j’en suis sur, pas grand chose a dire de plus la dessus…
Je préfère approfondir un peu sur les présentations relatives à Jonas, le serveur J2EE principalement développé par Bull. Les slideshares cités dans un tweet de leur auteur (@florentbenoit):

@chamerling http://slidesha.re/dUjifT & http://slidesha.re/hASv0A for my #ow2con slides #ow2 #jonas #javaEE—
Florent BENOIT (@florentbenoit) November 26, 2010

Sur la partie ‘Reliable Asynchronous Web Services on JOnAS Java EE server’ fournissant un nouveau mode d’échange de message reliable et asynchrone à Apache CXF, mon constant est le suivant : L’approche est non lightweight et est plutôt orientée pour l’entreprise ie il faut des instances de Jonas pour faire tourner cette solution. Fini le bon vieux Endpoint e = Endpoint.publish(); . Mais disons ici que ce n’est pas le but. Le vrai but est démontré par une démo efficace; client et serveurs peuvent ‘tomber’, les messages seront de toute façon délivrés lorsque les parties intéressées seront de retour (A méditer pour Petals ESB…).
Sur la deuxième présentation ‘Secure your Java EE projects by using JOnAS audit tools’, je retiens la partie présentation des informations de monitoring qui permet de suivre le cheminement d’une invocation dans tout les modules entrant en jeu. La solution de présentation basée sur Flex est sexy, c’est vraiment mieux que de montrer des messages XML dans une pauvre table HTML… Cette partie aussi me semble très intéressante à extraire de Jonas et à rendre générique et disponible pour tous…

Tout cela (et tout ce que j’ai raté) confirme vraiment que les personnes impliquées dans OW2 fournissent vraiment un travail de qualité, que ce soit au niveau des projets, du management du consortium et sont vraiment motivés. Je pense vraiment que le travail autour des initiatives lancées cette année, que ce soit pour le Cloud ou le BI fourniront des solutions compétitives car les gens sont là, compétents et motivés!

Pour ceux qui ne suivent pas mes tweets, toutes les vidéos de ces deux journées sont disponibles en ligne.

Finalement, parler (en anglais) devant une centaine de personnes n’est pas si difficile et c’est même très motivant, il me tarde déjà la prochaine fois!

En attendant plus de détails, une phrase qui m’a bien plu ce matin, simple et efficace par Jean-Pierre Laisné, président de OW2 :

"Cloud can be foggy" #ow2con—
Christophe Hamerling (@chamerling) November 24, 2010

Pourquoi? Parce que le brouillard commence en bas, et en bas de la pile il y a l’infrastructure, facile mais à méditer…

Image via Wikipedia

J’utilise déjà Adium pour Gtalk, jabber perso et pro et en temps que Twitter-addict je me suis dit qu’il était temps de voir comment est supporté ce service dans la nouvelle version de Adium sortie il y a quelques jours (le support dans la beta était un peu juste et ne m’avait pas spécialement satisfait…). Voici donc un premier retour d’expérience sur l’utilisation de Adium et de Twitter.

Les mentions

Mentionner

Le premier soucis de l’intégration de Twitter dans un logiciel initialement conçu pour la messagerie instantanée est le mappage entre le monde du microblogging et de l’IM. Les développeurs d’Adium ont décidé que chaque abonnement Twitter serait mappé sur un buddy IM. Ok bon, je suis actuellement 538 personnes (mais activement quelques dizaines, merci les listes!). Bref, cela me donne une fenêtre de liste de contacts assez énorme, qui de plus est affreusement longue à charger au démarrage (l’enrichissement se fait pas tranche d’une centaine de contacts, je pense que les limitations de l’API Twitter doit en prendre un coup). En plus je me retrouve avec a peu prêt autant de notifications Growl me donnant le statut actuel de mes contacts…
Du coup, pas d’autre choix que de désactiver l’option ‘Afficher qui je suis dans la liste de contact‘ dans les préférences du compte Twitter.

Oui mais… En désactivant cette option, il se trouve que la completion du nom lors d’un @mention ne marche pas pour tous les utilisateurs… Pour info, la completion est disponible en tapant ‘@xxx + Tab’ xxx étant le début du nom de la personne à mentionner.
Les développeurs ont apparemment choisit de ne pas charger la liste des personnes suivies si on ne veut pas les afficher. Dommage, l’affichage n’étant pas la seule utilisation que l’on puisse faire et il arrive souvent que l’on veuille mentionner quelqu’un dans un tweet… Après avoir discuté avec les développeurs sur le canal IRC d’adium (#adium sur freenode), la seule solution est de réactiver l’option que l’on vient de désactiver un peu plus haut et de choisir le masquage des contacts pour le compte depuis ‘Affichage>Masquer certains contacts>Masquer les contacts du compte‘.

Bref, on se retrouve avec quelque chose qui marche mais qui dans mon cas prends énormément de temps à démarrer…

Être mentionné

Dommage, il semble que la seule façon de voir que l’on est mentionné dans le tweet d’un contact est une minuscule marque dans la barre de défilement… Une notification Growl aurait bien fait l’affaire (ou même une fenêtre de dialogue spéciale).

Les DM

Puisque au point précédent j’ai du désactiver l’affichage de la liste des contacts (et que je ne peux plus ‘double-cliquer’ sur le contact), comment alors envoyer un message direct?
Seule solution, créer une nouvelle conversation (cmd-N). Ouf la completion marche bien si on a bien activé l’option qui va bien (cf point précédent)…

Par contre, cette fois ci un DM venant de quelqu’un affiche bien une nouvelle fenêtre de dialogue de type chat.

Les listes

Support absent… Dommage, je ne suis activement qu’une vingtaine de personnes que j’ai placé dans une liste privée (la timeline globale étant vraiment trop horrible à suivre). Il y a sûrement ici une astuce pour créer un groupe d’utilisateur mais je n’ai pas envie de dupliquer les choses. Je m’en passerais pour le moment.

–

Pour conclure cet article, il est clair que le ‘mapping’ entre deux mondes pas tout à fait identiques est assez complexe mais pour une première intégration c’est déjà vraiment pas mal (en plus je ne pense pas qu’il y ait une société derrière Adium comme on peut le voir pour pas mal de projets Open Source de nos jours ie quid du business model d’un logiciel de messagerie instantanée). Ce genre d’exercice peut évidement tirer aussi les fonctionnalités de base vers le haut, a voir dans les prochaines versions.

Les points cités précédemment sont certainement contournables, et discuter avec les développeurs via le canal IRC du projet est un bon moyen de trouver des solutions alternatives en attendant la version 1.5 (le tracker est déjà bien rempli)…

Le but est de partager ici des infos sur les projets recherche auxquels nous participons, des nouvelles sur les prototypes, les avancées, les articles, les conférences, les meetings, … bref tout ce qui rythme la vie de l’équipe.

Just created account to share PetalsLink Labs stuff and more!—
PetalsLink Labs (@petalslinklabs) October 25, 2010

La premiere réunion de travail de la semaine dernière est plutôt prometteuse : montage de l’association, création du bureau, discussion de la première session qui aura certainement lieu en janvier 2011 dans une grande salle du centre ville. Bref de bonnes rencontres, de bonnes choses a venir, et j’aurais l’occasion d’y revenir assez rapidement.

De retour de la réunion de création du Montpellier JUG, de bonnes rencontres, la suite bientôt…—
Christophe Hamerling (@chamerling) November 08, 2010

A SOA4All white paper is available: “Web Services Are Dead. Long Live Internet Services“.

This white paper presents the project vision about the evolution the Internet ecosystem: Web 2.0, Semantic Web, Web of Data, Cloud technologies and other facets enabling and supporting the Future Internet of Services.

C’est l’époque à laquelle les feuilles tombent, mais c’est aussi celle où les nouveaux projets commencent… La semaine se tenait la réunion de démarrage du projet de recherche Play à Karlsruhe – Allemagne. Suite naturelle pour moi du projet SOA4All qui se termine dans les prochains mois, le projet Play (qui n’a aucun lien avec le Framework Web Play, très bon soit dit en passant) va permettre de mettre continuer mes travaux sur la fédération des architectures SOA, du Cloud et de plancher sérieusement sur les architectures événementielles.

Un scénario de présentation de la plate forme du projet est le suivant :

Paul is a businessman who has been flying from Paris to New York. He used the entertainment service on board, but hasn’t finished watching the movie before the landing. Two hours later he is entering his room in the downtown hotel he booked earlier and wow: the room entertainment service is ready to PLAY the movie Paul was watching in the plane – of course only the unfinished part.

Vu comme ça, rien (ou presque) de révolutionnaire en soit. Quoi que, en y réfléchissant bien et en pensant à la plate forme qui pourrait supporter de telles choses, on peut se demander comment on peut effectivement savoir que Paul va pouvoir regarder son film depuis sa chambre d’hôtel alors qu’il était en train de le regarder dans l’avion 2 heures plus tôt? Est ce que l’on peut alors parler de SOA, de cloud, de fédération, de gouvernance, d’adaptation, d’EDA, de CEP, …? Oui! Bref, l’architecture àvenir sera probablement certainement détaillée ici dans quelques temps, le temps de mettre tout dans le bon ordre… Il sera tout de même déjà question de mettre en place et d’étendre les produits que nous développons, que ce soit Petals ESB ou Petals Master pour ne citer qu’eux.

The PLAY project will develop and validate an elastic and reliable architecture for dynamic and complex, event-driven interaction in large highly distributed and heterogeneous service systems. Such an architecture will enable ubiquitous exchange of information between heterogeneous services, providing the possibilities to adapt and personalize their execution, resulting in the so-called situational-driven process adaptivity.

Bref, un beau projet qui commence pour moi, avec des partenaires experts dans leur domaine et beaucoup de choses à apprendre… Pour le moment je me demande si la prochaine réunion se tiendra encore dans un pays Bierophone (après la Belgique et l’Allemagne ces deux dernières semaines, question légitime) et par contre je ne doute pas que les discussions seront toujours aussi intéressantes, que ce soit chacun derrière son ordinateur ou autour d’une bonne table.

Bon, comme d’habitude, beaucoup de choses autour de la sémantique, sémantique de services, linked data, RDF et compagnie mais surtout l’occasion de montrer les avancées et faire un point sur le Distributed Service Bus ie le bus servant de base de l’infrastructure de service du projet.

Pour faire court, le scope à beaucoup varié et divergé de ce que nous pensions faire initialement. A la base, nous pensions nous engager vers le développement d’un bus de service massivement distribué à l’échelle d’Internet ie une extension de Petals ESB qui lui est tout juste distribué. Au final, cet aspect massivement distribué est forcément complexe et demande encore de la réflexion (surtout sur son utilité). Le scope s’est recadré vers quelque chose qui est plus dans l’air du temps en se rapprochant d’une solution SOA pour le Cloud.
Bref, on parle aujourd’hui de Federated Distributed Service Bus (fDSB) ou des réseaux/îlots de noeuds (les DSBs) sont interconnectés de façon intelligente pour créer des infrastructures fédérées. Pour ceux qui connaissent un peu Petals ESB, cela veut à peu près dire (et pout faire simple) que ces îlots ont une connaissance locale de leurs services. La connaissance des autres services n’est possible qu’a travers la couche de fédération et via des politiques de propagation des informations bien définies (un outils de gouvernance tel que Petals Master peut jouer ce role de définition des visibilités).
La couche de fédération est aujourd’hui le medium qui permet de faire communiquer ces ilots de DSBs via des protocoles hétérogènes, traverser les firewalls etc etc. On arrive alors vers les prémices du so-called “Hybrid Cloud” ie créer un Cloud SOA au sens large en utilisant du Cloud public (Amazon EC2 par exemple), du Cloud privé (via OpenNebula et compagnie), etc.
Et c’est bien le cas d’usage que l’on à dans les cartons : des DSBs sur Amazon EC2, des DSBs sur Grid5000, des DSBs sur les laptops et des invocations de services possibles (dans tous les sens et sans connaissance préalable des services disponibles).
Pour le moment on ne parle pas d’élasticité et compagnie qui font la force (à mon avis) du Cloud. Ca c’est autre chose que je suis en train de préparer en parallèle, qui devrait voir le jour dans les prochains mois et dont je parlerais sûrement à la prochaine “OW2 Annual Conference” dans un mois à La Cantine – Paris.

The Internet is growing fast and is becoming the support for thousands to billions of services prosumers. In parallel, business entities needs to collaborate more, are using Internet as a communication layer and are starting cloud intiatives to expose and consume IT services into public and private clouds.The goal of this presentation/talk is to introduce state of the art solution and to propose OW2-based Open Source response allowing entities to develop and extend their business easily in a cloud-aware way. The approach we are proposing is composed of three major modules : A cloud-aware/federated service bus, a service governance tool and an online Collborative Business Process Editor.The cloud service bus extends the OW2-Petals ESB by enabling service exposition and consumption between service farms by using OW2-ProActive as the framework to build a federated communication layer. Once communication links are established between parties using the cloud middleware, services visibility can be expressed using the OW2-Petals Master governance solution and automatically exposed to defined partners by the service bus. Finally, an online business processes editor is deployed in the cloud and fully connected to the infrastrucutre in order to provide a fully collaborative processes creation using BPMN standards.

Je parlerais donc de mes travaux sur le portage de notre pile SOA dans le Cloud et sur le travail que l’on fait depuis presque trois ans dans le cadre du projet SOA4All avec les gens de chez OW2/INRIA ProActive.

Le programme complet de la conférence est disponible sur le site d’OW2 (notez bien la Free Beer Party après mon talk, j’en aurais bien besoin pour décompresser), les autres slots sont tout aussi intéressants! Bref, encore une très bonne occasion de rencontrer des personnes passionnées et d’avoir de vrai discussions (IRC c’est bien mais F2F c’est mieux).

Pour info, nous présenterons aussi nos travaux actuels sur PRESTO et Petals ESB: French web service protocol for public administrations exchanges – an open-source implementation.

Image via Wikipedia

Et non IRC n’est pas un vieux protocole mort… Ce moyen de communication sert encore beaucoup dans le monde de l’open source (pour les plus vieux c’est un genre de Caramail mais pas pour draguer, enfin je crois…).

Niveau clients, il y en a des tonnes comme d’habitude. Sous Mac OS X je citerais Colloquy mais bien évidement, je suis un inconditionnel de Adium et il se trouve que la beta v1.4 propose un support sommaire mais suffisant d’IRC. La seule chose qu’il faut savoir c’est que utiliser IRC n’est pas tout a fait la même chose que de chatter via jabber ou autre. En gros avec IRC et Adium (pareil pour Colloquy), fermer sa fenêtre équivaut à se déconnecter du channel… C’est la qu’il faut être vigilant… L’autre difficulté vient du fait de trouver comment faire pour sauver ses channels préférées (il y en à des tonnes…).

Je profite que OW2 développe l’utilisation de ce canal de communication pour illustrer le présent article avec quelques captures relatives à l’ajout de channel en tant que contact Adium.

1. Joindre un channel (Je passe la partie connection à un serveur IRC…)

2. Blablabla

3. Sauver le channel en tant que contact: “Ajouter un signet à la Conférence” et choisir un nom de groupe pour ranger tout ça bien proprement…

Et voila, le channel apparaît dans la liste des contacts… Facile pour se reconnecter facilement quand on ferme la fenêtre sans faire attention!

Note : D’après une discussion que j’ai eu sur le channel IRC d’Adium, la v1.5 permettra de ne plus être déconnecté lors de la fermeture de la fenêtre… Pour le moment la 1.4 est toujours en beta depuis bien longtemps mais marche plutôt bien…

J’avais déjà essayé d’utiliser Automator il y a quelque temps et je n’avais pas eu le temps de me pencher dessus. Mais en fait c’est un outil extrêmement simple et puissant où l’on peut faire quasiment tout ce que l’on veut. En tant que novice, j’ai mis à peu près une heure à comprendre comment il marche et à pondre le script qui permet de renommer mes dizaines de milliers de fichiers (je reviendrais sûrement sur les possibilités d’Automator au travers d’exemples d’ici peu). En attendant, j’ai créé une page qui raconte où trouver et comment utiliser ce que j’appelle FileRenamr.

1. Monter son disque depuis Finder/Aller/Se connecter au serveur… Ne pas oublier de choisir l’option pour sauver le mot de passe.

2. Lancer Preferences Systeme/Comptes et choisir son compte. Sélectionner l’onglet Ouverture et glisser le nouveau disque réseau du bureau vers la fenêtre.

3. Il n’y a pas de 3…

UShareSoft delivers a software appliance factory, formally named UForge that provides a simple to use SaaS platform to create high quality business ready software appliances. Our mission is to make it easy for individual developers, communities, and professionals to deliver their software into easy to use physical, virtual and cloud images.

Pour résumer, les outils développés par cette société permettent de générer n’importe quelle image/Machine Virtuelle depuis une application SaaS. Plus besoin d’installer des tonnes de paquets et de se demander comment faire pour générer une image Amazon AMI, VMWare ou une ISO depuis une même source. Tout ce qu’il faut faire avec les outils de UShareSoft est de sélectionner la distribution cible, les paquets désirés, de rentrer les paramètres de configuration, de sélectionner les formats de sortie et de cliquer pour générer les images que l’on veut (Il sera bientôt possible de choisir les produits PetalsLink a intégrer dans les images sur leur application).

C’est bien sur une vision assez rapide et simpliste des outils, de nombreuses présentations plus avancées sont disponibles sur le site de USS et sur SlideShare. Contactez les, vous ne serez pas déçus!

La question : Comment sont ils arrivés là? Maven introspecte t-il les artefacts sur quelque repository ou une ame bienveillante les a ajouté au fichier de configuration du plugin archetype? J’opte plus pour la première réponse…

The W3C, the Web’s standardization consortium with a mission to lead the Web to its full potential, has today acknowledged WSMO-Lite, a technology submission led by KMi.

Developed within the EU project SOA4All, WSMO-Lite is a lightweight set of terms for describing the semantics of Web services that builds on the W3C standard SAWSDL. According to the W3C’s ownTeam comment, WSMO-Lite “is a useful addition to SAWSDL for annotations of existing services and the combination of both techniques can certainly be applied to a large number of semantic Web services use cases.”

Source KMi Planet News

Related Articles

• “WSMO-Lite: Lightweight Semantic Descriptions for Services on the Web” published as a W3C Member Submission (w3.org)
• W3C Semantic Web Interest Group (w3.org)

GeasyBPMN Editor est un produit issu du projet recherche Synergy auquel nous participons activement :

SYNERGY is a research project funded by the European Commission with the aim of developing dynamic and adaptive knowledge management systems and services to enable virtual organisations (VOs) to collaborate more easily.

Un des aouts majeurs de ce nouvel outil est sa capacité à travailler sur l’édition de façon collaborative via son interface réactive orienté Web2.0.
Le produit est bien sur releasé en Open Source sous license GNU Affero qui est la plus adapté pour ce genre d’outil et pour nous…  Tout les liens nécéssaires pour avoir plus d’informations et essayer le produit en ligne sont disponibles sur le site du projet.

Dans le cadre du thème Cloud Computing, je vais m’attaquer prochainement à l’intégration complète de ce produit dans la suite PetalsLink pour le Cloud, de bonnes choses en perspective dans les prochains mois… Plus d’information bientôt (il y a quand même pas mal de boulot pour ca)!

Pour nous, le but est ‘simple’. Pouvoir fournir des solutions SOA dans le Cloud. Comment? Vous le saurez évidement bientôt sur ce blog puisque je devrais leader cette thématique. En attendant, je viens de soumettre une proposition de présentation pour la prochaine conférence annuelle OW2 qui se tiendra à Paris en novembre. Le sujet, “Cloud aware large scale distributed SOA“, part des résultats que nous sommes en train de consolider dans le projet SOA4All et d’étendre à une approche Cloud. La suite bientôt…

Image via Wikipedia

Je profite de passer un peu de temps à aider les collègues de l’équipe produit sur le sujet des notifications dans Petals ESB qui est assez récent dans la suite Petals pour proposer un article sur une vision de haut niveau du support des notifications dans le bus de service distribué.

L’architecture et l’intégration

Je ne reviens pas ici sur l’architecture de Petals ESB basée sur JBI (il y a assez d’articles la dessus sur mon blog) mais je voudrais parler de l’architecture choisie pour fournir un support aux notifications dans Petals. Malgré tout le support JBI est important ici car cette intégration est basée sur l’aspect composants JBI de Petals. Pour rappel, un composant JBI est une sorte de plugin qui vient enrichir le container JBI en offrant des fonctionnalités supplémentaires en tant que connecteur protocolaire ou de moteur service (les fameux Binding Components et Service Engines).
L’intégration des notifications est donc exclusivement basée sur des composants JBI via des composants dédiés d’une part et via une intégration dans le Kit de Développement de Composants (CDK) développé au sein du projet.

Du point de vue des spécifications, il est choisit de fournir une implémentation des spécifications WS-Notification de chez Oasis. Une vision simpliste de cette spécification fait intervenir un broker (un intermédiaire intelligent) pour gérer et découpler les émetteurs de notifications et les destinataires. C’est sur ce broker que les émetteurs s’enregistrent, et c’est aussi sur lui que les destinataires informent qu’ils sont intéressés par uu/des types de notifications précises. Pour plus de détails, je vous recommande de jeter un coup d’oeil à la spec elle même ou à Googler le sujet.

Du point de vue de l’intégration, le broker est implémenté dans un composant JBI dédié, le petals-se-notification. Comme tout le travail se passe généralement dans les autres composants JBI, le CDK (qui est le support pour le développement des composants) propose une activation du support des notifications en tant que producteur. Cette activation implique un enregistrement envers le broker dès son démarrage. Malgré cette activation, si aucun producteur n’est enregistré au niveau du broker, il ne se passera rien! En effet, l’architecture actuelle force les consommateurs de notifications à informer le broker de leur interêt pour des notifications via un système de topics. Je passe vite la dessus mais en gros, lorsque le consommateur s’enregistre au niveau du broker, le broker va relayer cette demande avec un contexte associé aux producteurs de notifications. Une fois cette étape achevée, des échanges de messages standard provoqueront potentiellement des notifications envoyées au broker qui fera ensuite son travail de relai.

Les principaux points forts de cette intégration sont :

1. la possibilité d’utiliser ce médium de notifications pour tracer les échanges entre consommateurs et fournisseurs de services standards. Ces informations peuvent alors être remontées vers une console de BAM par exemple.
2. L’utilisation du canal JBI pour échanger les notifications. Pas de nouveau canal de communication à créer, tout passe par les couches de communications du bus de service. Comme Petals est un bus de service nativement distribué, cette approche est vraiment un point important.
3. Le support rapide via un CDK qui fournit toute la mécanique nécessaire pour implémenter ses producteurs et consommateurs de notifications.

Cette intégration a bien sûr des points faibles. Premièrement, il faut absolument que le composant qui fait acte de broker soit présent et robuste pour pouvoir gérer les notifications venant de N fournisseurs en tant que point central. Ensuite, ce broker doit (pour le moment) être unique dans le contexte du bus. En placer un autre sur un autre noeud du bus n’est pas possible actuellement (enfin si c’est possible mais des messages seront perdus).

La suite?

De nouveaux projets sont au programme en cette fin d’année avec pour but (un des buts plutôt) d’aller vers une architecture full EDA intégrée dans le coeur du bus. Cela va normalement supprimer les points négatifs cités précédemment avec notamment la suppression des composants JBI et le développement d’un broker distribué se basant sur l’architecture distribuée de Petals. Cela fera bien sûr de la matière pour les prochains articles de ce blog courant 2011.

En attendant, un prochain article portera surement sur quelque chose de plus technique avec un peu de code, je conseille de faire tourner la démo (disponible ici) qui met en oeuvre Petals ESB, Petals View et les notifications. Elle éclaircira mes dires, car le blahblah c’est bien, passer à l’action c’est mieux!

C’est peut être le fait de travailler en tant que développeur (entre autres) dans une startup cool et dans l’Open Source qui m’a emmené à pouvoir passer en mode télétravail, à vrai dire il semble que c’est un fonctionnement qui est de plus en plus fréquent (réduction des coûts, du stress, …) mais là n’est pas le sujet de l’article.

Evidemment, une des premières choses qui vient à l’esprit, c’est le gain de temps. C’est vrai j’économise à peu près 59 minutes de trajet par jour (en estimant que monter à l’étage le matin et en descendre le soir me prend 1 minute, ce qui est large!). Ce stress là est épargné: plus de voiture, de métro et de marche dans un environnement pollué pour rejoindre les bureaux du centre Toulousain.
Par la suite, ce gain de temps augmente au cours de la journée : Plus besoin de faire le tour des bureaux pour dire bonjour à tout le monde (non je ne suis pas sauvage), connecter son client de messagerie est suffisant; plus de perturbation par les discussions du bureau d’à coté sur le match de la veille, plus besoin de repasser les habits, etc… Au final j’estime que le cumul doit tourner autour des 1h30 à 2h par jour… Donc au final, sur une journée, le choix est possible entre travailler moins de temps effectif pour un rendement équivalent ou vraiment travailler les 8 heures syndicales… Je dirais que ça dépend des jours dans mon cas…

Ensuite effectivement, l’environnement de travail à la maison est plus calme que celui du bureau. Bon il faut dire que j’habite dans un lotissement très calme, pas de bruit, pas de passage de voiture, les enfants jouent de temps en temps dans la rue mais ce n’est pas ça qui peut me déranger. On est généralement tous d’accord, que travailler dans un environnement calme permet d’être productif. Aujourd’hui je ne suis plus obligé de mettre mon casque et écouter de la musique en continue pour masquer les autres bruits… Un point positif de plus… Ah oui, je pense qu’il est important d’avoir  son bureau dédié, dans une pièce séparée et ne pas avoir à travailler dans le salon ou dans la chambre… Finalement, la seule chose qui me manque vraiment, c’est la clim! L’été dans le sud c’est un peu rude… Bon, pour palier à ça, j’ai un frigo plein de glaces, je travaille en short et le soir je peux aller piquer une tête à la mer.

Il est aussi important d’établir des règles avant de quitter les bureaux de la société. Que ce soit pour le matériel, les frais et compagnie. La chose la plus importante est le contact avec les collaborateurs et la hiérarchie. La messagerie instantanée est efficace pour poser les questions et être questionné par la même occasion. Elle ne remplace pas les discussions de bureau mais je fais souvent des breaks en parlant avec quelques collègues, je vais à la chasse aux potins car dans mon bureau, il ne se passe rien… La règle la plus importante reste la périodicité de ‘visite’ dans les locaux de la société. Il est pour moi très important de pouvoir discuter de visu, échanger, faire des réunions, voir les gens, … Tout ça car les discussions par mail ne sont pas aussi faciles qu’elles en ont l’air. Un courrier électronique c’est bien, par contre ce qu’il manque c’est l’intonation… Des choses qui ne devraient pas être mal prises le sont souvent, au bout de la 3eme réponse on s’aperçoit que le contenu n’a plus rien à voir avec le sujet initial… Bref, la communication électronique à aussi ses inconvénients. Le téléphone reste le meilleur outil pour ça!

Et la rigueur alors? Je pense que ce mode de travail ne peut être compatible qu’avec une certaine rigueur? Dès le début, l’important est de s’imposer des heures de bureau et de s’y tenir sinon il me semble que l’on peut très vite dévier sur des horaires décalées non compatibles avec une vie de famille digne de ce nom. Non je ne travaille généralement pas le soir car j’ai aussi une famille et une vie extra professionnelle. D’ailleurs celle ci s’est étoffée et s’étoffe encore… J’ai du temps en plus, donc je me suis vraiment remis au sport (pour compenser la sédentarité), j’ai repris les activités que j’avais délaissé comme la photo… Je me suis même mis au jardinage (la première récolte de tomates est prometteuse).

Dernier point : il faut être proactif! Toujours être à l’affût, ne pas se faire oublier, faire des propositions, réagir aux mails… De ma faible expérience, il me semble que des fois les gens pensent que je ne fais plus partie de la société. Non, j’ai toujours le même statut, je fournis toujours un travail conséquent, je pars toujours en déplacements (et ça fait du bien de sortir de ma maison), je rapporte toujours de l’argent à la société et donc je suis toujours un employé comme les autres. Je ne veux pas que l’on me laisse dans mon coin être un emploi fictif! Je ne veux pas aussi me reposer sur mes lauriers, dans notre monde de développeur il faut toujours être actif, de remettre en question, apprendre de nouvelles choses que ce soit par le biais des projets sur lesquels on travaille, ou de façon personnelle avec de l’auto-formation.

Voilà un tour d’horizon rapide de ses premiers gros six mois de télétravail, pour moi le bilan est plutôt positif et je pense continuer sur cette lancée. La suite de mes aventures de télétravailleur  geek sûrement bientôt!

Plus besoin de s’embêter, ni même de réfléchir, convertir n’importe quelle unité de temps vers n’importe quelle unité de temps est simple :

long days = TimeUnit.DAYS.convert(22545455566L, TimeUnit.MILLISECONDS);

ie 22545455566 ms sont équivalentes à 260 jours.

C’était la pensée du jour : “Coder c’est bien, avec les commentaires intelligents c’est mieux”

Note : Ce travail se base sur Petals ESB 3.0.2 mais est normalement compatible avec la v3.x. Tout le code est disponible sur le SVN du projet Petals ESB chez OW2 (le lien plus bas) et je ne l’ai pas inséré dans l’article car l’intérêt n’est pas de montrer que je sais coder en Java…

Le contexte

Petals ESB v3.x est livré avec une couche de transport permettant de faire communiquer les instances du bus de service basée sur une implémentation Java NIO. Le but de l’article est de présenter un framework de couche de transport et de montrer que développer une nouvelle couche en se basant sur le framework est simple et rapide.

Le framework

Le but n’est pas de détailler complètement le framework, mais juste les points d’extension qu’il offre. Le framework gère la logique d’envoi synchrone et asynchrone des messages, ce qu’il reste à implémenter est finalement juste la partie permettant de recevoir des messages (ie le serveur) et d’envoyer les messages sur le noeud distant (indépendamment de la logique Petals).

• Le serveur: Il doit être capable de recevoir un message de la forme de son choix (tout dépend du protocole utilisé) et d’informer le framework qu’un nouveau message est recu après l’avoir converti en message Petals (ici JBI), rien de plus…
• Le client: Doit pouvoir retrouver le serveur à appeler et lui envoyer le message après avoir transformé le message Petals (JBI) en message serveur-dépendant.

Le  framework est basé sur une abstraction de la couche de transport Java NIO de Petals ESB v3 et son code source est disponible dans ma sandbox dans les projets petals-transport-api et petals-transport.

Une implémentation Web service?

Oui parce que c’est la plus rapide et qu’elle est bien utile! Allez pour faire encore plus simple (et pour ne pas changer une équipe qui gagne), on va utiliser JAXWS & Apache CXF.

1. Le coté serveur

Il est en charge de démarrer le service de réception de messages, ici on va utiliser JAXWS pour exposer une instance de org.ow2.petals.transport.cxf.TransportServiceImpl qui implémente org.ow2.petals.esb.api.TransportService.

L’implémentation cré un message JBI depuis le message reçu par la pile Web service (via la méthode/opération #receive), et passe ce message au Receiver en appelant l’unique méthode #onMessage(MessageExchange). Le receiver n’est ici rien d’autre que le composant de transport du Framework (org.ow2.petals.transport.TransporterImpl dans le module petals-transport) qui implémente le service de transport de Petals ESB (org.ow2.petals.transport.Transporter) et qui possède l’intelligence pour faire remonter le message dans les couches de Petals ESB.

2. Le coté client

Ici aussi, rien de bien méchant. Il suffit de savoir créer un client Web service pour parler au serveur que l’on vient de présenter au point 1. Une fois encore, JAXWS et CXF font ca bien. Une factory est à implémenter (org.ow2.petals.transport.api.ClientFactory) et permet de créer des instance du client pour chaque container Petals ESB à invoquer.

3. What else?

Un peu de configuration via Fractal et le tour est joué. Une nouvelle couche de transport permet de faire communiquer les instances de Petals ESB via Web service au lieu de passer par NIO, tout cela avec quelques classes…

Et alors?

Avec quelques classes (même pas une dizaine, dans le meilleur des cas implémenter 4 interfaces doit être suffisant), on peut créer un nouveau type de transporter pour Petals ESB sans se soucier de :

1. JBI. Ou presque la seule chose à faire est créer un message JAXWS depuis un message JBI et inversement (ca va il y a plus dur…)
2. La logique de message synchrone et asynchrone. Tout cela est géré par le framework.
3. La remontée du message vers le bon fournisseur de service.

On focalise ici vraiment sur la partie communication pure entre client et serveur. Pour valider le principe d’implémentation facile et rapide, j’ai créé un transporteur XMPP en à peu près un jour… Le code de ce transporteur XMPP n’est pas encore public mais ca ne devrait pas tarder. Il me faut juste un peu de temps…

Tout cela pour montrer qu’utiliser Petals ESB n’est pas limitant. L’architecture permet quand même des points d’extension intéressants, il faut juste s’y connaitre un peu (beaucoup). C’est juste notre métier…

If you can walk into any library or Internet cafe and sit down at any computer without preference for operating system or browser and access a service, that service is cloud-based.

… de Cloud Applications Architecture chez O’reilly

Ca ne rentre pas sur mon Twitter et je pense que c’est une bonne définition à partager!

C’est la dernière ligne droite puisque le projet est dans sa dernière année (bien entamée), et il reste encore des choses intéressantes à faire. La plus ambitieuse est surement l’intégration finale de OW2 Petals ESB et de OW2 Proactive pour créer un Bus de Service Distribué et Fédéré via un Framework de fédération maison.
Un article sur les concepts de la fédération est disponible au téléchargement. Les premiers tests de déploiement sur le Cloud pour créer une fédération sur Internet entre différents providers (Amazon EC2, Grid5000, …) et de performance nous permettent d’être assez satisfait du prototype actuel.

Mais comme on est jamais assez satisfaits, la suite réserve encore et surement beaucoup de bonnes choses que ce soit pour SOA4All ou pour les projets de recherche a venir.

Petit tour sur le toit de la cathédrale - Duomo

1. Avoir l’obligation de créer un composant spécifique par service à exposer
2. Avoir l’obligation d’implémenter une interface spécifique (KernelWebService)
3. Avoir l’obligation de décrire et de binder le service dans les fichiers de description ADL

Disons que cette approche est finalement assez simple mais devient vite lourde lors que l’ajout de services. La solution du jour va supprimer les 3 points cités ci dessus. Comment?

1. Un composant implémentant une interface annoté en JAXWS doit être la condition suffisante pour être exposé en Web service
2. Un composant spécifique est en charge d’exposer les composants Fractal qui satisfont la condition 1.

Le composant introduit dans le point 2 ci dessus, que l’on appellera le WSM (‘Web service Manager’) est le composant qui introspecte le composite Fractal dans lequel il est instancié. Il a ainsi la visibilité des composants qui implémentent une interface annotée en JAXWS et peut l’exposer, ici en utilisant Apache CXF.
En allant plus loin, on peut facilement imaginer avoir un WSM de haut niveau qui peut se balader dans l’arbre complet du modèle Fractal et exposer tout les services du bus (ou une partie que l’on juge intéressante par filtrage).

Note pour l’équipe : Ce code est disponible sur la forge de mon projet recherche, disponible sur demande

En pratique, les domaines sont complètement indépendants, ils ne sont aucunement connectés via Internet ou toute autre connection alternative. Dans cette première itération sur la fédération, il n’y a pas de notion de hierarchie en domaine et sous domaine. Un noeud d’un domaine peut demander à la fédération une résolution de endpoint et aussi envoyer un message à des endpoints de la fédération pour invoquer des services. Une vue de haut niveau sur deux noeuds dans deux domaines différents est la suivante :

Techniquement, l’intégration de la fédération intervient à plusieurs niveaux :

1. Chaque noeud implémente le service de fédération qui permet de donner un point d’entrée à la fédération. Ce service expose une opération de recherche de endpoint et une opération d’invocation de service.
2. Chaque noeud s’enregistre dans la fédération en donnant un callback (ici c’est le point d’accès au service exposé en 1 qui est publié dans la fédération).
3. Un module de fédération permet de faire une recherche de endpoint dans la fédération. Dans le cas de Petals, c’est un module du routeur (cf cet article sur les modules) qui permet de faire cette recherche.
4. Une implémentation au niveau fédération de la couche de transport permet d’aller invoquer un service de la fédération.

Une première approche simple (et pas forcément efficace) est de laisser le module de routage faire une requête à la fédération à chaque invocation pour trouver une liste de endpoints qui peut répondre à la requête, une version plus évoluée permettrait d’avoir un cache à un niveau intermédiaire (pas si évident en fait dans une approche très dynamique). A voir…

En attendant, un premier prototype permets de faire communiquer des noeuds appartenant à des domaines différents sans que ceux ci est une connaissance des autres noeuds (au niveau de Petals ESB, les noeuds des domaines ne sont pas renseignés au niveau du service de topologie). La vidéo qui suit montre deux noeuds, un sur mon laptop et un autre sur un serveur OVH. Je n’ai ouvert aucun port sur ma Box, sur mon laptop ou sur le serveur pour faire passer du trafic supplémentaire : C’est un des avantages à utiliser XMPP.
Le scénario est simple, un client sur mon laptop veut invoquer un service qui fournit une interface X. Cette interface X n’est fournie par aucun service localement (d’ailleurs on voit bien qu’il n’y a pas de endpoint sur le container coté client). Et la magie, il existe un endpoint dans la fédération qui fournit cette interface et il se trouve que cet endpoint est sur le container tournant sur le serveur OVH.
Et alors? Ca a l’air bête comme çà mais on arrive quand même à récupérer la référence du endpoint distant et à invoquer le service sans avoir besoin d’ouvrir quoi que ce soit, de faire du polling ou autre. Merci XMPP.
Comment? Pour dire simple, chaque noeud se connecte sur un serveur XMPP. En pratique c’est un peu plus compliqué et je laisse ca pour un prochain article!

Les premiers tests n’ont rien a voir avec la fédération mais valident que l’on peut utiliser une couche de transport générique que j’ai développé (et que je détaillerais dans un futur article) pour rapidement implémenter un transport utilisant le protocole désiré, ici XMPP. Le schéma suivant donne une vision de haut niveau de cette architecture et du cas d’usage :

Description du scénario ci dessus:

• Chaque noeud est connecté à GTalk avec un compte dédié
• Un service est lié à Petals ESB, disons que c’est un Web service bindé avec le composant SOAP (Proxy Out)
• L’endpoint ainsi présent dans Petals ESB est exposé sous forme de Web service par le composant SOAP sur l’autre container (Proxy In)
• Tout client envoyant une requête au service via le Proxy In voit sa requête traverser les différentes couches de Petals jusqu’à arriver à la couche de transport. La communication avec le container cible se fait grâce à la notion de Chat de Jabber. Un Chat est créé entre le container 1 et le container 2 et le message contenant la requête est alors publié au container 2 via le Chat.
• Le container 2 reçoit le message et le fait remonter jusqu’au service final. La réponse prends le chemin inverse.

On profite aussi de l’archivage des communications Gtalk :

Evidemment, passer par GTalk pour invoquer des services d’un même domaine est pénalisant et l’intérêt est assez limitée car la communication entre les noeuds ne se fait pas uniquement via la couche de transport (la recherche de endpoints passe par un canal différent par exemple). Et c’est la que la fédération du Bus va entrer en jeu. La suite donc au prochain numéro.

Dans le précédent article de la série, j’ai présenté globalement les concepts de routage de message et comment la couche de routage de Petals ESB pouvait être étendue à moindre frais. Aujourd’hui, nous allons regarder de plus prêt pourquoi Petals est vraiment un Bus de Service Distribué avec un grand ‘D’ depuis qu’il est arrivé sur le marché des ESBs Open Source.

Blablabla et bla!

Dans l’article précédent, nous avons vu que la couche de routage était traversée par le message et que en sortie, nous obtenions toutes les informations nécessaires sur les endpoints et sur le contexte du message. Comment maintenant envoyer ce message au bon endpoint? Rien de pus simple, en effet, chaque endpoint contient les informations sur le service, son interface mais aussi sa localisation. Dans les données de localisation, le domaine, le nom du container et le nom du composant destinataire attachés au endpoint sont présentes. Rien de plus simple alors pour la couche de transport, il suffit de :

• En fonction du nom de container, il est possible de retrouver les informations sur ce container en invoquant le service de topologie. Ce service de topologie est capable de retourner la liste des informations nécessaires pour contacter une instance distante.
• Créer un client vers le container distant en fonction du protocole de transport
• Envoyer le message et attendre une réponse si besoin. Si une réponse est retournée, celle ci est encapsulée dans le message d’origine et le message repart en direction de la couche de routage. La couche de routage peut donc effectuer des opérations sur la réponse en fonction de modules de routage présents. Le message est finalement adressé au consommateur de service.

Et alors?

Et alors, contrairement aux autres ESB JBI du marché, il n’est pas nécéssaire d’utiliser des Binding Components et de les configurer pour invoquer des services distants. Un exemple de ce que cela implique est donné dans cet article sur DeveloperWorks. Avec Petals, on a ce que l’on appelle une vision unifiée du bus de service qui est distribué.

C’est tout?

Techniquement, Il y a eu beaucoup de tentatives pour implémenter un transporteur de messages digne de ce nom. Dans Petals V1, on avait un transport JMS basé sur OW2-Joram. Dans Petals V2, c’était un projet OW2 mort appelé Dream qui servait de couche de transport. Aujourd’hui dans la v3, le transport est assuré par une implémentation maison basée sur NIO très performante.
La performance c’est bien mais moi je préfère l’extensibilité. C’est pourquoi je proposerais bientôt une alternative à la couche de transport actuelle. Cette couche est très bien quand on se place au niveau de l’entreprise (le ‘E’ de ESB). Actuellement je travaille sur des sujets intéressants ou je remplacerais le ‘E’ par un ‘I’ pour Internet et même par ‘FD’ pour ‘Federated Distributed’. Quand on parle d’Internet, on imagine facilement que l’on doit se confronter aux Firewalls, à échanger les messages sur HTTP, en XML avec des notions de présence etc etc… La suite bientôt!

Monitoring

Management

La suite au prochain épisode…

Bref, des tonnes de choses intéressantes sont en cours, je pense bientôt publier un papier technique sur un site à grande audience sur ce genre d’architecture en l’illustrant par une mise en oeuvre avec Petals ESB et d’autres technologies prometteuses. ‘So, stay tuned’!

This is a historic week for SOAP .. it was on April 26, 2000 that the SOAP v1.1 specification was published

“SOAP tu as 10 ans, tu es grand maintenant”. Bref, il va bientôt faire sa crise d’adolescence, alors profitons en avant que cela n’arrive!

JMX c’est bien pour manager une application Java mais il faut savoir parler JMX et généralement, parler à une application JMX via Internet c’est pas forcément le pied et encore moins quand l’administrateur réseau ne veut pas qu’il y ait autre chose qui rentre chez lui que du bon vieux HTTP et être ce que j’appelle ici ‘Firewall-Friendly’.

Pas Firewall-Friendly?

Bref, je milite ici sur l’utilité d’avoir une administration d’application générique qui peut être exposée dans la technologie et le protocole qui colle le mieux au contexte. Et la je parle principalement de ce que je connais le mieux : Petals ESB. Ce bus de service est fortement basé sur la spécification JBI. Il est tellement lié que l’administration du bus ne passe que par JMX, même pour effectuer des opérations internes au bus… L’administration ne doit donc pour moi être fournie que sous forme d’API et d’implémentation indépendante de toute technologie d’exposition. A charge du développeur de l’application de fournir les mécaniques adéquates pour exposer cette API en JMX, en Web Services, en REST, etc… Cela fera surement l’objet d’un article sur une mise en pratique de ce genre d’approche dans Petals.

Le but principal et original de cet article était de parler un peu de ce que l’on peut faire en terme d’administration et de monitoring du Bus Petals. Je travaille depuis quelques temps déjà sur un projet visant à créer une infrastructure de service largement distribuée sur Internet dans le cadre du projet de recherche SOA4All. Je viens de finir un prototype d’application Web qui permet de manager ces noeuds exposés sur Internet et d’effectuer quelques opérations qui ne sont pas disponibles dans une distribution standard de Petals (tout du moins l’API de base ne les fournies pas). Comment? Et bien forcément sans utiliser JMX (j’en suis assez allergique ce qui rajoute un allergène à ma liste déjà longue, en plus c’est le printemps…), mais plutôt en utilisant et en étendant l’API Web service que j’ai développé pour Petals 3.0. Cette application permet alors de se connecter à n’importe quelle instance de Petals (et à son réseau) exposée sur Internet via une API WS et ainsi de lier des services externes au bus, d’exposer des services internes, de voir ce qui se passe dans le bus et bien plus encore… Tout cela en utilisant GWT pour créer une application sympa avec des choses qui bougent car Petals à une activité qu’il faut pouvoir montrer en direct!

DSB Manager Portal

Ce studio de développement est une distribution Eclipse qui comprend les plugins de bases nécessaire à tout développeur et ajoute une partie spécifique à Petals ESB,la release note est brève mais donne envie d’en savoir plus :

Petals Studio 1.0 was released ! This is a small step for Petals and a cool step for developers. As the first stable release, Petals Studio 1.0 includes a lot of enhancements, which will make your Petals life easier and faster. Here are the main

• Unified Petals ESB Wizards
• Sketching for BPEL and SCA
• Organize the workspace by Projects or Services (endpoints)
• Text editor, with auto-completion, for JBI, SU and SA
• Extended validation for JBI, SU and SA
• Import existing WSDL with dependencies
• Project export
• Interaction with Petals ESB Server
• Compatible with Linux and Windows, 32 and 64 bit
• Bug fixes.

Alors pourquoi ne pas aller voir la documentation du studio pour en savoir plus et bien sur le télécharger et l’essayer?!

Le cas d’usage

Petals ESB est pleinement basé sur JBI est ne fournit pas forcément une API permettant d’exposer des services simplement. On pourrait imaginer avoir une API de management du style ‘bind(wsdlURI)’ où wsdlURI est l’URI du WSDL du service à lier au bus. La distribution de base ne fournissant pas ce genre d’API, il faut contourner cette lacune par l’utilisation de JBI et des APIs de management à distance.

La pratique et le code

Je passe sur la génération de Service Units et de Service Assemblies (des articles sont disponibles sur mon blog pur le faire avec des librairies Java ou avec le Petals Studio). Imaginons que nous ayons généré tout les artifacts JBI nécessaires coté client et que tous les composants JBI sont déjà installés sur le Bus. Comment soumettre ma SA au bus, et comment gérer son cycle de vie à distance?

package net.chamerling.blog.petalsclient;

import java.io.File;

import javax.activation.DataHandler;
import javax.activation.FileDataSource;

import org.ow2.petals.kernel.ws.api.DeploymentService;
import org.ow2.petals.kernel.ws.api.PEtALSWebServiceException;
import org.ow2.petals.kernel.ws.api.to.AttachmentDescriptor;
import org.ow2.petals.kernel.ws.client.PetalsClient;
import org.ow2.petals.kernel.ws.client.PetalsClientFactory;

/**
 * Sample which is using the petals-kernel-wsclient library
 *
 * @author chamerling
 *
 */
public class App {

	public static void main(String[] args) {

		try {
			// get a client
			PetalsClient client = PetalsClientFactory.getInstance().getClient(
					"http://localhost:7600/petals/ws", 20000);

			// 'upload' the SA in the artifact repository
			File saFile = new File("sa.zip");
			AttachmentDescriptor ds = new AttachmentDescriptor();
			ds.setAttachment(new DataHandler(new FileDataSource(saFile)));
			client.getArtifactRepositoryService().addArtifact(ds);

			// Deploy the SA and start it
			String saId = "my-sa-id";
			DeploymentService dClient = client.getDeploymentService();
			dClient.deploy(saId);
			dClient.start(saId);

		} catch (PEtALSWebServiceException e) {
			e.printStackTrace();
		}
	}
}

Tout est dans le code :

1. La SA est déposée dans le répertoire géré par le service d’artifact (par défaut, sous PETALS_HOME/artifacts/)
2. La SA est déployée depuis le répertoire cité en 1
3. La SA est démarrée.

Le code de l’exemple est disponible dans mon projet googlecode sous http://code.google.com/p/chamerling/source/browse/trunk/blog/petals-ws-client

Et alors?

Je suis en train de développer un module qui reroute les appels de service. L’adresse du service à appeler est donc mis à jour lors de la traversée du module en question. Pour faire bête, je me suis dit que j’aller spécifier un jeu d’adresses dans un bon vieux fichier de propriétés et que j’allais mettre ce fichier dans le module. OK, c’est bien, ça marche (heureusement…), je peux charger mon fichier dans le Handler du module et utiliser les adresses qui y sont définies.

Ce qui m’embête, c’est que ce fichier est packagé dans l’archive du module et donc non modifiable à souhait… C’est là que le Classloader d’Axis2 entre en piste. Si je mets un fichier avec le même nom dans les ressources de mon code client, celui ci est pris en compte en priorité lors de l’appel par le module de MonModule.class.getResource(“/foo.properties”); Je peux donc cette fois ci livrer un module générique qui inclus des valeurs par défaut et les clients qui utilisent ce module peuvent ‘overrider’ les valeurs par défaut dans leur propre fichier de configuration.

Encore une fois, merci Axis2.

Dans l’article précédent sur l’acheminement de messages dans Petals ESB, j’introduisais les notions, aujourd’hui nous allons regarder en détails la couche de routage du bus. Cette couche est largement appelée Router par les développeurs du Bus, et le sera donc dans cette article et dans la suite de la série.

L’archi simplifiée

L’architecture du Router utilise la notion très répandue et  fort utile de modules ie le Router invoque séquentiellement une liste de modules pour élire les services à appeller. A la fin de la traversée on se retrouve avec toutes les informations nécessaires pour appeler les services. On peut modifier cette liste en ajoutant ou supprimant des modules par configuration. Un schéma simplifié donne un Router avec cette tête :

Plus de détails sur l’utilisation des modules dans Petals et leur injection dans un vieil article (à non pas si vieux…).

L’implémentation

L’implémentation de base de Petals ESB est composée de 2 modules en émission :

1. Le module qui interroge le registre de services et retourne une liste de point d’accès (endpoint dans le jargon service) en fonction des informations contenues dans le message d’entrée.
2. Le module de résolution de la couche de transport. En fonction de la localisation des endpoints trouvés par le module précédent, un contexte est créé pour définir la couche de transport à utiliser (cette couche de transport sera détaillée dans le prochain article de la série).

On peut imaginer un grand nombre d’utilisations de ces modules. Personnellement, je les utilise à outrance par exemple pour :

• Ajouter des informations de timestamp sur les messages
• Notifier une couche de monitoring que des messages sont échangés entre consommateurs et fournisseurs de service
• Logger les appels
• Mettre à jour le choix de la couche de transport avec ma propre implémentation du transport de messages inter container
• …

Outro

Vous en savez un peu plus sur le routage dans le bus de service Petals. il faut vraiment retenir que cette couche est vraiment extensible et customisable sans grand effort, en effet pas besoin de recompiler le coeur de Petals pour ajouter des fonctionnalités pour la résolution des endpoints. Dans le prochain article de la série, nous regarderons de plus prêt comment sont échangés les messages entre les instances de Petals.

Je commence ici une petite série d’articles sur l’acheminement  de messages dans Petals ESB pour décrire d’abord simplement et par la suite plus techniquement (avec du code ) comment le message se balade dans le bus de services lors de l’invocation de services. Cette invocation passe par plusieurs étapes, qui sont ‘customisables’ et extensibles facilement pour répondre à des besoins distincts, on verra cette partie plus tard…

Le blahblah

On le dit depuis la première version de Petals ESB, Petals est Le bus de services distribué qui implémente la spécification JBI. Ici distribué signifie que des instances du bus de service sont lancées sur des hotes distincts et que du point de vue de l’utilisateur, cela est totalement transparent ie l’utilisateur n’a rien à configurer de plus qu’un fichier de description du réseau (contrairement aux concurrents où l’on doit généralement configurer des composants JBI pour exposer des services). On ne se place pas ici à un transport de messages au niveau applicatif mais vraiment à un niveau (abstrait) de transport. Pour être plus clair, l’architecture de Petals ESB est divisée en couches et pour faire simple on a :

1. Le canal de communication. Le canal de communication est la couche d’accès utilisée au niveau des composants JBI et donc au niveau des consommateurs et fournisseurs de services. Lors de l’invocation d’un service, le composant qui invoque un service envoi un message au canal. Le canal possède aussi tout un jeu de ‘listeners’ qui permettent de recevoir des messages de la couche de niveau N-1 (ie la couche de routage) en mode fournisseur de services.
2. La couche de routage. En mode consommateur de service, cette couche reçoit le message du canal de communication et est chargé de trouver le point d’accès (endpoint) à qui le message doit être envoyé. Cet endpoint peut être local ou distant (sur un autre instance de Petals ESB). Elle permet aussi une remontée du message vers le bon canal de communication et donc vers le bon fournisseur de service en mode fournisseur.
3. La couche de transport. Cette couche reçoit le message et le endpoint auquel le message doit être envoyé. Elle envoi ce message au endpoint, qu’il soit local ou distant. La couche de transport gère bien sûr la réception des messages envoyés depuis les instances distantes pour l’invocation des services qui se trouvent sur l’instance locale.

La suite

Dans les prochains articles, je détaillerais les couches de routage et de transport, leurs features, leurs points d’extensions, etc, etc… Et avec peu de code, on verra que l’on peut customizer Petals ESB.

…ou comment se battre quelques heures avec les ClassLoaders…

Le contexte

J’aimerais bien pouvoir démarrer une WebApp depuis un Jetty embarqué dans mon application et rendre accessible des objets de mon application dans la WebApp.

Le problème

Mon application et ma WebApp ont deux ClassLoaders bien distincts = Problème de ‘ClassCastException’

L’explication de la solution

Pour ma part, l’application en question qui va démarrer la tambouille et partager des objets est le bus de service Petals. La WebApp, elle, est développée comme une WebApp classique, elle n’a pas de lien avec mon application sinon une interface, que je qualifierais, d’échange.

L’implémentation de cette interface est injectée par mon application dans le contexte de la WebApp. Les problèmes commencent ici. En fait le seul problème est un soucis de ClassLoader. En effet, dans la WebApp, le ClassLoader est créé avec le contenu de WEB-INF/lib/*, de WEB-INF/classes/* et du ClassLoader du container Web (on fait souvent le similaire pour expliquer le ClassLoader d’un composant JBI dans le container JBI Petals). Des ressources créées dans mon application ont (généralement mais pas toujours) un ClassLoader spécifique à l’application. Si je les injecte dans la WebApp via le ServletContext, que je les récupère et que j’essaie de les ‘caster’, je me retrouve avec un beau ClassCastException du style ‘foo.Bar cannot be cast to foo.Bar‘. Les personnes développant des applications standard, ne se soucient généralement pas des histoires de ClassLoader et peuvent donc rester perplexes devant un message de la sorte. Quand on développe un container de n’importe quel type, on se dit que la il y a un soucis de ClassLoader ie on essaye de ‘caster’ une ressource qui n’a pas le même ClassLoader que celui du Thread courant. Si on regarde plus finement en passant en mode debug ce qu’il se passe lorsque l’on fait quelque chose du style :

Bar bar = (Bar)o;

On s’aperçoit bien que la JVM va appeler la méthode loadClass(String className) du ClassLoader à un moment où à un autre et que là ca va poser problème. La solution à notre problème est simplement de créer notre propre ClassLoader et ‘d’overrider’ loadClass(String className) intelligemment pour pouvoir enfin accéder à nos objets dans notre WebApp.

Le code

Disons que j’ai une classe foo.BarImpl qui implémente foo.Bar. Je veux passer une instance de cette classe BarImpl à ma WebApp via le contexte de l’application Web (quelques commentaires dans le code suivant).

package foo.bar.myapp;

import java.io.File;
import java.io.IOException;

import org.mortbay.jetty.Server;
import org.mortbay.jetty.webapp.WebAppContext;

public class MyApp {

       public void startServer() Exception {

        File webapp = new File("mywebapp.war");

        if ((webapp == null) || !webapp.exists()) {
            throw new Exception("Can not find the Web application");
        }

        this.server = new Server(9999);
        WebAppContext context = new WebAppContext();
        context.setContextPath("/");
        context.setWar(webapp.getAbsolutePath());

        Foo foo = new FooImpl();
        try {
            // create classloader with current object classloader
            MyClassLoader classloader = new MyClassLoader(foo.getClass()
                    .getClassLoader(), context);
            context.setClassLoader(classloader);
        } catch (IOException e1) {
        }
// put the object in the Jetty context ie in the servlet context
        context.getServletContext().setAttribute("foo", foo);
        context.setAttribute("foo", foo);

        this.server.setHandler(context);
        try {
            this.server.start();
        } catch (Throwable e) {
        }
    }
}

La subtilité dans le code précédent est l’utilisation de ‘MyClassLoader‘. Ici ‘MyClassLoader‘ étend ‘org.mortbay.jetty.webapp.WebAppClassLoader‘ et redéfinit la méthode ‘loadClass(String name)‘ de la facon suivante:

   @Override
    public synchronized Class loadClass(String name) throws ClassNotFoundException {
        Class result = null;
        try {
            result = this.myAppClassLoader.loadClass(name);
        } catch (Exception e) {
        }
        if (result == null) {
            result = super.loadClass(name);
        }
        return result;
    }
<pre>

Où on a ‘myAppClassLoader‘ qui est le ClassLoader de mon application que j’ai passé lors de l’instanciation de mon ClassLoader (dans le listing 1 : foo.getClass().getClassLoader()).

De l’autre coté j’ai une Servlet qui peut maintenant récupérer l’objet stocké dans le contexte sous l’attribut nommé ‘foo‘ sans problème de ClassCastException, par exemple dans la méthode ‘init‘ de la Servlet :

    @Override
    public void init() throws ServletException {
        Object o = this.getServletContext().getAttribute("foo");
        if (o != null) {
            Foo foo = null;
            try {
                foo = (Foo) o;
            } catch (RuntimeException e1) {
            }
        } else {
        }
    }

Le mot de la fin

En me mettant d’accord sur le contract de l’objet d’échange, je peux développer une application Web indépendamment, travailler avec un mock en mode test et basculer finalement sur mon application le moment venu. Finit aussi les appels Web service ou JMX locaux pour accéder à l’application qui lance le container Jetty, c’est plus propre, plus rapide, bref c’est mieux et ca marche!

l’API du kernel de Petals propose l’interface org.ow2.petals.kernel.api.server.PetalsStateListener :

package org.ow2.petals.kernel.api.server;

/**
 * Listener notified when a Petals container finish to start or to stop.
 */
public interface PetalsStateListener {

    /**
     * Callback method on PEtALS start up
     */
    void onPetalsStarted();

    /**
     * Callback method on PEtALS stop
     *
     * @param success
     *            {@code true} if PEtALS has stopped successfully
     * @param exception
     *            the exception if the stop has failed, {@code null} otherwise
     */
    void onPetalsStopped(boolean success, Exception exception);
}
<pre>

Cette interface n’est malheureusement utilisée que statiquement et une seule fois pour informer le ‘launcher’ que le kernel est bien démarré. On a pourtant org.ow2.petals.kernel.api.server.PetalsServer qui définit la méthode addPetalsStateListener(PetalsStateListener). je vais donc utiliser cette API et modifier simplement l’implémentation de org.ow2.petals.kernel.api.server.PetalsServer pour ajouter des listeners qui seront appelés lors du démarrage et de l’arrêt de Petals.

Pour ce faire deux approches sont possibles :

1. Rechercher tous les composants Fractal qui implémentent org.ow2.petals.kernel.api.server.PetalsStateListener
2. Créer un manager qui contient une liste ordonnée de tous les org.ow2.petals.kernel.api.server.PetalsStateListener

On va ici se pencher sur la solution 2 car la solution 1 ne permet d’ordonner facilement les listeners à appeler (ca peut valoir le coup de les appeler dans un sens bien définit!).

1/ Le manager de listeners

Simplement un composant Fractal qui détient la liste des listeners définis. Ces listeners sont définis par configuration dans les fichiers ADL de Petals. Son interface :

package foo.bar.petals.kernel.listener;

import java.util.Set;

import org.ow2.petals.kernel.api.server.PetalsStateListener;

/**
 * @author chamerling - eBM WebSourcing
 *
 */
public interface LifeCycleListenerManager {

    /**
     * The binding prefix of the component which is listening petals state
     */
    static final String PREFIX = "petals-state-listener-";

    /**
     * Get an ordered set of listeners
     *
     * @return
     */
    Set<PetalsStateListener> getListeners();

}

et son implémentation :

package foo.bar.petals.kernel.listener;

import java.util.HashSet;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import org.objectweb.fractal.fraclet.annotation.annotations.FractalComponent;
import org.objectweb.fractal.fraclet.annotation.annotations.Interface;
import org.objectweb.fractal.fraclet.annotation.annotations.LifeCycle;
import org.objectweb.fractal.fraclet.annotation.annotations.Monolog;
import org.objectweb.fractal.fraclet.annotation.annotations.Provides;
import org.objectweb.fractal.fraclet.annotation.annotations.Requires;
import org.objectweb.fractal.fraclet.annotation.annotations.type.Cardinality;
import org.objectweb.fractal.fraclet.annotation.annotations.type.Contingency;
import org.objectweb.fractal.fraclet.annotation.annotations.type.LifeCycleType;
import org.objectweb.util.monolog.api.Logger;
import org.ow2.petals.kernel.api.server.PetalsStateListener;
import org.ow2.petals.util.LoggingUtil;

/**
 * @author chamerling
 *
 */
@FractalComponent
@Provides(interfaces = { @Interface(name = "service", signature = LifeCycleListenerManager.class) })
public class LifeCycleListenerManagerImpl implements LifeCycleListenerManager {

    @Monolog(name = "logger")
    private Logger logger;

    private LoggingUtil log;

    @Requires(name = PREFIX, signature = PetalsStateListener.class, cardinality = Cardinality.COLLECTION, contingency = Contingency.OPTIONAL)
    private final Map<String, Object> listeners = new Hashtable<String, Object>();

    @LifeCycle(on = LifeCycleType.START)
    protected void start() {
        this.log = new LoggingUtil(this.logger);
        this.log.debug("Starting...");
    }

    @LifeCycle(on = LifeCycleType.STOP)
    protected void stop() {
        this.log.debug("Stopping...");
    }

    /**
     * {@inheritDoc}
     */
    public Set<PetalsStateListener> getListeners() {
        HashSet<PetalsStateListener> result = new HashSet<PetalsStateListener>();
        if (this.listeners != null) {
            Iterator<String> iter = this.listeners.keySet().iterator();
            while (iter.hasNext()) {
                String key = iter.next();
                Object o = this.listeners.get(key);
                if (o instanceof PetalsStateListener) {
                    result.add((PetalsStateListener) o);
                } else {
                    // warning
                    this.log.warning(o + " is not an instance of "
                            + PetalsStateListener.class.getCanonicalName());
                }
            }
        }
        return result;
    }
}

A noter que la Map ‘listeners’ est remplie par Fractal au démarrage de Petals.

2/ Modification de PetalsServerImpl

Dans org.ow2.petals.kernel.server.PetalsServerImpl je rajoute la méthode initListeners() :

   private void initListeners() {
        // get the component which owns the listeners
        Component listenerManagerComponent = FractalHelper.getRecursiveComponentByName(
                this.petalsContentController, Constants.FRACTAL_LISTENERS_MANAGER);
        if (listenerManagerComponent != null) {
            try {
                LifeCycleListenerManager manager = (LifeCycleListenerManager) listenerManagerComponent
                        .getFcInterface("service");

                if (manager != null) {
                    Set<PetalsStateListener> listeners = manager.getListeners();
                    for (PetalsStateListener petalsStateListener : listeners) {
                        this.addPetalsStateListener(petalsStateListener);
                    }
                } else {
                }
            } catch (Exception e) {
            }
        }

    }

Ce code permet de retrouver mon ‘listener manager’ (puisque PetalsServerImpl n’est pas ‘Fractalisé’) et de remplir la liste des listeners. Allez maintenant, on va dire que j’appelle cette méthode d’initialisation juste avant d’appeler les listeners (dans start() de PetalsServerImpl):

    public void start() throws PetalsException {
        // get listeners which have been defined by configuration (Fractal)
        this.initListeners();

        // notify the listener if there is one
        for (PetalsStateListener petalsListener : this.petalsListeners) {
            petalsListener.onPetalsStarted();
        }
    }

3/ Configuration des listeners

Dans les fichiers de définition des composants Fractal, je peux maintenant instancier mes listeners et les ajouter à la liste des listeners gérée par le manager de listeners :

	<!-- lifeCycle Listeners -->
	<component definition="foo.bar.petals.kernel.FooService" name="Foo" />
	<component definition="foo.bar.petals.kernel.BarService" name="Bar" />

	<!-- Listeners manager -->
	<component definition="eu.soa4all.dsb.petals.kernel.listener.LifeCycleListenerManagerImpl" name="LifeCycleListenerManagerImpl" />

	<!-- Fill the map -->
	<binding client="LifeCycleListenerManagerImpl.petals-state-listener-foo" server="Foo.service" />
	<binding client="LifeCycleListenerManagerImpl.petals-state-listener-bar" server="Bar.service" />

Le composant foo.bar.petals.kernel.*Listener implémentent  org.ow2.petals.kernel.api.server.PetalsStateListener et sont ajoutés à la liste des listeners managés par LifeCycleListenerManagerImpl lors de la définition des liens (lignes ‘binding’). Tous les listeners ajoutés au manager doivent avoir une valeur de l’attribut client commençant obligatoirement par LifeCycleListenerManagerImpl.petals-state-listener- (remplissage de la Map par Fractal).

Facile et pratique, non?!

La spécification JBI est basée sur l’état de l’art des Web services et donc utilise WSDL pour la description des services ‘hostés’ ou liés à l’implémentation JBI. Petals ESB implémente (et étend – mais ça sera peut être l’objet d’un autre article sur le pourquoi du comment…) la spécification JBI depuis sa première version. Petals ESB est même certifié compatible JBI par SUN (RIP) après le passage du TCK JBI (Outil de test de compatibilité fournit par SUN). Bref, là n’est pas la question… Les descripteurs JBI servent à beaucoup de choses dans une implémentation JBI mais nous allons particulièrement regarder comment nous nous en servons dans l’exposition de services.

Un service exposé dans le bus fournit donc sa description via un WSDL associé. Ce service est activé dans le bus après le déploiement de ce que l’on appelle communément une ‘SA’ (Service Assembly) qui contient des ‘SU’ (Service Unit). Pour exposer un service dans le bus afin qu’il soit accessible à tout les consommateurs, la SU doit être en mode ‘provide’ ie fournisseur. Elle doit aussi définir le Endpoint, le Service et l’Interface qu’elle veut exposer. Prenons l’exemple du bon vieux service HelloWorld définit par le WSDL suivant :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:definitions name="HelloServiceImplService" targetNamespace="http://sample.petals.ow.org/" xmlns:ns2="http://schemas.xmlsoap.org/wsdl/" xmlns:ns3="http://schemas.xmlsoap.org/wsdl/soap/"
	xmlns:ns9="http://www.w3.org/ns/wsdl/http" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns5="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:ns6="http://schemas.xmlsoap.org/wsdl/http/"
	xmlns:ns10="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:ns7="http://www.w3.org/ns/wsdl" xmlns:ns8="http://www.w3.org/ns/wsdl/soap">
	<ns2:types>
		<xs:schema elementFormDefault="unqualified" attributeFormDefault="unqualified" targetNamespace="http://sample.petals.ow.org/">
			<xs:element name="sayHello" type="tns:sayHello" xmlns:tns="http://sample.petals.ow.org/" />
			<xs:element name="sayHelloResponse" type="tns:sayHelloResponse" xmlns:tns="http://sample.petals.ow.org/" />
			<xs:complexType name="sayHello">
				<xs:sequence>
					<xs:element name="arg0" minOccurs="0" type="xs:string" />
				</xs:sequence>
			</xs:complexType>
			<xs:complexType name="sayHelloResponse">
				<xs:sequence>
					<xs:element name="return" minOccurs="0" type="xs:string" />
				</xs:sequence>
			</xs:complexType>
		</xs:schema>
	</ns2:types>
	<ns2:message name="sayHelloResponse">
		<ns2:part element="tns:sayHelloResponse" name="parameters" xmlns:tns="http://sample.petals.ow.org/" />
	</ns2:message>
	<ns2:message name="sayHello">
		<ns2:part element="tns:sayHello" name="parameters" xmlns:tns="http://sample.petals.ow.org/" />
	</ns2:message>
	<ns2:portType name="HelloService">
		<ns2:operation name="sayHello">
			<ns2:input message="tns:sayHello" name="sayHello" xmlns:tns="http://sample.petals.ow.org/" />
			<ns2:output message="tns:sayHelloResponse" name="sayHelloResponse" xmlns:tns="http://sample.petals.ow.org/" />
		</ns2:operation>
	</ns2:portType>
	<ns2:binding type="tns:HelloService" name="HelloServiceImplServiceSoapBinding" xmlns:tns="http://sample.petals.ow.org/">
		<ns3:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
		<ns2:operation name="sayHello">
			<ns3:operation style="document" soapAction="" />
			<ns2:input name="sayHello">
				<ns3:body use="literal" />
			</ns2:input>
			<ns2:output name="sayHelloResponse">
				<ns3:body use="literal" />
			</ns2:output>
		</ns2:operation>
	</ns2:binding>
	<ns2:service name="HelloServiceImplService">
		<ns2:port binding="tns:HelloServiceImplServiceSoapBinding" name="HelloServiceImplPort" xmlns:tns="http://sample.petals.ow.org/">
			<ns3:address location="http://localhost:9999/sample/HelloService" />
		</ns2:port>
	</ns2:service>
</ns2:definitions>
<pre>

Son descripteur JBI associé sera donc (lié a Petals via le composant Web service dans cet exemple) :

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
        xmlns:generatedNs="http://sample.petals.ow.org/"
        xmlns:jbi="http://java.sun.com/xml/ns/jbi"
	xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
	xmlns:soap="http://petals.ow2.org/components/soap/version-4"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<jbi:services binding-component="true">
		<jbi:provides interface-name="generatedNs:HelloService"
			service-name="generatedNs:HelloServiceImplService"
			endpoint-name="HelloServiceImplPort">

			<!-- CDK specific elements -->
			<petalsCDK:timeout>60000</petalsCDK:timeout>
			<petalsCDK:wsdl>Service.wsdl</petalsCDK:wsdl>

			<!-- Component specific elements -->
			<soap:address>http://localhost:9999/sample/HelloService</soap:address>
			<soap:soap-version>11</soap:soap-version>
			<soap:add-root>false</soap:add-root>
			<soap:chunked-mode>false</soap:chunked-mode>
			<soap:cleanup-transport>true</soap:cleanup-transport>
			<soap:mode>SOAP</soap:mode>
		</jbi:provides>
	</jbi:services>
</jbi:jbi>

Où on respecte bien que :

1. JBI ‘endpoint-name‘ = Valeur de l’attribut ‘name’ du Port dans le WSDL
2. JBI ‘service-name‘ = Valeur de l’attribut ‘name’ du Service dans le WSDL (avec JBI Service NameSpace = targetNamespace du WSDL)
3. JBI ‘interface-name‘ = Valeur de l’attribut ‘name’ du PortType dans le WSDL (avec JBI Interface NameSpace = targetNamespace du WSDL)

Petals ESB v3.x ne vous insultera plus lors du déploiement de vos services. Une solution simple pour ne pas se faire insulter, est d’utiliser le Studio Petals qui facilite grandement la vie des développeurs!

Nous allons donc développer un module qui change dynamiquement l’URL de l’endpoint à appeler (on utilisera bien sûr Maven2 pour nous aider à créer et packager le projet…).

1. Créer le projet

Utilisons Maven2 pour créer un projet :

mvn archetype:generate

et je réponds bêtement a Maven quand il me pose des questions sur le groupId, l’artifactId, etc… Une fois créé, je génère le projet Eclipse associé et je l’importe (Eclipse fait aussi parti de mes grand amis) :

mvn eclipse:eclipse

Ill faut modifier le POM pour dire a Maven que l’on est en train de créer un projet qui n’est pas une librarie Java mais un module Axis2. Ceci est possible en spécifiant le type de projet dans le POM et en déclarant que l’on veut utiliser le plugin MAR fournit par Axis2 :

<project ...>

...

<groupId>foo.bar</groupId>
<artifactId>reroute</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>mar</packaging>

...

<dependencies>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.5.1</version>
</dependency>
</dependencies>

...

<build>
<plugins>
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-mar-maven-plugin</artifactId>
<version>1.5.1</version>
<extensions>true</extensions>
<configuration>
<moduleXmlFile>src/main/META-INF/module.xml</moduleXmlFile>
<includeDependencies>false</includeDependencies>
</configuration>
</plugin>
</plugins>
</build>
...
</project>

2. Business code

Créons maintenant notre handler (le module est en fait un handler Axis2 packagé dans une archive avec un descripteur de module). Pour faire simple, je vais étendre la classe AbstractHandler pour créer mon Handler de reroutage et remplacer le ‘target EPR’ par le nouveau (bien sûr on peut faire quelque chose de beaucoup plus évolué, on va dire qu’ici tout part vers un seul service) :

package net.chamerling.blog.axis2module.reroute;

import org.apache.axis2.AxisFault;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.context.MessageContext;
import org.apache.axis2.handlers.AbstractHandler;
import org.apache.axis2.util.LoggingControl;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * @author chamerling
 *
 */
public class ReRouteHandler extends AbstractHandler {
	private static final Log log = LogFactory.getLog(AbstractHandler.class);

	private static final String FINAL_EPR_PREFIX = "http://localhost:8082/petals/proxy/";

	/**
	 * {@inheritDoc}
	 */
	public InvocationResponse invoke(MessageContext messageContext)
			throws AxisFault {
		EndpointReference toEPR = messageContext.getOptions().getTo();
		String finalEPR = FINAL_EPR_PREFIX + toEPR.getAddress();

		if (LoggingControl.debugLoggingAllowed && log.isDebugEnabled()) {
			log.debug("Reroute Handler for message : "
					+ messageContext.getMessageID());
			log.debug("Initial ToEPR is " + toEPR.getAddress()
					+ " and is changed to " + finalEPR);
		}

		toEPR.setAddress(finalEPR);
		return InvocationResponse.CONTINUE;
	}
}
<pre>

Avec Axis2 c’est ‘facile’, tout est dans le message context! Je viens de remplacer le service à appeler par le mien en modifiant le champ ‘address’ du ‘EndpointReference’.

3. Packager le module

Pour créer un module avec le Handler que l’on vient de définir, il faut passer par l’écriture du fichier de description du module, le ‘module.xml’. Ici c’est simple :

<module name="reroute">
	<OutFlow>
		<handler name="ReRouteHandler" class="net.chamerling.blog.axis2module.reroute.ReRouteHandler">
			<order phase="reroutePhase" />
		</handler>
	</OutFlow>
</module>
<pre>

Mon module s’appellera donc ‘reroute’ et sera appelé que lors de la phase d’émission de message ‘OutFlow’. Plus d’informations sur ce qui est possible avec ce fichier sur le site d’Axis2.

4. Configurer Axis2

Il y a plusieurs façcons de dire à Axis2 d’utiliser le module que l’on vient de développer. En se basant sur la contrainte de départ, je n’ai pas le droit de modifier mes services donc je ne peux pas modifier le descripteur de service ‘service.xml’. Heureusement, j’ai accès au serveur et je peux modifier le fichier de configuration d’Axis2 ‘axis2.xml’ :

...
<!-- Engage the reroute module -->
<module ref="reroute" />
...
<phaseOrder type="OutFlow">
	<!--      user can add his own phases to this area  -->
	<phase name="soapmonitorPhase" />
	<phase name="OperationOutPhase" />
	<!--system predefined phase-->
	<!--these phase will run irrespective of the service-->
	<phase name="PolicyDetermination" />
	<phase name="reroutePhase" />
	<phase name="MessageOut" />
	<phase name="Security" />
</phaseOrder>
<pre>

Je viens d’engager mon module pour tous les services et je l’ai aussi ajouté dans la collection de phases qui est appelé lors de l’émission d’un message. A chaque fois qu’un message est envoyé vers un service, on passe donc dans le module que l’on vient de développer. Je viens donc de modifier les services invoqués sans modifier le code client! Je reviendrais bientôt sur l’utilisation de ce genre de choses dans un vrai cas d’usage avec du REST, du SOAP, des PROXYs, de l’ESB distribué sur le Web (bien sûr avec Petals ESB), etc…

Resources

Le code de ce ‘tutoriel’ est bien sûr disponible sur mon Google Code sous http://code.google.com/p/chamerling/source/browse/#svn/trunk/blog/reroute-axis2.

Bon, comme je le dis souvent “Google est ton ami”, mais aujourd’hui Google ne l’est pas (comme le temps dehors, de la neige en Mars a Montpellier, mais ou va-t-on?). Bref, faisons le bêtement :

mvn deploy -DaltDeploymentRepository=chamerling.maven.snapshot::default::ftp://ftpperso.free.fr/maven/repository/snapshot

Je viens de dire a Maven2 de déployer mon artefact sur un repository dont l’ID est chamerling.maven.snapshot (pour rappel, cela veut dire que Maven2 va aller chercher dans mon settings.xml un serveur dont l’ID est chamerling.maven.snapshot pour récupérer le login et le mot de passe) en FTP sur l’URL ftp://ftpperso.free.fr/maven/repository/snapshot. Et c’est la que mon autre ami Maven2 (bon OK je n’ai que des amis virtuels…) me dit :

[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagonftp.

Ok bon c’est normal… Wagon est la librairie de transport abstraite utilisée par Maven2 et par défaut FTP n’est pas supporté. D’ailleurs sur le site du plugin deploy de Maven2 on remarque bien qu’il faut normalement définir dans le POM que l’on veut utiliser l’extension FTP de Wagon :

<build>
<extensions>
<!-- Enabling the use of FTP -->
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-beta-6</version>
</extension>
</extensions>
</build>

Oui mais moi je ne veux pas modifier mon POM! L’astuce c’est de rajouter l’extension FTP-Wagon dans le classpath de Maven2 ie ajouter la librairie Wagon FTP dans M2_HOME/lib et la ‘Oh Miracle’, ca ne marche pas…

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
org.apache.commons.net.ProtocolCommandListener
[INFO] ------------------------------------------------------------------------

Normal, Wagon FTP utilise commons-net pour tout ce qui est communication, j’ajoute donc le JAR de commons-net  2.0 dans mon M2_HOME/lib et là ça marche beaucoup mieux :

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------