As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Why is the Mono project implementing WCF interfaces and classes "as is"?
I do not understand what is the point to repeat Microsoft's design. My experience says that WCF is a huge framework with an implementation based on SOAP services. There are tremendous problems with their approach. It simply does not fit well for simple HTTP request processing cycle. Why not try to invent a better framework instead?
Update:
OK, I get it. :) I like the .NET platform, C# and I like that this platform is available on another OS, but ...
Don't you guys see that many things in the original (Microsoft) frameworks can be done better?
Look at System.ServiceModel.Channels.Message. This is one of big things of customization landscape.
Why do I see XML everywhere? How can I easily do anything with classes like this? It is feasible, but I cannot say this is good design for a general purpose communication framework. I thought that the purpose of the Mono project is not just bringing the .NET ecosystem to unix* but make it better.
I think the whole point is to make WCF platform available in other operating systems than Microsoft Windows. So, if you have an application developed with MS VisualStudio (Microsoft's compilers), you can deploy it on Linux or Mac OS X if you wish.
You can also use MonoDevelop and Mono Compilers if you decide to code WCF in alternative platforms.
Because not everything is suitable for a simple http request processing cycle. Because SOAP offers features REST does not. Because it hooks into a wide set of encryption, authentication and authorization options. Because what you see as as tremendous problems solve problems for others.
Mono exists to allow .net on other OS's. Mono is not about picking and choosing what to implement based on merit.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am going to develop an application for OS X and I need some scripting engine for it.
The purpose of the scripts is to receive a text on their input (HTML file in most cases), parse it in some way and return the data to my app. These scripts should be easily editable by the users, therefore they should have some common used syntax like C or pascal.
Can you suggest some lightweight solution for this?
Thanks!
PS. I am new to OS X development, trying to switch from Windows...
Two suggestions:
Javascript, try the V8 engine. http://code.google.com/p/v8/ Very popular, likely familiar syntax to many.
Lua. http://www.lua.org Extremely lightweight and simple to connect. If your script editors write scripts for World of Warcraft, for example, they will know Lua.
In general AppleScript/Automator actions are easy for the end user to work with since the technology includes a GUI for building scripts without much programming knowledge. For experienced developers used to other languages, they can be a bit too friendly/loose and have a somewhat different syntax (more like plain English). The good thing is that they can also call other languages as needed, so a developer familiar with Perl or whatever could incorporate that into an AppleScript or Automator action.
Since you're talking about parsing text, Perl itself would be a good solution - again there's some difference in syntax, but the scripts can be rather compact and the basics of parsing aren't too difficult to learn. I haven't personally incorporated Perl into an OS X app, I've just used it on the command line, so I don't know if there are any pitfalls to that approach.
One additional advantage to AppleScript is that you can make your application itself scriptable so that users could automate the functions of your application into a larger workflow.
I would suggest downloading the free TextWrangler application by Bare Bones Software, or a similar developer's text editor, to see how they incorporate scripting into the application. This may give you additional insight into your approach.
LUA seems to be a good choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the pros and cons of using a rest service vs a wcf service?
I am wondering which type to use and I was interested to find some sort of comparision.
Rest is a way of doing communication over the internet. It is a very basic process of picking addresses to serve as method locations and returning HTML standard data (javascript, css, html of course).
WCF is a .net library used to have two programs talk to each other using SOAP. Which consists of two very familiar programs trading class info.
Seeing as Rest is a process, and WCF is a class library, a better question might be "Rest vs Soap".
The bottom line is, if you need two apps to talk, you might want to use WCF. Even if the apps are not both written in .net. However if you need information to be accessed by web tech(usualy javascript access is done this way) you'll want to use Rest.
Just a quick side note though, WCF does Rest well too, so you realy can't go wrong there.
You're asking a question about apples and oranges. REST is pattern used in creating web services. I'm not an expert on it, but you can find plenty of details on Wikipedia. WCF is a Microsoft technology for creating web services (primarily using SOAP, although it's so configurable that you can do REST on it as well - see ASP.Net WebAPI).
Pros for WCF:
Very configurable - If you can imagine it, WCF can probably do it.
Simple to use if you're sticking to the Microsoft stack. Visual Studio does 90% of the work for you.
Cons for WCF:
Very configurable - It can be a bit of a pain to get it do exactly what you want sometimes, especially if you're new to it.
There can be some problems communicating between different technology stacks. I've heard of Java services curling up and dying when pointed at a WCF service. As far as I've heard, this is a problem with the Java libraries, not WCF, but who knows for sure.
That's all that comes to mind right now, but hopefully that gives a you a decent impression on WCF.
If you are absolutely sure that HTTP is the protocol you want to use and you want to embrace it as an "Application" protocol, not just a "Transport" protocol then something like ASP.NET Web API.
If you building a service for your servers in your datacenter to talk to each other then seriously consider WCF.
Whether to do REST is a completely different question. Will this service last for many years? Will it have many different clients? Will some of those clients be out of your control? If you answered yes, then it may be worth investigating what benefits the REST constraints can bring.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Could you tell me the open source alternatives to WCF??
I'm a newbie and just started using WCF. I wanted to know about the alternatives that are open source too.
Also, what makes them better options/not so good compared to WCF.
Thanks,
Thothathri
There are open source projects for REST services - for example Open Rasta Perhaps you will also find some open source projects for basic SOAP services but I doubt that there is an open source project implementing all WS-* related stuff implemented in WCF. WS-* protocols are mostly implemented only in API from big companies - MS, IBM, Oracle, SAP, etc. Reasons are:
Complexity - implementing WS-* protocols means diving deep into tons of specifications. You must also implement them very carefully to be really interoperable and to do not reduce performance too much.
Support - WS-* protocols are usually used in B2B solutions where enterprises demands some guarantees and support.
Costs - developing such API takes really long time.
Even WCF implements only subset of WS-* protocols. But WCF is highly extensible so anybody can try to implement some of these missing protocols himself.
WCF doesn't states only for REST and SOAP services. It is also replacement of .NET Remoting and Enterprise services from older .NET versions. You will not find a .NET API which will also offer all this functionality.
I also highly recommend checking out ServiceStack, it's a config-free web service framework I started that lets you easily and rapidly develop web services with very little friction.
It provides an expressive friction-less environment as you're able to develop web services by using you're own POCO C# DTO's which also encourages best-practices web service development since you're easily able to create more batch-full, coarse-grained APIs.
It's aims to be more productive by closely fusing C# with HTTP where all C# objects returned get automatically serialized to the requested format with (XML, JSON, JSV, CSV, SOAP 1.1/1.2, HTML) supported out-of-the-box. C# Exceptions also get automatically serialized for you making the tedious things effortless.
One of the major benefits is not needing to be concerned with external formats and endpoints (which are taken care by the framework) and you're left with developing your logic in a clean-room, auto-wired and highly testable, DDD-like IService class.
You could use RestCake if you're trying to create RESTful services.
Mono project has an ongoing effort for WCF hosted in Github. As you know, System.ServiceModel is the main engine for WCF. You can find Mono implementations of these namespaces under /mono/mcs/class/System.ServiceModel.* . You can find project related updates and relevant contribution information here
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
If you've worked on a cross platform development project what advice do you have for someone (like myself) considering starting one? Examples:
What worked?
What didn't?
What problems did you run into and
how did you solve them?
Did you aim for consistent appearance
and functionality across all platforms
or try to take advantage of each platform's strengths?
What language and cross platform libraries did you
use and did they live up to their claims?
Was it a desktop, mobile or web-based application?
I worked on a small cross-platform project. The app was a desktop app, distributed directly as an executable on USB.
Did some research initially - you might be able to trace my stackoverflow questions - and settled with Mozilla's XULRunner.
It worked really well in terms of being cross platform - you're basically running off a well cross-tested platform that runs firefox and thunderbird, so the crossability (is that a word?) is pretty bullet proof.
Its first flaw I thought was the documentation - there is a lot out there, but it's a bit obscure at first.
But then, the mozilla forums community is awesome, really friendly and helpful.
In terms of development, it's all javascript and a bit of html-like marker language called xul and styling using css (you can also build extensions in c++ if you need, but the core is pretty powerful as it), so it's pretty familiar right away and pretty flexible too.
XUL gives a good platform-specific native feel to the apps (IMO), or you can re-do entirely your chrome elements and make a custom ui.
One major gotcha with XUL is that because of the way XULRunner works, your source code will be more or less pretty much viewable by anyone. If you have proprietary code this may not be ideal for you - or you will need to isolate in a separate library written in c++ (XPCom components in Xul terms).
I'd highly recommend it. I had a pretty short turn around time frame to build the project and it really saved my ass. I did the development on a Mac, and it worked right away on PC without any major change.
Additionally, there was other platforms that I reviewed for this project.
I've seen some strong support for cross platform UI kits & languages like QT (with PyQT for instance), or tcl/tk and such. I wasn't too taken by it but you might want to look into it.
Some people suggested AIR, JavaFX and .NET/Mono. For me this wasn't viable as it's too much of a dependency on some systems (XP doesn't come with Java, Mac doesn't come with .NET/Mono, neither come with AIR). If you want something that will just work out of the box, that doesn't fit the bill. But your requirements may be different.
Titanium (from Appcellerator) is probably the closest contestant to XULRunner. It seemed great, quite powerful but the desktop development edition has pretty awful debugging features compared to XULRunner. Their agenda is more toward the mobile dev edition, which I can understand, but I wish they'd care more for the desktop edition. However, if cross-platform mobile development is what you're after this may be good - though I haven't tested it for that purpose.
Hope this helps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Can anyone point me to a cognos API document and some example code? The best for me is that the API can be access thru python. But examples in other languages are good also.
The Cognos SDK for .net is horrible; I know because I just spent 3+ days trying to get even basic functionality working. Its clear that the person who developed the sample applications has no idea how to work with Web Services or .net.
I managed to find a Cognos.WSDL file that you can try to use to generate your own proxy classes; but; its not WS-I compatible and thus won't work with wsdl.exe
The cognosdotnet.dll and cognosdotnetassembly's are overbloated. There are nearly 1000 classes defined in there. They basically wrapped up their entire API set into a single assembly.
Cognosdotnet.dll defines all the types; and many of them are confusing to work with; but all the raw materials you need are there.
Cognosdotnetassembly.dll defines the serializers. Why they even include them is beyond me. This file is huge (46MB) and provides zero value. The problem is that there is a dependency on this assembly with the type definitions (cognosdotnet.dll).
What I ended up doing was taking Refelector; and code generating the cognosdotnet.dll; then removed the dependency on the serializers. I then created my own wrappers around it to make the API more friendly.
I would recomend starting with the reportrunner example as a starting point; to at least try and get your connectivity working etc..
You haven't indicated which version of Cognos you're seeking assistance for, but if it's for Cognos 8, you should have the full API docs and sample code if you have the Cognos 8 SDK.
The SDK samples are provided mostly in Java, though some are .NET.
The SDK Developer Guide (again, Cognos 8) should contain enough information to help you get started on putting your own library together.