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.
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'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.
The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.
They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.
My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?
My question is will this cause
problems in PHP? Can PHP consume .NET
web services quickly and efficiently?
Or is this just a bad design decision?
I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.
The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.
For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.
The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.
I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.
P.S.:
I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.
The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.
PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.
WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.
Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.
Not really much of a problem at all, just investigate your options.
Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).
Look also into WCF services, I believe they're supposed to supplant the Web Service format.
Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.
I have seen a few examples where the architecture is that there is java on the server side and c# on the client - what makes this combination so good? why would .net on both sides not be a better choice (or in fact, java on both sides?)
added later: in lots of cases, the java is hosted on a windows server itself, i think via tomcat (not 100% sure) - what's the motivation here?
Java is frequently used on the back-end (and has become the de-facto standard) for a number of reasons:
Java can run on various operating systems transparently, from Windows development workstations to dedicated unix servers.
Java enforces a modular, object-oriented approach to coding, which allows for large-scale systems to be written (hopefully) without becoming unmanageable. (this is also true of C#/.NET, but not true of other back-end languages such as Perl or Python)
Java is frequently used in back-end systems (the more popular a language is for a particular application, the likelier it is that there are mature libraries and tools in that language for that particular application)
C# has great tools and libraries for designing UIs in Windows. Java's operating system (OS)-independent nature provides fewer tools for the particular quirks of an OS's UI, whereas C# is designed and maintained by Microsoft, for the purpose of writing Windows applications.
Well, there are a lot of cases where .NET is used at both ends (and I would guess ditto for Java). But my guess for the motivation behind Java-server/.NET-client architectures is that the application is targeting Unix as the server OS, either for cost or reliability reasons, or because it needs to fit into an existing Unix server environment (e.g. working closely with existing Unix apps), but is targeting Windows as the client platform. (I think Java is probably much less common where Windows is also being used as the server platform; no figures to back this up though.)
If a Unix server OS is assumed, then Java is a very productive choice, well supported with lots of libraries but with a larger developer base (at least in "enterprisey" environments), and more "management" recognition, than alternatives such as Perl, Ruby or Python.
Conversely, .NET is the better fit for the Windows client, because it has much better support for building Windows GUIs. It's not just the tooling: the Java GUI APIs themselves (e.g. Swing) tend to prefer cross-platform similarity over a native look and feel, and therefore tend to result in apps that don't look or behave like Windows applications. (I am generalising a bit here -- sorry!)
Data interchange formats like JSON make it far less important that the systems on either side of the connection are the same low level technology.
Java is a very well tested and supported language for servers, whilst C# has great tools for building GUI's.
Java is considered more mature, which is a good attribute for a server, whereas C# has better integration with/similar look and feel to windows and office (which the clients like)
Most servers are either Windows or *nix based. So at the server, either Java or .NET/C# (via mono on *nix) would be perfectly good.
Java has better support for different client devices, but in many ways that requirement is being replaces by the much better HTML support at most clients - at least for online devices.
For a installed client application, then arguably Java has the better portability - but with things like Compact Framework, Micro Framework, Silverlight, etc .NET is catching up.
Personally (due to job role), I care mainly what is at the server; .NET/C# has never let me down - but I'm not a Java developer, so I can't contrast directly. From work on open source projects I know there is a good community of people out there using mono on the server.
At the client, tools like WPF offer a first rate GUI experience, with .NET's support for winforms being useful for regular windows apps. But since a lot of the WPF architectureis common with Silverlight (with Moonlight as the mono twin for *nix etc), this allows the experience to be used on non-Windows clients too.
As far as Java is concerned two things
Linux. Its reliable and cheap. One of the many reasons enterprises use a lot of Linux for Java because they don't have to reboot boxes after Patch Tuesday.
Hotspot. Its one of the wonders of the modern world - amazing performance.
Fortyrunner, I haven't seen a single benchmark where a hotspot JVM will beat MS CLR.
On the server side Java has proven to be robust and scalable and it is available on platforms that .NET can only dream about. Hence if you want the most choices in hardware Java is an excellent choice - this includes very large machines with many CPU's as well as lots of clustered cheap x86 boxes.
If you have .NET on the server side you must use Windows, and Windows simply doesn't scale well hardware wise.
How would you describe and promote WCF as a technology to a non-technical client/manager/CEO/etc?
What are competing solutions or ideas that they might bring up(such as those they read about in their magazines touting new technology)?
What is WCF not good for that you've seen people try to shoehorn it into?
-Adam
Comparing with .asmx: WCF is the next generation of Microsoft's Web service development platform, which addresses many of the issues with older versions, specifically:
better interoperation, so you can interoperate with Web services that aren't from Microsoft or that are published on the Internet
much more flexible, so it's easier and faster for developers to get their jobs done
easier to configure without changing code, reducing the cost of maintenance significantly
It may be that they raise the question of how it relates to SOA, a "service-oriented architecture". WCF is the Microsoft solution for creating applications that participate in these distributed systems.
Tell them it'll let you do your job easier which translates into less time and less money.
In a single sentence, I'd say that WCF is "software that lets you set up and manage communication between systems a lot more efficiently than in the past".
I can see them bringing up BizTalk as a competitor, but of course you could say that WCF works with it and is in fact used as base technology for it in the more recent versions.
I'm not sure if I can think of any inappropriate shoe-horning of WCF that I have seen, although there are plenty of legacy apps that will probably be "upgraded" to WCF that don't really need to be for any real business reason.
There is an inter-op angle as well. If you upgrade your Asmx services to WCF services you can still honor your asmx clients and then start moving forward with newer WCF clients. WCF is starting to get some ReST attention, RSS is there, Silverlight has a place with WCF. Performance is better, depending on the bindings you choose. One of the big draw backs is a steeper learning curve comapred to Asmx services, the great power/great responsibilty problem and then the 101 ways to do the same thing.
None of this is CxO talk but refactor the language into magazine buzz words so that they can see the future of this technology.