I'm looking for a technology which is targeting on building distributed applications. My friend adviced me to use CORBA (Java & C++ combination) . But I have read it's sort of obsolete stuff. I'm planning to write rather simple distributed application. What solutions would you advice to use? Thanks!
If you want to distribute your code logic to multiple servers and have it managed as a single entity, I would recommend CloudIQ Platform from Appistry. You can deploy Java, .NET and C/C++ code to the framework. From an administrative point of view, the servers work and act as one. When you submit a request for execution, the framework distributes the request to the best available worker, performing load balancing. With this framework, you can have producer/consumer, scatter/gather, and other parallel types of jobs.
The framework also monitors the execution of jobs, so if there is any type of hardware failure, other machines will get allocated the jobs that were running on the failed server.
CORBA is quite old. To choose a library or framework, the questions are: why do you want it to be distributed? (what's the goal? performance / parallelization? scalability? physical constraints on locations of parts of the system?) Which sort of nodes will be running the various parts? What languages would you rather use?
Recommend using ICE(Internet Communications Engine), ICE can support multiple operating system platform (Windows, Linux, Solars, Mac OS, iOS, Android...), multiple developing language (C++, Java, .NET, Python, Ruby, PHP), and it is simpler.
You can use SOAP web services. I'm currently developing distributed testing system on Python & .NET using using SOAP and it is easy to write and deploy.
There are a lot of different SOAP server/client libraries for different languages and platforms.
Yes, CORBA, and technologies like COM and DCOM are all pretty much obsolete... I am not sure exactly what you want to accomplish, but I would look towards .NET remoting to build distributed applications. If your application is really simple, you can even use mailslots or named pipes to pass simple data across a network.
As sinelaw mentioned, there are many questions before a good suggestion can be made, but, you may want to look at REST (http://en.wikipedia.org/wiki/Representational_State_Transfer) as a way to transfer data between applications. REST is nice in that what it can accept and return are flexible, for example, you can upload a file and return a PDF. Though it is used on http, that isn't the only allowed protocol. It is language/platform agnostic.
If you want to go with something that is standardized then SOAP or REST is probably your best bet, if you want to be platform-independent. If you don't mind being restricted to Java/JVM or .NET then there are other options, but that becomes very restricting.
What type of data is being passed? How critical is security? What platforms/languages should be usable? What is the purpose of the program, the goal?
If you want a portable solution that can also be used with different protocols, WCF on Mono might be a good fit
For .Net I suggest you WCF , it's quite simple to implement and very flexible, and about CORBA it's a good choice if your goal is to understand deeply distributed applications, but it's not more recommended for real projects, currently is very difficult to find developers mastering CORBA.
Related
Alright, so I've asked several questions on StackOverflow about .NET Remoting, and there is always at least one person who just has to chime in, ".NET Remoting is deprecated, use WCF instead." I understand that it's deprecated and there is no guarantee of future support with new versions of the .NET Framework. But what are some other good reasons we would want to move over to WCF? I have seen a few mostly minor annoyances with .NET Remoting, however, this is not enough to change the minds the powers that be who believe firmly in "if it ain't broke, don't fix it". At this time, the only reason that attitude will change is if .NET Remoting is removed from a future version of the .NET Framework, so who knows how long that will be?
Does anybody have any insight as why exactly WCF is "better" than .NET Remoting, or why Remoting is inferior to WCF? What are the pros and cons of each technology? Are there additional things you can do with WCF and not with Remoting?
I mean, it would be great if I could convince them to let us migrate our software over to WCF just to allow a configurable TcpChannel timeout to be set on the client side (this seems to have been broken for a while, no matter what steps or troubleshooting I try), and when this happens, it makes our software look like absolute shite.
Thanks in advance for helping to shed some light on this.
There are plenty of reasons to ditch remoting; a few might include:
lack of transport flexibility
versioning requirements are huge pain
platform dependent (no sensible chance of cross-platform usage)
no chance of usage from the growing mobile market
lack of future development: whatever feature you want added - it won't be
however, I would disagree that WCF is the automatic replacement; WCF itself is a pretty versatile tool, but can be pretty complex, and has restrictions of its own. I haven't used it myself, but I have seen lots of praise for Service Stack, essentially with users describing it as "WCF done right", i.e. the good bits of WCF, without the pain points. However, there are plenty of other options too. One nice thing about the idea of Service Stack, though, is that it iterates pretty quickly, and if it lacks something you want you can change it.
.NET Remoting is now a legacy technology, quoted from MSDN:
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
And here is a performance comparison between WCF and .NET Remoting done in 2007: http://msdn.microsoft.com/en-us/library/bb310550.aspx
To summarize the results, WCF is 25%—50% faster than ASP.NET Web
Services, and approximately 25% faster than .NET Remoting.
So I guess speed is a good reason to drop .NET Remoting.
While the given reasons are probably the driving considerations there are other non-trivial reasons:
Transport independence
IDE tooling
Ease of testing
Maintainability
When you use WCF you can change transport merely by editing your config file. This can be very handy when some sanctimonious system admin won't open a port and you need to use HTTP on port 80 to get through the corporate firewall.
The WCF tooling in Visual Studio is phenomenal. The hardest part is figuring out the URL you need. After that it's just point and click for code generation. There are one or two gotchas with serialisation of collections but broadly speaking if you tell both ends to use arrays it will just plain work. If you need a collection at the destination you can always construct one around the received array, and since LINQ will happily operate on arrays you can fold this into other transformations.
I'm not sure what Stephan P means by pain points. Editing the config can be tricky but Microsoft provides an excellent GUI tool that takes all the guesswork out of it by providing a full tree of options yet generating a sparse config file.
WCF services are easy to test because they have a published interface to which you can connect a test harness. This is more a virtue of SoA in general rather than WCF in particular, but it's still desirable.
WCF makes things a great deal simpler in my code, since neither application nor service is polluted with "routing" code (to determine what ought to process the message content); it looks like simple method calls or implementations. I mostly use WCF as a wrapper for MSMQ, and the only visible consequence of the transport selection is that these method calls must all be void functions because it's a OneWay transport. But that's hardly surprising when the point was persistent queueing.
This all speaks to maintainability. Even for in-house applications, maintenance is a dominant cost, and when you're supporting your software at customer sites poor maintainability can be crippling.
Then there's interoperability with otherwise incompatible platforms. In this case I'm thinking of using HTTP/XML or HTTP/JSON to provide service to web apps written in (eg) PHP.
Going the other way isn't quite so easy but it's fairly straightforward.
I give points for WCF with respect to logging and security.
Logging
WCF has an integrated Logging mechanism that helps you log traces that become a boon during maintanence. In other technologies, developer has to do some work to achieve this but in WCF, all that we have to do is to enable trace by changing the config file and WCF starts providing traces for you.
Security
Security mechanism in WCF is fairly simple and out of box when you look from the implementors perspective but is very robust and highly secure. The best part is that for the highy used and recommended bindings, WCF provides default security which can be trusted to the core. The message security on WSHTTPbinding is an example on these lines.
.NET Framework remoting does not do authentication or encryption by default. Therefore, it is recommended that you take all necessary steps to make certain of the identity of clients or servers before interacting with them remotely
Moreover WCF is an framework to develop Service Oriented applications under microsoft platform mixing both message and rpc style of programming. Which was not in the remoting. Remoting is basically oriented to rpc only.
I am quite aware of both java and C# .Net .when i try to create a new windows application which are the factors that decide which technology should be opted?
I know of one thing ,for great and faster UI development Visual studio helps a lot.
There are several factors I would consider...
What are your programmers used to working with already? What third party libraries are you likely to need, what's available on both platforms?
Does platform independence matter to you?
Would LinQ be advantageous?
If you're starting from scratch, costs for the platforms?
Both platforms have strong communities around them...
Hope this helps...
Dotnet is pretty much native in Windows which obviously makes it more suited to writing Windows programs. Using Java in a Windows-only environment makes it much harder for you since it effectively just adds another unnecessary API layer.
You will soon realise that all integration points between your Java code and Windows are a bit problematic. For instance, creating installation programs, access file system, reading/writing the registry, starting/stopping services, task bar icons, using Windows GUI components (media player, IE...), help file system...
It all boils down to this imo: The Dotnet framework is much richer in terms of functionality than the Java dito, mainly becuase Java is cross-platform and thus needs a "one-size-fit-all" approach to its API. My experience is that you will only get frustrated trying to "emulate" a Windows native program in Java.
Choose the one with which you are most familiar. The two platforms are different enough that skills from one does not transfer easily to the other.
In any case, try making a trivial application in both your scenarios and see how it works for you. The initial impression is important as it is probably indicative of how well the rest of the work will be.
It also depends on what kind of windows application you want to build. If it's just a question of building a simple standalone application then, considering you know both languages equally well, I wouldn't hesitate and would go for a 100% microsoft solution, especially if you have to do specific things like accessing ActiveDirectory, the windows registry, etc.
Not that you can't do it in Java : you can always use AD through LDAP in Java for example, but the APIs are just "a bit" more complicated than the .Net ones (try to decode objectSIDs in Java without a few tricks).
Now if you have to build an enterprise app. I just feel that popular frameworks like Spring and Hibernate are always coming out after their Java counterparts (disclaimer : this is a personal opinion; I didn't do any research on this, thoroughly comparing frameworks in both languages, but that's just the feeling I have). I don't know how good the .Net implementations are though, so I don't have a point of view on that. I just remember writing .Net 2.0 apps and not liking ADO.Net at all.
My view is that the frameworks I like do exist in both languages, but they are first developed for Java, then ported to .Net.
Now I'm not the kind of developer trying to defend his favourite language over the others. If I don't have external constraints to develop, then I choose whatever language gets my app up and running faster and in the most efficient way.
...But with java you will have crossplatform application on scratch.
Also coding UI in java is not difficult - if you read some guides before and use some frameworks as swing application framework or SWT framework.
If its Exclusively for Windows then .Net is best bet.
Yeah for a pure cross platform application Java can't be beat, but if you can manage it Silverlight is a subset of WPF and a pretty compelling cross-platform proposition on its own.
Productivity-wise I think WPF has an edge as it has a nice XAML markup language that can be easily created with the built-in designer in VS.NET or integrates nicely with MS' suite of expression products.
While this stems from the age-old debate between Java and .NET, I'm interested in the merits of these two technologies in terms of SOA/web services.
I'm starting a new project writing web services. I don't have extensive experience writing them in either Java or C#, and I'm open to using either a Microsoft stack (running IIS) or a Linux stack (running Tomcat). So far in my research, the complexity of the two languages seems to be about equal.
I'll be running a MySQL database (SQL Server is out of the question). Database access thus has no bearing on the rest of the stack.
I will be consuming REST services (and possibly SOAP as well), and exposing SOAP services.
What are the advantages or disadvantages of these two technologies in terms of ease of use, complexity, typical development time, total cost of ownership (esp. maintenance costs), etc.? Which has better integration to existing security and authentication frameworks (e.g., CAS, LDAP, or OAuth)?
While I am a java proponent and have little C# experience, I will honestly say they will likely be about equal, and you should go with whatever language you are most familiar with and comfortable in programming.
On the Java side, both exposing and consuming web services (SOAP or REST) can be easily done via open source libraries (and there may even be some stuff built into the JDK at this point, although usually they are a bit behind the open source community), one of the most popular being Spring. This will do for you all the complexity and plumbing around creating and consuming SOAP, and exposing or consuming REST.
For SOAP:
For REST:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/
For SOAP:
http://static.springsource.org/spring-ws/sites/1.5/
Note Spring is just one option (but a good one), but my overall point is don't write the plumbing yourself, choose an existing framework to do it for you and it shouldn't matter what language you use.
As mentioned I don't know much about C# but what I've found is they usually take the good parts of the core JDK and the open source java community and build it into the language, so there may be some nice native stuff in C# that mirrors what Spring has done for Java.
I need to monitor several systems going thru stress testing. I want to make a client-server .NET(C#) application that will ping the systems to check temperature, memory usage etc.
The client will provide system info (cpu-mem-hdd configuration) at start then it will undergo through several benchmark/stress tests. The server will keep track of what is been executed and also will be able to detect system crashes. I pretty much have all the code for the client (have been running on the system, using WMI)
I have no experience with .NET remoting nor WCF, but I think this is a great opportunity to learn them.
What technology would you use?
WCF is meant to unify .net remoting with a handful of other Microsoft technologies. WCF gives you a lot of flexibility to change the design of your client-server architecture simply by changing a few .net attributes.
I recommend you proceed with caution and make sure you have a good WCF reference at hand. You will spend a lot of time spinning your wheels in the mud without one.
Snmp, maybe based on http://www.snmpsharpnet.com/.
Nothing fancy, new and shiny, but a protocol that is meant to be used for exactly the stuff you describe. Would definitely be my first choice.
If that is not an option for you: Second choice for me would be WCF, because that can be used from different platforms (you are more flexible in the future).
i will choose service bus.
What is the best and easiest method that can be used for inter-process communication in a very large project?
My requirement is to communicate between a normal Windows Forms Application and Windows Services.
Methods that are easy to maintain and implement are preferred.
Thanks
From the tags I understand that we are talking about .NET. Perhaps you should try Microsoft WCF. It unifies this issue, abstracting specific inter-process (inter-service) communication technology from actual code. So generally you'll design and write the interfaces that your processes will use to talk to each other and then you'll configure a specific communication technology in XML config file. That is, you have rather clear separation between "what do the processes talk about" and "how is this communication implemented specifically".
WCF supports SOAP, TCP\IP communication, MSMQ etc., you processes can be IIS-hosted web-services, usual Windows services, console applications etc. - all this under unified framework. I think, this is exactly what you are looking for.
It really depends on the project as there are a large number of methods.
This may depend on where the different portions of the project run (They could run on different servers, or different technology stacks altogether.).
The most common method is probably web services. Although these come with an overhead, so it may be worth looking at a simple interface API via a DLL.
Whatever you do it should probably be thought about and designed carefully, considering security and performance, and how you will extend or modify it in the future.
Not necessarily the best or the easiest....
In the .NET world try MSMQ or IBM MQ message queue middle ware.
If the communication is mostly 1-way, then consider using WCF services, which are both good and easy if you let the code generators in Visual Studio do most of the work for you.