I'm doing some comparisons and a presentation tomorrow with different BPMS systems and I was reading about the difference between jbPM (the source engine that was used to build Activiti) and the Activiti engine. Can someone tell what is the caution of jBpm having the native built-in business Rules engine where Activiti has no native rule engine support but supports a basic integration with Drools to support the business Rule Task?
This is a real important question for me so a quick response to this would be great.
Thanks
Well, a couple of clarifications about your statements:
jBPM 5 and 6 are not related with Activiti at all. They are completely different engines.
Drools and jBPM 5/6 were built together to work from the ground up. This allows you to go one step further when you model your business assets. If you are only looking at business processes, then jBPM and Activiti do provide similar features. But the case is that most of the time, after implementing your first of processes you realise that you need more flexibility and Rules (a Rule Engine) becomes a must in your infrastructure. So it obviously depends on what you are looking for to do with the Engine(s).
HTH
PS: by the way I've written this blog post very long time ago, but it still applies: http://salaboy.com/2011/01/19/jbpm5-vs-activiti5-dumb-question/
Related
My organization is looking to install MuleSoft to support data and process integration. We have 5 ERP's and need to consolidate data quickly for analysis and process improvements. Looking for references or issues you have experience with MuleSoft.
While seeking extra details from this curious person, I have got an interesting research paper putting up light on Enterprise Integration Architecture while leveraging the tools of Middleware like Oracle SOA Fusion Middleware and MuleSoft ESB specifically. There are many other tools that are fairly doing well in the market and yes are available as open source and at fairly high price in terms of yearly licencing cost. Coming back to main point. You get what you ask for!
First, Kindly go through the relevant MuleSoft Documentation to get started. Perform few POC's and observe how user friendly the tool is ! The tool is not too generic to quote and unquote standard inherent issue. It's the developer's ability which makes the tool to be used efficiently.
When you talk about Middleware Integration Services, you should have a background story of all the tools which falls under such category. Have you explored the other options ! such as spring boot micro services, dell boomi, web methods before.
I work in a small organization that has built an enterprise SaaS solution. Up until this point our workflows have had no programmatic interface. We're moving to a model that will allow for an end user to do anything programmatically that can be done in the UI. I'm looking for suggestions in terms of the language/framework that you would use to build that programmatic layer.
From an organizational perspective I would like the current UI team to also have ownership of the API. That team is familiar with PHP, Rails, and Javascript. Our current back-end code is written in Scala. I'm leaning toward not doing the APIs in Scala because it doesn't seem like the right tool for the job and the lack of subject matter expertise around it on the UI team.
From a functionality perspective most of the APIs will be fairly simple database operations (CRUD) with perhaps some simplistic business logic applied on top (search for example).
I'm a bit intrigued by using Node.js for this as everyone on the team is really strong with Javascript. That being said I don't just want to hop on the semi-new technology bandwagon. Because it is enterprise software, unit testing frameworks, reusability, and extendability are all important considerations as well.
Any suggestions?
I realize this question was about technology options, but there's a fundamental concern that seems really important to call out:
From an organizational perspective I would like the current UI team to also have ownership of the API.
While this sounds like a logical approach, it may not work out well unless you're UI team is made up of really solid engineers. SaaS API development is arguably one of the most challenging aspects of modern software design. A great API will make everyone's lives easier, while a poor API will bring your system to its knees and leave you completely clueless as to why.
As a quick example, if you don't solve the end user's needs in the right way, you're likely to force a number of n+1 problems on them (and thus, on you.)
There is a bunch of great material out there about how to design great APIs and even more about the pitfalls of designing a bad one. Generally speaking, most of the UI devs I've worked with, particularly ones that are only familiar with scripting languages, are not people I would entrust to API design. Instead I would utilize them as customers (in a Scrum sense) who guide the design by describing end-user needs.
I faced something like this on a previous project, where we ended up going with a combo of Esper and our own DSL written using ANTLR 3.0. Our biggest concern with using a fully funcional runtime, was sandboxing the user's code.
That said, I think Node.JS would be one of the easier ones to sandbox and it fits your needs. Maybe using something like this: http://gf3.github.com/sandbox/ or looking into Cloud9's code to see how they keep things safe. I also like that with Node.js you could give your users a pretty niffy editor using Ace.
Also check out this post: How to run user-submitted scripts securely in a node.js sandbox?
I am going to implement Lucene search into my project and I want to make a best start.
So I consider between 3 versions of Lucene (Java/C#.Net/C++) which is the best version upon these criterias :
1.performance
2.easy to implement
3.plenty of documents ?
Assume the system is Window server, and I ask it for a long-term use.
Thanks
I would say Java. Lucene was initially developed in Java and I would think there are bigger community, more documentation and bigger deployments using Java.
Granted, Windows is not usually considered as primary platform for deploying Java services but it still would work with flying colors. Many people using Windows for Java development and even deployment so I don't expect any major issues.
Unless you've got a specific feature you need, I would look at best being:
a) Whatever platform you are developing the program in -- there are lots of advantages to not having to switch tools/contexts/platforms to muck around with the search internals.
b) Whatever platform your ops guys want to deal with -- I know lots of windows ops guys hate dealing with java as it is a strange foreign language. For example.
c) All of the above being equal, Java is the real flagship lucene project that everyone else is keeping up with with and that has the most tools & resources. It is the way to go if you don't have any reason not to use java. Solr is another advantage here -- you can pretty easily use a pre-wrapped fully functional lucene http server.
In any case, keep in mind that at least theoretically any lucene index written on one platform is readable by others so you don't necessarily have to fully commit to a single platform.
Is OpenSwing a good framework for developing professional desktop application?
I was recently using the OpenSwing Framework. I can say only the best for the functionalities which are provided with the framework. It is a multitier concept with excelent data binding possibilities. My App uses a small Derby DB in background and I’m managing it with hibernate.
I’m sure, you will be able to advance very fast and provide a working prototype very quick. I would advice you to read the available doc first and to run the provided examples (http://oswing.sourceforge.net/).
However, it has another side which you should be aware of and you will probably notice by yourself if you run the examples. The GridFrame, GridFrameControler, DetailFrame, DetailFrameControler etc classes are not really generic. There are a lot of dependencies bult in and you will have to customize them again and again for every single implementation (can be seen in the demos).
I had another approach, I invested some time in building my own classes which are generic and using the unchanged OpenSwing classes in the background first. Now I’m only setting the properties file where all details are pre-defined. The rest is generic and I don’t have to re-code again and again for every single frame.
I hope this will help.
Regards
I used the openswing in team for more than two years.
It's a pretty nice swing framework for the enterprise development used in the Internal.
It provide great component based by MVP pattern ,such as grid , document ...
If you try it , It's a good article for you about Model-View-Presenter
And try the demo in the source,It's quite good.
The JAllInOne is also a good demo for the framework also made by the mcarniel
and It's a personal project only developed by mcarniel. Thanks mcarniel's great work.
As it is included in the license (according to SAP) we would prefer using Solution Manager over other tools, for the entire life-cycle of software development. Or is it highly recommended to use specific tools for the particular processes like Test Management? Any opinions?
in general before answering this question, please be aware that SAP will bring out a new support model and the features and functions available in your SolMan installation will differ according to the support you requested from SAP. If you stick to the Enterprise Support you will (nearly) get every functionality, for Standard Support you well get less and a lot of features will not be included. At the moment, SolMan 7.10 is in Ramp Up Phase and 7.20 will be released in 2011. Due to the fact, that SAP changes the kernel of the Solution Manager Stack, which is apparently CRM from 5.0 to 7.0 you should keep in mind, that any functionality you implement in your current SolMan will lead to high migration efforts.
Apart from this, if you look at the Enterprise version, my experience is that not all features are rather good and suitable. It also depends on the organization you are working in. The SAP tools focus only on SAP, so if you are working in an environment where non-SAP Java has an important part I would look for different tools. If you look into the change management (ChaRM), it is suitable for small landscapes and for big ones only with some effort. Here you should also consider at least to have a look at different technologies and tools. From my point, there are some things like monitoring, job scheduling etc. which are quite good, but for the more general application lifecycle management tools you should at least take other options into account.