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.
Related
We have an application that uses BPM for managing long running processes.
We don't want to use this product anymore and we're looking at moving it to an ESB (i.e. Mule).
My view on this is that complex and long-running processes don't belong in an ESB. Also it would need to manage state which is not what an ESB should be doing in my opinion. An ESB is designed to handle high-volume, short-lived, real-time type messages? Am I correct in saying this?
Does anybody agree/disagree with this and what would the best solution be?
For example, should the BPM code be rewritten as a java application with a database behind it to manage state and use maybe quartz in Mule to handle periodic tasks to replace timers that are used in the BPM application?
I'd be interested to hear as many opinions on this as possible.
Many thanks.
I guess in your case you can move to an ESB if 3 characteristics are met:
the BPM solution was used for very low level messaging (EAI).
there is no much instrumentation of the data for business users, for example through a BAM module to represent KPIs and enforce SLAs.
there is no human interaction, for example through forms, workflows, approvals.
You can use ESB to move messages across systems. If you need to capture and track state, you probably want to use a database to keep it in sync. You can also enforce some level of transaction support via queue systems like JMS.
You probably need to have a good idea how to move things over. A good idea is to overlay the BPM with a thin layer, and then replace it without disrupting the user experience.
I hope this helps. Disclosure: I am the Chief Architect of Intalio, a BPM company.
I think I am a little late to the party here :), but I will write for the benefit of those who come here looking for an answer...
This is what Ross Mason has to say about the ESB BPM discussion.
Mule 3 provides strong orchestration capabilities with Flow, which is
great for short-lived transaction where the goal is to maximize
throughput and scalability. For other use cases like long running
transaction, Mule has support for commercial and open source BPM
products (like jBPM, Activiti, BonitaSoft BPM, etc.).
So yes ESB and BPM are complimentary solutions and not substitutes for each other.
To conclude, I guess you are correct about your observations.
Source
Folks, I have question this morning that hopefully one of you techies can answer – during past few months, I have been heavily involved in preparing several SQL certifications study guides as it’s my desire to secure Microsoft Certified Solutions Associate (MCSA) or associate level. While I have previous experiences within this skill set and wanted to sharpen it by obtaining further experiences and hopefully securing this certification, it has been quite challenging setting up a home lab that allows me to create environment similar to what the big dogs use nowadays – windows server/several sql instances/virtualization and all that – due to lack of proper hardware or cost. In any case, my question today is to seek your advices and guidance on other possible options, particularly if this task can be accomplished using Amazons AWS – I understand they offer some level of space that can be used as playground or if one want to extend the capacity, subscription is an option. So, if I was to subscribe the paid version of it, is it possible to install all software needed to practice and experiment all needed technologies to complete and or master contents on the training kit. Again, I’m already using my small home network and have all proper software, but just feel that it’s not enough as some areas require higher computing power to properly test or rung specific areas..
Short: Yes
You can create a micro instance for free and install whatever you want on it. If your not familiar with using the CLI, it can be a bit daunting but there are plenty of guides online.
They also offer an RDS service where, they will allow you to set up a database instance and will maintain it for you but it's not free.
Edit
Link to there MS Server Page
http://aws.amazon.com/windows/
Azure is the windows cloud service, I think the comment was have you considered looking at azure instead of AWS
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Could not find an answer on this question, so would like to initiate this:
Tibco EMS vs. MSMQ vs. MQ.
How do these 3 technologies compare?
Which one is better and in which kinds of scenarios?
Specifically, I think to use one of these in SOA environment (.NET + WCF), where the scenario will mature over time.
I have one additional specific interest in the performance, which is important to mention. So, if given a choice, performance is of a critical priority.
I would appreciate to have a comparison table for a clear picture.
Thanks!
EDIT:
I am concentrated on two parameters: performance and scalability.
Scalability - how do these technologies compare in terms of supported concurrent users' count? which can support more users? scenario does not matter, let's choose the scenario which is supported by all them - e.g. simple queues.
Performance - in exactly the same scenarios, which performs faster?
If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.
MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.
Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.
IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.
Edit:
There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.
On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.
For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example,
- Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc
- Will you integrate systems in a point to point manner or you may consider having a Hub / ESB?
- Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc)
Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.
Again it is expensive commercial solution more suitable for enterprise scenarios
where mainframes are involved
Not sure why you mentioned mainframes. Many MQ enterprise customers don't have them.
IBM MQ - IBM technology supporting queues and it also somehow emulates
topics (publish/subscribe)
MQ v7.0.0 (released 2008) and onwards supports pub/sub topics as a native feature, there is no emulation involved.
APIs for both Java and .NET are terrible.
The MQ Classes for Java and JMS have evolved over 10+ years and are used heavily by thousands of enterprises.
.NET API is full of bugs and it doesn't work as expected.
The .Net API has been around for 7+ years over a few major releases of MQ. I would imagine that the obvious bugs would have been shaken out by now.
I am concentrated on two parameters: performance and scalability.
MQ has unlimited scalability. Performance is very good even with no tuning.
MQ is best only if you need to integrate with lots of mainframes. Pub/Sub is implemented poorly and the many APIs are 'strange to use'.
If all your applications are Windows, MSMQ might be a good choice, but it will be difficult to bridge into Unix or Java worlds.
The whole Java community standardized on JMS so TIBCO EMS is a good choice if you ever want to connect non-Windows applications.
I am an iOS developer. I am planning to do some sap back ended applications for iOS. when I Googled this, I realized that sybase has released sybase unwired platform(SUP) to mobilize the SAP.
I have few questions to explore regarding SUP:
What is the benefit of SUP when compared to another approach?
Is it possible to mobilize a big size SAP application also?
Should I need to do any special modification in SAP for this SUP?
Whether any other similar unwired platforms available in the market? If any please give some detail of it.
If anyone knows SUP Please direct me on the right path to explore.
Compared to which other approach? SUP make pretty easy accessing functionalities, reading data from and writing data to a SAP backend.
Yes, if you are willing to recode all screens for iOS. As far as I know SUP let you mobilize data and functionalities (if they are webservices or RFC's), but not a whole application without a frontend effort.
It will depend on how it was coded on the SAP backend. If you have RFC's for all of your needed functionalities, then you won't have to change anything.
I'm not aware of any, but take a look at SAP Project Gateway, which is more focused on small applications communicating through REST-based webservices with SAP backend.
If you want to learn SUP, check this SDN videos, and the Sybase Infocenter.
There is a product called SAP Netweaver Gateway in the ramp-up-process (like a beta for a couple of customers) that simplifies the access to SAP data via Rest Web Services (oData). Maybe you should investigate in this topic also.
Do you need to deploy to several devices?
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.