I want to use OpenSplice DDS for "Messaging" and "Database Transaction Processing" functionalities.
Can you please help to know if OpenSplice DDS open source implementation supports - "Database Transaction Processing" or not?
Can anyone share the experience with OpenSplice DDS?
OpenSplice DDS Community Edition (the "open source" version) does not feature any out-of-the-box integration with a DBMS. Its commercial version does provide an optional service called DBMSConnect that might do what you are looking for. You did not describe in detail what you are trying to achieve, so it is hard to assess.
As far as I know, there is no on-line documentation available on DBMSConnect for you to check out whether it would do what you are looking for. However, the DDS implementation from RTI has a similar feature, also commercially available only, called Real-Time Connect. Full documentation for that is available on-line via the Real-Time Connect User's Manual. There are more links on Real-Time Connect on their Community Portal Documentation page. That might help you in assessing whether it meets your needs.
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 shop that's adopted TFS for source control. We're happy with the integration in VS and the other features it offers, so it's likely we're not going to switch to another platform. However, features for team collaboration and documentation are lacking compared to other solutions, most notably SVN + Trac.
Has someone been able to integrate TFS 2010 with TRAC?
EDIT:
It's been asked that I clarify my intent here. It's very simple. I'm just asking if the TRAC project management and bug/tracking system can be used in conjunction with TFS. And, if so, what would it take?
Remember, I'm not looking for a Sharepoint solution--I've already got that. I'm asking if it's possible that TRAC and TFS can get along.
(Long rambling clarification on what I'm looking to get out of TRAC removed. The question is simply "Can TRAC work with TFS?")
Not so much of a trouble a the Trac side. There is FOSS everywhere, a lot of modularity and flexibility. No quite the same at the other side. I've read about the trouble even with one-time migration from SVN to TFS. Despite the source is all open and well documented, there no evidence of good support, that should tell you much about the chance for getting even more - constant synchronization.
Facts: MS SQL server is the base for TFS. No connector available for MS SQL server as a Trac db backend, although there are several python bindings to MS SQL server available, or the option to connect via ODBC. But just an option, nothing ready AFAIK.
I'm not aware of any well documented open TFS API as foundation for migration and integration. And I'm not convinced this will ever change. At Redmond (Microsoft) they are reportedly only considering what seems important to themselves: "helping customers with IBM Rational ClearCase and ClearQuest tools." And most probably it this behavior will persist and SVN/Trac keeps very low on the ToDo for them.
[Edit2]
While TFS has some support for bidirectional communication, these scenarios are not recommended. It mostly aims at integration, read: sucking information in, not communicating with other information systems like Trac.
[Edit]
Just for sub-task of repository browsing you could try to write code to push a duplicate of changes to another (SQLite|MySQL|PostgreSQL) repo that Trac supports right now. But I consider this is rather wasteful and ugly, and fact remains, that it's hard, if possible at all, to do the same tracking without such big code duplication. Ultimately, if you want to live without the actual check-in source changes you must at the very least send information about the meta-data like resource ID's (for link generation) to find the data in TFS.
I'm looking into that right now. So take the following as half-educated advise to the best of my knowledge and feel free to correct/discuss.
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.
I've been evaluating several opensource message queue technologies, such as RabbitMQ, ActiveMQ, OpenAMQ, etc. My question is, what benefits are gained by using a commercial technology such as Tibco EMS, WebSphereMQ, Sonic, etc. instead of something like Active or Rabbit? PHP will be the primary language involved, although Java systems will be interacting as well.
I'd say the benefits are few and far between. You really need to be sure that a commercial system is for you before you invest as there is likely to be no going back.
Some of these things are so esoteric, so prone to vendor lock-in, so damn heavyweight that you'll feel like you have a gorilla on your back, not just a monkey ;)
Those commercial technologies are good, but investment in them can be steep. Both yearly license costs and on-going support costs must be considered when making a decision. As far as vendor lock-in goes, in the commercial world there's only one vendor offering support for a given product. In the open source world, there's typically more than one vendor offering support. Consider ActiveMQ for example. Both Progress Software and SpringSource offer support agreements for ActiveMQ as well as some others.
Also, in the commercial world, you won't ever get to look a the source code yourself. For a product like ActiveMQ, anyone can grab the source code. This is pretty powerful because it means that you can add features, etc. and quite possibly get them added to the product.
ActiveMQ has a great community and is very widely deployed. ActiveMQ provides client APIs for many languages including C/C++, Java, .NET, Perl, PHP, Python, Ruby and more.
There are great communities around projects like RabbitMQ (check out the mailing list for example). Also, if cost is an issue, obviously open source is a win there.
The biggest difference I have found is operational support and management. The commercial vendors usually provide better tools for ops/support staff to resubmit, edit messages etc.
This is often a weakness of open source offerings, which if rectified, should cause some serious lack of sleep for commercial vendors.
I think it's always best to thoroughly examine your requirements before choosing a messaging system:
Not all the commercial vendors will support PHP for example. ActiveMQ and RabbitMQ will.
Not all the messaging systems can support very large Queue sizes - though ActiveMQ does
Not all the messaging systems survive a hard broker stop without loosing messages ActiveMQ will - without you having to use transactions.
And if you are going to use open source - always look at the community - ActiveMQ is the most active community of any open source message vendor - and it's also Apache - which means diversity and no reliance on any single developer or vendor for delivery.
If you use commercial products it comes with everything(just we have
to use) but all the open source products will have basic features but
still we can implement commercial product features(involves lot of
development)