I was pretty busy these days with being involved in a startup openings and now as a co-founder I am glad to announce its name iCodix. Our aim is to provide Java consulting services and Enterprise Content Management (ECM) solutions, especially based on the Alfresco platform. At this stage, where iCodix is just starting, we have an ajax based UI framework for Alfresco called Jibe (former AlfExt).
Jibe is a complete UI framework based on the javascript ExtJS library. It is tight to the Alfresco configuration and each UI component is configured on the server side and thus is easily reusable.
A lot of components are already implemented and some of them can be seen in the demos available here. However, one could add very quickly new components or layouts as there are a lot of 'cut' points' on which it is possible to attach any behavior or interaction with other systems.
Jibe's architecture was thought the way to easy the developer's work and to allow the developer to concentrate on the real problem and not to play around with javascripts anymore. Although, if new components are needed than for sure you have to write some javascript, but at least the need is minimum as there are existing components which are used the most in the business world, like panels, tabs, grids, labels, combo boxes, date pickers, tree lists and a few others.
Jibe is an addon to the Alfresco platform and we consider it as a UI framework for Alfresco, which is not yet replacing the complete Alfresco feature set but it is not said it will not. Alfresco is also working on some new UIs but they do not target the same market and the same level of integration. Jibe's components are all linked by events and thus it is easy to catch an event on some node or properties and to show or to act in any other component.
An integration with Groovy is implemented in Jibe and from now on if you are using Jibe, it is not needed to restart the server as far as the UI components configuration is concerned as well as the Groovy services that are integrating third party codes with the Jibe UI.
The deployment is done as any other Alfresco modules and Jibe coexists with the exiting Alfresco JSF client as well as with any other Alfresco UI clients. The Jibe framework contains a core module and other modules which are enabling different parts of the system like repository browsing or workflow management.
As an example of how an application could reuse Jibe and its powerful integration aspect, we integrated the opensource VoIP Asterisk server as a module where Alfresco is turned into a call/contact center, where Alfresco users are becoming agents and where documents are linked to incoming or outgoing calls. With the power of jBPM it is not that hard to implement a predictive dialer within the same and user friendly UI.
Well, our opinion is that Jibe is the UI layer where you could integrate different applications and to allow it to look as one. It comes out of the box with a powerful content management system which is Alfresco and it can turn on your world and your business :)
More about Jibe architecture can be found here. Although it is an old description but it could give you some ideas.
Showing posts with label integration. Show all posts
Showing posts with label integration. Show all posts
Tuesday, September 2, 2008
Monday, May 19, 2008
Service Orchestration and BPM
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
