I'm writing a small c# console application that needs to interogate Websphere Application Server ND (6.1) to retrieve a list of installed apps.
I can easily do this from the command line using the wsadmin command, but don't really want to launch wsadmin from my c# app.
Is there a way to natively get c# to talk to Websphere and get this sort of information ?
Wsadmin is just a scripting interface for JMX and everything you can do with it can be done with RMI and SOAP. For C# users that means querying for Management Beans via SOAP.
However there are no turn-key solutions available. What has been suggested before has been at least taking a look at the ws-jmx-connector and implementing your own library. You could probably easier just capture one of those queries with ie. SoapUI and replay the SOAP calls. This probably means too much work and that's probably also why there are no ready solutions.
Also, you could just read the XML files that describe the (properly) installed WebSpehre Application Server applications. That is probably much easier, and works just fine. Take a look at the server profile directory. You should see a directory called config, then under it cells, your management cell's name and under that you will find XML files that actually contain every setting you see in the management console. They are well parseable by the standard .NET libraries and a few of those will contain application lists. Take a look at serverindex.xml for instance.
Related
I am responsible for developing the software for a printer-like device, for which I am using C#/.Net and WPF. We now have the necessity for making this software network-capable, so that the device can be remote-controlled over a local network.
The idea I currently have, is to be implement some way of calling the API-functions of our software over the network. This could be done by a client-side DLL, which sends the commands for the API and receives their responses as well as any events, that the device-software issues.
To this date I have only worked a little with socket-based communication using TCP/IP, where I explicitly sent strings over the network and received them on the other side. I did this completely synchronously. However for the new implementation I will need asynchronous calls to the API to query state, issue events, etc. and it seems like it would require considerable effort to implement this using socket-based communication (am I wrong?). I will have to avoid too much custom implementation, since I am under a time-constraint for the implementation.
In my search I came accross the possibility of using SOAP in ASP.Net, which from this CodeProject post, seems to be what I am looking for and does not seem to be too complicate to implement. However in my Visual Studio 2015 installation I am unable to find the project-type they are using there, which is a "ASP.Net Web Service".
My question is now:
Given my choice of technologies (.Net), would this be the most effective way for achieving, what I have in mind? Is it still possible to do this in Visual Studio 2015?
Update:
As always I found one of the questions afterwards: Here is an explanation of how to create an "ASP.Net Web Service" in Visual Studio 2015, which I have tested to work. Leaves the question, of whether this is the best way to go for what I need.
I think that you would have better luck using web api. Calling a REST based api is a lighter load on the network and is generally easier to set up. It is also easier to call from non-Microsoft based clients and usually requires less coding to get started.
Here is a good tutorial on creating a RESTful web api using .Net Core. If you have a PluralSight subscription, they have a number of tutorials on Web Api. If you don't have a subscription, it is well worth the money.
Web Api and WCF are two completely different frameworks. WCF uses SOAP, which is XML based, meaning that the number of bytes needed to send information is much larger than a RESTful service in Web Api. It is much easier to write and deploy a Web Api application and client than it is to write the equivalent in WCF.
when we are using winform to index data through lucene.net then think say 10 same win apps is running in a office and they all index data. if the index segment file is created in every pc then it will be problem or we can create in any centralize pc but problem occur when that pc suddenly being unavailable from network. so i like to know can we store lucene.net index in sql server for centralize access. if possible please guide me. i search lot for storing lucene.net index in sql server but found none. i got a article on java and they i saw it is possible. here is the link
http://kalanir.blogspot.in/2008/06/creating-search-index-in-database.html
they said Lucence contains the JdbcDirectory interface for this purpose but i am working with lucene.net & c# so please anyone guide me how make it possible to store lucene index in sql server.
thanks
It is possible to create a custom Directory but, it is quite painful. I've seen several project try this and fail.
The show stopper for your approach is that the IndexWriter assumes that it has sole access to the Directory. So having multiple machines writing docs to the same Directory is flawed and will break many assumptions.
The best approach is to treat Lucene like a database. You wouldn't expect many machines to all write directly to files of a db. That's why there is a service that the clients talk to (SQL Server, MySql, Postgres etc etc).
Remember Lucene is just a library not a "product".
What you need is a service with an api for the machines to talk to.
ElasticSearch has been mentioned elsewhere and it is very good. Highly recommended you look into it. Redundancy, speed, latest features etc (yes it does require the JVM, more accurately the JRE. If you look carefully there is a download/installer that does not also install crapware).
It is also quite straight forward to write a service that self-hosts ASP.net WebAPI and wraps Lucene. Creating a client that talks to it is also quite easy. Just a wrapper around HttpClient. (I have done this several times. Getting a POC working should only take a day or two. But the devil is in the detail.)
I'm in this project:
A web page that's gonna be used by the front-end company people to query and update data from a SQL DB.
I'm working with visual studio and the code behind (C#) is almost done, so the interactions between SQL and C# are ok.
My original idea was to work with ASP.NET which is familiar to me, but that's not gonna be possible. I have to switch to PHP.
So, today is my first day learning PHP, checking http://php.net/manual/en/index.php and a lot of things seem quite similar to ASP.NET so I guess it won't be that hard.
Anyways, some questions popped up quite fast as I wanted to script something else than a "hello world".
Is there an easy way to get/send C# variables from my class using a php page? I've read soemthing about using XML in order to do so, but still I'm scratching my head, is there another, easier, way to do this?
You have options.
direct integration. PHP can instantiate and use .NET objects . See the DOTNET library in PHP. So if you run PHP on Windows, and you expose your .NET logic according to the requirements of the PHP DOTNET infrastructure, then you can just call .NET classes directly from PHP. Some restrictions: PHP is built to integrate with the .NET 2.0 runtime. You can't build .NET 4.0 objects and connect to them from PHP.
synchronous network protocols. As others have suggested you can expose your C# logic via aREST or web services interface, then invoke those services from PHP using the curl library or file_get_contents(). The C# logic could be, but need not be, publicly exposed. In other words, you could make it accessible only from within the firewall of your app, so that no anonymous public access is possible. on the other hand your architecture may call for access to the same API from 3rd-party or user apps. In that case it needs to be exposed publicly.
in either case, public or private, you will want to use WCF or ASPNET MVC to expose these services implemented in C#.
asynchronous mechanisms. PHP can connect to MSMQ. See Using PHP to Open MSMQ Queues . Of course C# can do likewise. You could use MSMQ as a buffering communication mechanism between the two worlds. To do this you'd need to come up with a data serialization protocol, for the messages you put and get on the queue. JSON or XML would be appropriate choices here.
Database. If you are concerned about employing MSMQ as it is "one more piece of infrastructure to manage" you can also employ a database as a go-between. A shared database can be accessed by both PHP and C# and used as a message queue or communication conduit. PHP inserts messages in a MySQL Table, and the C# app could read and process them, then place reply messages in a different table. This would require some work by you to design the message formats, protocols, indexes, and request/reply correlation mechanism. But it relies on proven, existing technology that you already know how to use.
Finally, there is Phalanger. This lets you compile PHP onto the .NET Framework. This means integration between C# and PHP will be simple. I haven't tried this but it might satisfy your requirements.
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
Sync Framework
ADO.NET Sync services v. 2
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully
So my company stores alot of data in a foxpro database and trying to get around the performance hit of touching it directly I was thinking of messaging anything that can be done asynchronously for a snappier user experience. I started looking at ActiveMQ but don't know how well C# will hook with it. Wanting to hear what all of you guys think.
edit : It is going to be a web application. Anything touching this foxpro is kinda slow (probably because the person who set it up 10 years ago messed it all to hell, some of the table files are incredibly large). We replicate the foxpro to sql nightly and most of our data reads are ok being a day old so we are focusing on the writes. plus the write affects a critical part of the user experience (purchasing), we store it in sql and then just message to have it put into foxpro when it can. I wish we could just get rid of the foxpro, unfortunately the company doesn't want to get rid of a very old piece of software they bought that depends on it.
ActiveMQ works well with C# using the Spring.NET integrations and NMS. A post with some links to get you started in that direction is here. Also consider using MSMQ (The System.Messaging namespace) or a .NET based asynchronous messaging solution, with some options here.
MSMQ (Microsoft Message Queueing) may be a great choice. It is part of the OS and present as an optional component (can be installed via Add/Remove Programs / Windows Components), meaning it's free (as long you already paid for Windows, of course). MSMQ provides Win32/COM and System.Messaging APIs. More modern Windows Communication Foundation (aka Indigo) queued channels also use MSMQ.
Note that MSMQ is not supported on Home SKUs of Windows (XP Home and Vista Home)
Its worth mentioning that the ActiveMQ open source project defines a C# API for messaging called NMS which allows you to develop against a single C# / .Net API that can then use various messaging back ends such as
ActiveMQ
MSMQ
TibCo's EMS
any STOMP provider
any JMS provider via StompConnect
You may want to look at MSMQ. It can be used by .NET and VFP, but you'll need to rewrite to use them. Here's an article that tells you how to use MSMQ from VFP. https://learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/ms917361(v=msdn.10)
Sorry if this isn't what you are asking for...
Have you considered some sort of cache behind the scenes that acts a bit like the "bucket system" when using asynchronous sockets in c/c++ using winsock? Basicly, it works by accepting requests, and sends an immediate response back to the web app, and when it finally gets around to finding your record, it updates it on the app via AJAX or any other technology of your choice. Since I'm not a C# programmer I can't provide any specific example. Hope this helps!
Does the Fox app use .CDX indexes? If so, you might be able to improve performance by adding indexes without needing to change any program code. If it uses .IDX indexes, though, the change would have to be done in the actual app.
As the problem is with writes, I would look more towards >removing< any unneeded indexes on the tables. As is common in RDBMS, every index on a FoxPro table slows down a write operation as the indexes need to be updated, and as you aren't reading directly from (or presumably directly querying) the table you shouldn't need very many indexes. You might also want to look at any triggers or field rules on the tables as they may be slowing down the write operation. Be sure your referential integrity is still preserved, though..