There is a lot of noise about the Service Oriented Architecture (SOA) and much less about how to coordinate those services or how to assemble them in a logical structure. A business has no gain if SOA is implemented and that those different services are not linked to each other or orchestrated.
The Service Orchestration concept is something that exists for a long time but it seems to me that it is not applied within a lot of organizations. One thing is to have a Service Oriented Architecture implemented for you business and the other is to really reuse and orchestrate automatically your business around those services.
Service orchestration is a concept mainly used in ESBs but I do not think it should only be used and implemented there. Business Process Management (BPM) is a technology that could orchestrate the services without any problems and some ESBs are using BPM to provide the service orchestration.
A service should be seen as a step in a business process and there you go, you are free to model your services as a unique business process that suites your needs. A business process mainly needs two kind of steps, which could be manual or automatic. A manual step is where an action is needed by someone from your company or a third party.
As I am working in document management for a longer period now, I am trying to explain to my clients that they could reuse their existing services in a newly created business process where document management is also completely integrated with the whole solution. Specifically, Alfresco has a BPM solution based on the jBPM implementation and thus document management is already integrated with BPM. The only thing to do is to integrate your existing service within your business process and benefit from it as an added value to your business.
This kind of integration does not need an ESB and I am not saying that this kind of solution is equivalent to a an ESB implementation. ESBs allows you to do much more than just service orchestration but this is just to explain that SOA is not really an added value to your business if you do not have a business process management around the services.
Monday, May 19, 2008
Wednesday, April 23, 2008
Book review : Service Oriented Java Business Integration
I took some time to read this book and I do not think I lost my so "precious" time. I would say that the book is not intended for Java beginners but more for people with a good technical background and especially with at least, some knowledge of the Java Enterprise world. Never the less, if you are not a specialist, just like I am not one, you could still read the book and you could learn a lot of new stuff.
Indeed, the book is taking you from the beginning and tries to lead you through different technologies like Java Messaging service (JMS), Enterprise Java Beans (EJB), WebServices (WS) and a few more. The author is clearly explaining how to use those different technologies within an Enterprise Service Bus (ESB) and how to implement it using the Java Business Integration (JBI) specification. The aim is to make you understand of how you could use any technology to achieve the Service Oriented Architecture.
A good point is that the theory is accompanied with a lot of examples based on Service Mix, which is an Apache JBI implementation. Those samples are insisting on EJB and WS, I would qualify them as realistic or real world samples. My opinion is that it could help a lot of people and companies not to rewrite their existing code but to rather reuse the code they already have and to make it working within a JBI container. You could find some explanations on how to make a real enterprise application using Service Mix and a huge assortment of useful packages like XStream or Axis. Also, on how to expose your EJBs as WSDL, which I find interesting. The samples provided in the book are accompanied with a lot of code and the whole build process. Thus even if you are not familiar with all those technologies you will be able to test and see the samples running.
All that is strengthen by the link to the Java Connector Architecture and to the point on how to exchange the information between all those different/heterogeneous systems.
While the book is correctly explaining the point of JBI, I would really appreciate to hear some words about the Service Component Architecture (SCA) and to see something about REST, but not only about WS. There are also a couple of references to VoIP and probably that a parallel could be shown with the SLEE (or JAIN SLEE) specification.
I also think there should be less explanation about WebServices and especially about the WS versioning, but some more words about XA transactions and services orchestration.
Finally, I really do recommend the book to those who are not familiar with ESBs or SOA and that want to learn something without investigating a lot on the web alone. Also, as I already mentioned to those who want to use a JBI container but have a lot of EJB and WS implementations around.
Indeed, the book is taking you from the beginning and tries to lead you through different technologies like Java Messaging service (JMS), Enterprise Java Beans (EJB), WebServices (WS) and a few more. The author is clearly explaining how to use those different technologies within an Enterprise Service Bus (ESB) and how to implement it using the Java Business Integration (JBI) specification. The aim is to make you understand of how you could use any technology to achieve the Service Oriented Architecture.
A good point is that the theory is accompanied with a lot of examples based on Service Mix, which is an Apache JBI implementation. Those samples are insisting on EJB and WS, I would qualify them as realistic or real world samples. My opinion is that it could help a lot of people and companies not to rewrite their existing code but to rather reuse the code they already have and to make it working within a JBI container. You could find some explanations on how to make a real enterprise application using Service Mix and a huge assortment of useful packages like XStream or Axis. Also, on how to expose your EJBs as WSDL, which I find interesting. The samples provided in the book are accompanied with a lot of code and the whole build process. Thus even if you are not familiar with all those technologies you will be able to test and see the samples running.
All that is strengthen by the link to the Java Connector Architecture and to the point on how to exchange the information between all those different/heterogeneous systems.
While the book is correctly explaining the point of JBI, I would really appreciate to hear some words about the Service Component Architecture (SCA) and to see something about REST, but not only about WS. There are also a couple of references to VoIP and probably that a parallel could be shown with the SLEE (or JAIN SLEE) specification.
I also think there should be less explanation about WebServices and especially about the WS versioning, but some more words about XA transactions and services orchestration.
Finally, I really do recommend the book to those who are not familiar with ESBs or SOA and that want to learn something without investigating a lot on the web alone. Also, as I already mentioned to those who want to use a JBI container but have a lot of EJB and WS implementations around.
Wednesday, April 16, 2008
Alfresco webscripts with Groovy
After being a little bit disappointed about using Grails in Alfresco (see my post below), I decided to see how could Alfresco be integrated with Groovy.
Alfresco introduced a while ago the "webscripts", with that they added a powerful scripting API based on JavaScript and the Rhino engine. When you add FreeMarker templates to that, what you could get is a nice output that you could customize to be some JSON data, XML or whatever suites you. That is amazing but I was not that happy as we have to wait for Alfresco to expose more of their services via the scripting API. Adding Groovy capabilities to any application and not only to Alfresco seems "natural" and I think that it helps in prototyping without having to recompile.
I took the groovy.servlet.GroovyServlet implementation and added a few lines that allows to configure a Spring bean as servlet parameters and to make them available in the groovy scripts.
The code is not yet published somewhere as a forge project but you can find it here. All you have to do is have Spring and Spring MVC on your classpath (Alfresco already has it) add Groovy libraries (groovy-all is a good solution, at least version 1.5.x) and configure your web.xml with the Groovy servlet that I am providing, an example could be found here. That example is using spring's DispatcherServlet but you could use the GroovyServlet as any other servlet, directly in your web.xml. If your are also using the DispatcherServlet then you have to configure it correctly as shown here.
Once you are done with those configuration just add the desired beans to the servlet configuration and you are on "rails" with Alfresco.
The samples provided here are using the ServiceRegistry bean and it is mapped in Groovy as registry, so to get any other Alfresco service you have to start from there. But you are free to map whatever bean you want.
Although, some people are saying that there are problems using Alfresco beans with Groovy, I did not have those problems till now, but I am not saying it will happen.
Alfresco introduced a while ago the "webscripts", with that they added a powerful scripting API based on JavaScript and the Rhino engine. When you add FreeMarker templates to that, what you could get is a nice output that you could customize to be some JSON data, XML or whatever suites you. That is amazing but I was not that happy as we have to wait for Alfresco to expose more of their services via the scripting API. Adding Groovy capabilities to any application and not only to Alfresco seems "natural" and I think that it helps in prototyping without having to recompile.
I took the groovy.servlet.GroovyServlet implementation and added a few lines that allows to configure a Spring bean as servlet parameters and to make them available in the groovy scripts.
The code is not yet published somewhere as a forge project but you can find it here. All you have to do is have Spring and Spring MVC on your classpath (Alfresco already has it) add Groovy libraries (groovy-all is a good solution, at least version 1.5.x) and configure your web.xml with the Groovy servlet that I am providing, an example could be found here. That example is using spring's DispatcherServlet but you could use the GroovyServlet as any other servlet, directly in your web.xml. If your are also using the DispatcherServlet then you have to configure it correctly as shown here.
Once you are done with those configuration just add the desired beans to the servlet configuration and you are on "rails" with Alfresco.
The samples provided here are using the ServiceRegistry bean and it is mapped in Groovy as registry, so to get any other Alfresco service you have to start from there. But you are free to map whatever bean you want.
Although, some people are saying that there are problems using Alfresco beans with Groovy, I did not have those problems till now, but I am not saying it will happen.
Tuesday, April 15, 2008
Grails integration ... nice but ...
These days I was trying Grails and I have to say that coding by convention with Groovy is very powerful and allows to create new web applications very quickly. It is very helpful when you create a new application because you can change the code without redeploying the whole application as you have to do with a WAR when you change a Java class. Grails has different environment and one of them is development, which is using embedded Jetty. The feature I really like is the integration with the Spring framework and especially the autowiring by name in Grails controllers.
Although, autowiring is not so new, it is not that easy to have it within an existing application which is using Spring and to integrate it with Groovy i.e. So, I saw in Grails a big big thing. The difference with the development environment and production is that in the dev environment, groovy files are recompiled and as soon as you change something, they are "redeployed". What a great feature, if only I could use it in another web or application container. Imagine that you have an application and that you could include a framework which is exposing all the beans that you need to your scripts, just by autowiring them.
You could be able to write a script, and expose some data to the rest of the world from your application without any problem. I already blogged about Alfresco (the opensource CMS) and its webscripts, but those webscripts are exposing Java through Rhino and you have to write some Javascript on the server side. What if we could do the same via Grails (I would say ... WoOoW ...)?
Although, you can create a WAR file containing your Grails application and just deploy it to Tomcat for instance and you could still benefit of all the Grails feature but not of being able to recompile your "scripts". Yes, it is possible somehow but not that easily. You could still have your dev environment and tell Grails as soon as a script changes to publish it to the production environment, but that is not what I want.
Another possibility would be to use the features of the dev environment, is to integrate your existing application into Grails. You could expand all the sources and run it via Grails, I am saying that because I want to reuse all the configuration files (Spring, JSF, ...) of the existing application. But, really I do not appreciate that way.
Also something that attracted my attention were Grails plugins. There is a possibility to know that a plugin has changed and that event could be handled in your groovy code and used for reloading of the necessary scripts. More information could be found at http://docs.codehaus.org/display/GRAILS/Auto+Reloading+Plugins.
Well, I guess that for the needs I have, I do not need to use Grails and I could simply use Groovy with somehow the autowiring enabled in groovy scripts. Probably that would be enough. But the REST approach of Grails is also a nice feature that could just be reused without having your own code or dispatcher servlets.
So, go with Grails if you need to quickly develop a Java based web application. But I would like to be able to reuse the Grails development environment in another container too.
Although, autowiring is not so new, it is not that easy to have it within an existing application which is using Spring and to integrate it with Groovy i.e. So, I saw in Grails a big big thing. The difference with the development environment and production is that in the dev environment, groovy files are recompiled and as soon as you change something, they are "redeployed". What a great feature, if only I could use it in another web or application container. Imagine that you have an application and that you could include a framework which is exposing all the beans that you need to your scripts, just by autowiring them.
You could be able to write a script, and expose some data to the rest of the world from your application without any problem. I already blogged about Alfresco (the opensource CMS) and its webscripts, but those webscripts are exposing Java through Rhino and you have to write some Javascript on the server side. What if we could do the same via Grails (I would say ... WoOoW ...)?
Although, you can create a WAR file containing your Grails application and just deploy it to Tomcat for instance and you could still benefit of all the Grails feature but not of being able to recompile your "scripts". Yes, it is possible somehow but not that easily. You could still have your dev environment and tell Grails as soon as a script changes to publish it to the production environment, but that is not what I want.
Another possibility would be to use the features of the dev environment, is to integrate your existing application into Grails. You could expand all the sources and run it via Grails, I am saying that because I want to reuse all the configuration files (Spring, JSF, ...) of the existing application. But, really I do not appreciate that way.
Also something that attracted my attention were Grails plugins. There is a possibility to know that a plugin has changed and that event could be handled in your groovy code and used for reloading of the necessary scripts. More information could be found at http://docs.codehaus.org/display/GRAILS/Auto+Reloading+Plugins.
Well, I guess that for the needs I have, I do not need to use Grails and I could simply use Groovy with somehow the autowiring enabled in groovy scripts. Probably that would be enough. But the REST approach of Grails is also a nice feature that could just be reused without having your own code or dispatcher servlets.
So, go with Grails if you need to quickly develop a Java based web application. But I would like to be able to reuse the Grails development environment in another container too.
Friday, February 15, 2008
Document Management with Alfresco "on rails"
For a couple of month I am working for a large international company, where I am helping on introducing a new and open source document management system. The power of open source and thus of Alfresco opposed to other closed source packages, is the open interfaces and the easiness of adding custom features. Whatever solution you chose, you should be sure that the package is enterprise ready. A document management system should provide a way to automate your business processes, to make the document transformations needed, provide metadata management and especially provide a friendly user interface.
My opinion is that Alfresco has a really powerful core but is still lacking some of enterprise level services. For document transformations Alfresco uses OpenOffice which is used as a server side application while OpenOffice was developed to be more client side oriented. The primary Alfresco user interface is implemented with Java Server Faces (JSF) and does not provide a nice and usable front end for the common user.
A cool feature of Alfresco that I really do appreciate are webscripts, through which are/will be exposed all the Alfresco functionalities via a REST like interface. This kind of approach will allow Alfresco to be easily decoupled from the JSF user interface.
It seems to me that Alfresco is trying to be a collaboration platform and not only a document management system. As I already said, Alfresco has a really good core and I would like to know why do they not focus on improving it and on providing an easy way to create new models via a user interface for example and not through several xml and configuration files. The first thing to provide in order to be a collaboration platform is to have a calendaring system, which Alfresco does not have. Wouldn't implementing CalDAV over their WebDAV implementation be a good start? Sometimes ago I tried to implement it and it does not seem complicated, if somebody is interested I would like to share that idea and the implementation.
To conclude, soon Alfresco will probably offer a new user interface implementation based on web scripts and AJAX and they will provide some Flex components which is a very good thing, that will be a nice move. Finally, I would like that they stop implementing some pseudo collaboration and just focus on real enterprise collaboration.
My opinion is that Alfresco has a really powerful core but is still lacking some of enterprise level services. For document transformations Alfresco uses OpenOffice which is used as a server side application while OpenOffice was developed to be more client side oriented. The primary Alfresco user interface is implemented with Java Server Faces (JSF) and does not provide a nice and usable front end for the common user.
A cool feature of Alfresco that I really do appreciate are webscripts, through which are/will be exposed all the Alfresco functionalities via a REST like interface. This kind of approach will allow Alfresco to be easily decoupled from the JSF user interface.
It seems to me that Alfresco is trying to be a collaboration platform and not only a document management system. As I already said, Alfresco has a really good core and I would like to know why do they not focus on improving it and on providing an easy way to create new models via a user interface for example and not through several xml and configuration files. The first thing to provide in order to be a collaboration platform is to have a calendaring system, which Alfresco does not have. Wouldn't implementing CalDAV over their WebDAV implementation be a good start? Sometimes ago I tried to implement it and it does not seem complicated, if somebody is interested I would like to share that idea and the implementation.
To conclude, soon Alfresco will probably offer a new user interface implementation based on web scripts and AJAX and they will provide some Flex components which is a very good thing, that will be a nice move. Finally, I would like that they stop implementing some pseudo collaboration and just focus on real enterprise collaboration.
Friday, January 11, 2008
REST and integration ... ?
Since REST has been adopted for a long time now it seems that applications integrations are the next step. Usually I thought that integrating different applications should be done via an ESB I am sure now that it is not true.
In my opinion any decent application should have different interfaces exposed to the world. One may consider WebServices and some others REST or any other technology or interface. To keep the focus on integration I will not discuss what is better even if I think that one should use the right tool for the right job.
Once an application has a REST interface it is very easy to access that information directly from the browser for example, even if you can use it on the server side too. The information provided might be in different format such as XML or JSON. JSON is very suitable for browsers and XML is better handled by the server side.
To get the data from the application and to make the user experience much better, people are using AJAX today, and that is for sure a must have. There are a lot of Javascript frameworks out there, opensource and commercials ones, that offers AJAX functionalities and also nice widgets or UI components. It is up to everyone to chose the framework that suites the best your needs.
At the end the integration is very easy to be done. It is true that security is a weak point in such an integration but that can be solved too.
To enable REST in your application it is good to consider the integration of a server side scripting language and of a templating framework. The templates should allow you to output different formats such as XML or JSON.
In my opinion any decent application should have different interfaces exposed to the world. One may consider WebServices and some others REST or any other technology or interface. To keep the focus on integration I will not discuss what is better even if I think that one should use the right tool for the right job.
Once an application has a REST interface it is very easy to access that information directly from the browser for example, even if you can use it on the server side too. The information provided might be in different format such as XML or JSON. JSON is very suitable for browsers and XML is better handled by the server side.
To get the data from the application and to make the user experience much better, people are using AJAX today, and that is for sure a must have. There are a lot of Javascript frameworks out there, opensource and commercials ones, that offers AJAX functionalities and also nice widgets or UI components. It is up to everyone to chose the framework that suites the best your needs.
At the end the integration is very easy to be done. It is true that security is a weak point in such an integration but that can be solved too.
To enable REST in your application it is good to consider the integration of a server side scripting language and of a templating framework. The templates should allow you to output different formats such as XML or JSON.
Tuesday, December 11, 2007
The refresh problem of a web page?
I heard many time that people have problems when refreshing a web page. Well, I really do not understand it and I would like that someone points me to a concrete example.
I agree totally that a stateless application has problems when doing a page refresh but then I would not call it an application but a service or something like that. My opinion is that an application needs some state representation and according to that state you can access stateless services. Thus, when doing a refresh you just show the same things that the user was seeing before the refresh.
Ok ok, what if you have 10000000 .... users ? What if an atomic bomb .... ? :) I have read a nice post about user data management sometimes ago but I forgot where I saw it. I will post the link as soon as I find it.
Actually, the article was stating that with 256 megs you can have a loooot of users, on which I agree totally. Of course, you can have a lot of data in the user session but what about load balancing, caches and ...
So, is memory the real problem for saving the state on the server side?
I think that on a technical level using AOP, Spring AOP / interceptors can be considered and used to solve the refresh problem.
I agree totally that a stateless application has problems when doing a page refresh but then I would not call it an application but a service or something like that. My opinion is that an application needs some state representation and according to that state you can access stateless services. Thus, when doing a refresh you just show the same things that the user was seeing before the refresh.
Ok ok, what if you have 10000000 .... users ? What if an atomic bomb .... ? :) I have read a nice post about user data management sometimes ago but I forgot where I saw it. I will post the link as soon as I find it.
Actually, the article was stating that with 256 megs you can have a loooot of users, on which I agree totally. Of course, you can have a lot of data in the user session but what about load balancing, caches and ...
So, is memory the real problem for saving the state on the server side?
I think that on a technical level using AOP, Spring AOP / interceptors can be considered and used to solve the refresh problem.
Subscribe to:
Posts (Atom)
Posts
