I want to know how can i communicate with MUMPS using C# .NET?
There is a requirement where i have to develop the UI in .NET using any of the .NET technology like ASP.NET, WPF or Silverlight etc. But the backend it will be old 60s MUMPS which is non relational database.
Is there any way to communicate to procedure of MUMPS using .NET? how can i use .NET with MUMPS together? I could not find much resource on Internet so thought to ask here
Request you to help and guide me with my above query.
Thanks
Regards
VJ
It depends on which MUMPS solution you will be using.
One possibility is the M/Gateway Services Integrator (MGWSI) developed by M/Gateway and provided free of charge. From their web page (M/Gateway Developments, then click on the MGWSI Gateway tab):
The core MGWSI product is a generic integration engine, but we provide a range of specific integration gateways as part of the overall package, including:
Caché, GT.M or M21 to PHP (the m_php gateway) ;
Caché or GT.M to Java Server Pages (the m_jsp gateway) ;
Caché or GT.M to ASP.Net (the m_aspx gateway) ;
Another possibility is to use KB_SQL, which offer JDBC and ODBC drivers. KB_SQL can be used with most of MUMPS solutions.
Another possibility may be to use EsiObjects, which supports both GT.M and InterSystem Caché. From their FAQ :
EsiObjects supports 4 fundamental gateways:
TCP/IP Gateway: This gateway is used to connect the EsiObjects Client Development VDE with any of the supported M systems. Additionally, The TCP/IP Gateway is also used to connect the runtime environment via an ActiveX Control.
COM Bridge: This is used with Microsoft clients built using VB, C++, C# , etc. It uses the TCP/IP Gateway and implements the ActiveX control for EsiObjects.
Java Gateway: This gateway uses the TCP/IP Gateway. There exists a set of methods in the ESI library that let you generate external Java Proxy classes from any EsiObjects class. All the connectivity is built in. Therefore, you can take the Java file that is created and use it within your Java environment, using the proxies automatically accesses the data on the EsiObjects Server.
CORBA ORB (aka EsiORB): This package is an add-on to EsiObjects. It is an implementation of the Object Management Groups (OMG) Common Object Request Broker Architecture (CORBA). The ORB uses the TCP/IP Gateway.
If the MUMPS solution you use is InterSystem Caché, you could use Caché Managed Provider solution. That said, that solution would work only for InterSystem Caché, not for the other MUMPS solutions.
If the MUMPS solution you use is GT.M, you could use PIP since it offers a JDBC driver. That said, that solution would work only for GT.M, not for the other MUMPS solutions.
Related
I'm looking for an open source alternative for commercial use to the RemObjects Remoting SDK.
I'm currently using Remoting SDK in the following scenario:
A number of windows service applications (5 to 10) act as servers and retrieve/provide data. These applications are developed using .Net Framework 4.6 (Windows service C#).
Several client applications (50 to 100) connect to each of the servers to consume the data provided by the servers. These clients are developed using .Net Framework 4.6 (WPF C#).
Remoting SDK RODL file defines the methods used by clients and servers to exchange data. Some of the methods are common calls that each client fires to retrieve data from the servers, some others are events that the servers fire and the clients receive automatically.
I would like to find an alternative open source library/framework to implement the communication between clients/servers in this scenario with the possibility to have both the clients calling the servers and the servers informing the clients when a certain event happens.
I have really basic knowledge regarding RPC and MESSAGE QUEUES and I've heard about gRPC, MQTT and RabbitMQ (which I've started to study in depth).
I would like to receive some suggestions/observations/links/guides by developers who are using one or more of these technologies in the .Net environment to solve scenarios like the one I've described to suggest me which solution will better fit the case.
I am interested in deploying a server to GoDaddy as a C# web application, then have desktop clients developed in C# and Java be able to subscribe/publish to the server using WebSockets (RFC 6455).
WebSocket supported libraries I am looking at are XSockets.Net and SignalR.
I am not able to find anything on using XSockets.Net (not to be confused with XSocket.org) in Java. I understand that XSockets targets MS .Net framework and Mono environments. However, looking at SignalR, there is also SignalA which is a Java based SignalR client for Android.
Thinking-out-loud... I understand there are many WebSocket libraries for Java, which suggests the idea that if I am able to publish a message (using WebSocket) from a Java application to a server, then I should be able to read it and processes it in C#, since WebSocket protocol is a standard.
Thus far, I believe a SignalR solution will satisfy my requirement to allow C# & Java applications to talk on the Web, but due to transport requirments of SignalR, my communication will not utilize WebSockets. Reading through SignalR requirements, to get WebSockets transport activated I must use Windows8+ with .Net Framework for 4.5+. GoDaddy does not use Windows8 for windows hosting, and even if it did, then all my clients must also use Windows8, which is not a guarentee.
So the question is: How can I get C# & Java desktop clients to talk on the web via WebSockets, othan than using SignalR and XSockets.Net?
Any help is very much appreciated!
EDIT: I will now look into deploying a C# XSockets.NET Server and have a C# XSockets.NET client and a Java JWebSocket client since both JWebSockets and XSockets support the WebSocket RFC6455 protocol. I will post my findings here and close this question if that was a successful effort.
You can implement a RFC6455 client in any language and use XSockets. However do note that XSockets uses a publish/subscribe pattern that you will have to implement as well to take benefit of the platform.
The upside is that you actually wont have to implement RFC6455 since you can implement a custom (non websocket protocol) and use that when communicating from desktop (or anything else). Since everything in XSockets is a plugin you can add custom protocols and still communicate with client talking RFC6455 since XSockets will offer cross-protocol communication.
So the thing you have to implement is actually only the publish/subscribe functionality in the java client.
There are probably not any Java clients out there that implements the IXSocketClient interface today, and we focused on Mono instead of Java when covering multi-platform support.
We will help you out in any way we can if you decide to write your own java implementation.
Note: as of the next version (not far away) it will be very easy to implement your custom protocol and connect from any device talking TCP/IP
In my humble opinion, you have misunderstood some things.
XSockets and SignalR are libraries which are totally oriented to a specific platform, .NET. They both wrap the functionality of WebSockets, a platform independent standard, to ease its use. This does not by anyway mean that you could use XSocket, or SignalR libraries in all platforms.
I suppose that creating a java client for XSockets or SignalR would be an overkill and would lead you to heavily depend on a 3rd party library. In your situation, I would go on with using WebSockets directly on my server side. Then I would use a library handling the WebSockets standard for each client, which could be different for each client development platform. Therefore, you would depend on one universal standard and you would minimize dependencies on 3rd party libraries.
Hope I helped!
Im on the verge to decide which way to go. On one side i have jWebsocket framework which offers me fast startup with javascript - java (client-server) integration, and on the other is to use pure socket.io (client) with c# websockets (http://alchemywebsockets.net/).
My purpose is not to advertize, however i need some thoughts on this before i start a project that requires REAL TIME information displaying(broadcast included) on the browser and i need to handle big chunks of data so i suppose opening multiple websockets on a server will do the job for me ?
P.s.
I will have maximum 10clients at the same time connected.
The SockJS library is a good choice for in-browser WebSocket client. It automatically supports fallback to variety of browser-specific transport protocols.
If you decide for Java on the server side, then I'd recommend Spring Framework 4 (here's an introduction) which nears it's GA release (I think we'll see it before the new year) and has WebSocket and STOMP support built in.
I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.
Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.
As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.
Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.
The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).
Right now, our options as I see them are:
Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management
My basic question is this:
What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?
(I am working on the assumption that by "stateful" you mean session-based).
I guess one big question is: Do you want to use SOAP in your messaging stack?
You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!
Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.
You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.
What sort of state do you need to store in your sessions? Maybe there are alternative approaches?
1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless.
2) consider distributed caching, perhaps Windows Server AppFabric Cache.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener