We are working on SOA, both on client (Silverlight) and server (WCF) sides, but with possibility of the clients being implemented by 3rd parties (.NET, Java, etc.). We use WSDL-first approach and want our data and services interface classes (C#) to be automatically generated from schemas during build process. So we need common data classes code not being regenerated for every service for successful compilation.
I have tried the svcutil utility, trying to first create all data contract classes from XSDs with the /dataContractOnly switch, and compile them to separate class library - the first stage. And then to create each service interface code, omitting the classes already in the library, with the /reference switch - the second stage.
The problem is that our schemas do not meet the DataContractSerializer requirements, so svcutil cannot create data classes. Even after I used xsd utility for this purpose, I cannot use svcutil's /reference switch on the second stage, since this switch only works for DataContract classes. And this is not the case with the classes generated by xsd utility.
So, am I missing something with these tools and are there any way to use them in my situation, or are there any other tools to generate data classes and service interfaces from XSD and WSDL schemas, in case where common data types are used by several service interfaces? Or should we hardly limit ourselves with DataContract compatible schemas? What approach do you use for WSDL-first development?
Have you tried WCF.blue tool by codeplex?
WSCF.blue is a toolset that facilitates the development of web services using a contract first (specifically, a schema first) approach. This is the WCF version of the orginal Web Services Contract First tool.
Also, there is a beautiful article on Contract-First development:
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx
Yes WSCF.Blue is a VS plugin as it ships but the source is available and so it can be rebuilt into a command line interface version like what we had to do, with little effort required I might add.
Related
Our new iPhone project consists of a native app and a server it needs to communicate with. I'd like the server to be written in Python/Django.
The last time we created something similar, the server was in written in asp.net and it exposed relevant methods as a SOAP-based web service. This was very convenient, since we were able to generate almost all server communication code from the WSDL using http://sudzc.com/. Now I basically want to do the same, but with Django instead of asp.net. More specifically, I want to expose methods and objects over an API and I'd really like to have some automatic Objective-C code generation at the other end.
I've looked at a few libraries for Django that are supposed to expose RESTful APIs, and most people seem to recommend django-piston or django-rest-framework. Will either of them have a WSDL-style description that I can use to auto-generate ObjC-code, though? Is there another set of tools for achieving what I'm after that I should be investigating?
In my personal experience I don't know of anything that exists to generate client-side stubs in Objective-C for a REST service. However, there's a very good library called RESTKit that features a JSON or XML to object mapping layer, and nice features like CoreData integration and local caching. There are number of useful Stackoverflow questions on it.
So that can get you part of the way, since it will handle communication and object mapping. If you need to build code-generation, it could output code that sets up RESTKit's mapping structures.
Another REST client lib for iOS that I like a lot is LRResty, for its clean API, but it's lower level than RESTKit in that it doesn't have any built-in parsing/object mapping features.
In this similar stackoverflow question there's a link to something called wsdl2objc which sounds like it's in line with what you need on the iOS side (I've no personal experience with it, so ymmv, etc...)
My question is very simple, and I want a clear answer with a simple example.
What's the main difference between API, Toolkit, Framework, and Library?
I prefer following:
An API is an abstract description of how to use an application. For example, an API may describe the function syntax (declaration) of a chat server. i.e. login, publish_message, subscribe_messages. And, it describes any protocols to use the application. i.e. must login before sending or recieving messages, or clients are dropped after 2 minutes if not sending or receiving messages.
A library is an implementation of an API, it containes the compiled code that implements the functions and protocols (maintains usage state).
A toolkit is a set of libraries (API) and services grouped together to provide the developer with a wider range of possible solutions. For example, the Globus Toolkit provides services (such as File transfering, Job Subission and Scheduling) that a devleoper can install and start on their servers. They also provide API's to build applications that may use the services deployed in an integrated fashion. For example, the developer may build a program that uses the Job Submission API to communicate with the Job Submission Service.
A Framework is a set of guidelines that prevents inappropriate use or developement. The developer must contruct their applications within the rules and boundaries of the framework. This is done by forcing the developer to extend the current framework to develope new software. by extending the framework, you force adhearence to the framework.
I'm not saying these are completely correct, but its worked ok for me so far!
This has always been my understanding, you will no doubt see differing opinions on the subject:
API (Application Programming Interface) - Allows you to use code in an already functional application in a stand-alone fasion.
Framework - Code that gives you base classes and interfaces for a certain task/application type, usually in the form of a design pattern. (Though not always)
Library - Related code that can be swapped in and out at will to accomplish tasks at a class level
Toolkit - Related code that can be used to accomplish tasks at a component level.
Those terms sometimes are misinterchanged.
Similar posts, read:
What is the major difference between a framework and a toolkit?
Framework vs. Toolkit vs. Library
I prefer to call a library as an alias of module or namespace. Toolkit and A.P.I. is usually a set of libraries for a common task. Altought, A.P.I. is more used for Procedural Programming than Object Oriented Programming.
what is the difference between these two terms, thanks in advance for any good simplifications and good examples.
A framework is a group of classes, interfaces and other pre-compiled code upon which or by the use of which applications can be built.
The API is the public face of a framework. A well designed framework only exposes those classes, interfaces, etc that are needed to use the framework. Code that supports the operation of the framework but that is not necessary to users of the framework is kept internal to the framework's assemblies/dlls. This keeps the public face of the framework small and encourages a "pit of success," or the quality of a framework which makes it simple to do the right thing.
(I provide an example from the .NET world)
The SqlConnection class is used to connect to a Sql Server instance. Its public API is pretty simple:
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
// Do work here; connection closed on following line.
}
However, this class depends on around 200 methods within the System.Data framework (in this case, an assembly), 3/4 of which are internal and not part of the public API of System.Data. Because the framework's API is kept simple, it becomes easy to use SqlConnection properly. If the user was required to deal with SqlConnectionFactory, SqlDebugContext, DbConnectionPoolGroup or any of the other internal classes required by the SqlConnection class, it would become exponentially more difficult to use SqlConnection properly. Because the API only exposes a small percentage of the framework, it is easier to create and use a connection.
An API is an interface to a (set of) component(s) encapsulating a functionality. For instance, the GoogleMaps API, the DirectX or OpenGL APIs.
A framework is more a set of tools, components aimed at helping the developer to develop his/her project in a given Frame. The framework usually sets some coding standards, provides useful components, ... For instance, Symfony/Cake are PHP web application frameworks. JUnit is a framework for unit tests in Java, ...
Frameworks can often bundle/provide a unified interface to some APIs.
Some APIs can be internally built using a framework.
API - application programming interface -> the contract you must obey when using a library's API
library - a set of classes/modules that solve a specific problem -> has an API
framework - a "bigger" set of libraries with a set of rules on how to use them
Since every library has an API, no point in giving examples.
A popular Java library for time is Joda time.
A popular Java framework is the Spring framework.
You must obey a lot of rules to use Spring well. You don't have to obey as many rules to use Joda time.
An API is something code has, not something it is. A framework has an API, but it is not itself an API.
API "Application Programming Interface" is set of prewritten packages, classes and interfaces with their respective methods. You can use it without much concern about internal implementations. API is used an interface between two or more applications and like REST API.
Framework is a skeleton that contains design patterns, classes, interfaces and libraries that can be used to build applications. Framework provides inversion of control which give the responsibility of program flow to the framework itself, also we can extend the framework without changing its predefined code. For example Spring is a framework that can be used to build web applications.
API's are pre-built-in from SDK (or from which you can include on to). Frameworks are loadable bundles wherein exposed functions of such bundles can be used. You can acquire expose functions of those frameworks by using pointer to functions.
Example:
API:
-stringWithString:
function from framework:
-myExposedMethod:
Framework is use to design an application, ie MVC, MEF. Like a model that you build on, almost a base for a certain set of functionality that you might want in your application.
API is for interaction between applications, your app would use the Facebook API to interact with Facebook.
Hope this is a bit more clear.
Java API simply means ...Application Programming Interface in which all the features describes of product or software.
Java Framework means semi-completed project or code. It provides an architecture to make project . Framework have own classes and methods etc..
An API is simply a library built with a particular language that developers can use to build applications.
Frameworks are a set of libraries, just like APIs however the syntaxes may deffer of the original language. So the developer may be writing a different syntax of PHP for example when using Symphony.
The main or core difference beteen framework and API is that framework allows developer to hook into the life cycle of the objects through lifecycle callback methods mechanism whereas API doesn't do that, API is only intended to perform a functionality only.
Another way to visualize it is this: (true of any programming language)
Any(!) "piece of software that is intended to be used by another piece of software" by-definition must have some "application program interface (API)," which represents the "knobs, switches and dials" that the other piece of software is expected (and, permitted) to use. All of the internal implementation details are not visible and cannot be reached.
"Frameworks" are tools that are designed to make it easier for humans to write a particular, common, type of application – such as a web-page. The framework implements "the stuff that every such application is going to need to be able to do," and does it in one, well-tested way, "precisely so that you (the application author) don't have to." Instead of redundantly writing "the same old thing, one more time, and fretting over whether you did it correctly," you simply leverage what the framework has already done for you.
After all...
Actum Ne Agas: Do Not Do A Thing Already Done.
I have been wrestling with SvcUtil all day, trying to get it to generate useful code for some IMS Enterprise Services (primarily Group Management Service, but there are others we need it to work for as well.) You can find the IMS service WSDL's here http://www.imsglobal.org/es/index.html.
I have come to the conclusion that SvcUtil is a useless afterthought from Microsoft that doesn't support the WSDL and XSD standards even in a half-assed way. It is incapable of generating a WCF service that conforms to the standard WSDL contracts that IMS uses AND functions at the same time. Despite generating compilable code from the following WSDL (http://www.imsglobal.org/services/gms/wsdl/imsGroupManServiceSync_v1p0.wsdl), observing the generated WSDL from the WCF service (?wsdl, ?wsdl=wsdl0, ?xsd=xsd0, etc.) shows that none of the operations exist, and only a fraction of the types that were generated in code are actually recognized by WCF. If we screw with the generated code, we can get something that sort of functions (we are using SoapUI to test), but then it no longer conforms to the contract, so its useless to the people who really need to call these services.
Are there any alternatives to SvcUtil? (Please don't suggest the built in Visual Studio "Add Service Reference" tool, that is just as useless as it uses the exact same code as SvcUtil.) We need something that will give us a degree of control over how code is generated from the WSDL contract, what files each part ends up in, which namespaces each code element ends up in, etc. The IMS contract imports both XSD types specific to the services defined in the WSDL, as well as XSD types that are common to all IMS services. We need to be able to generate different assemblies for those types, and reference them in the generated code (similar to how SvcUtil is apparently supposed to do it...but it doesn't seem to do what it says its documentation says it does at all.)
I have been a huge fan of WCF until now. It obviously works when you use only .NET/WCF services, but any time you try to use it in a standards-compliant, cross-platform environment, everything goes to shit.
Have you had a look at the WCF Proxy Generator on Codeplex? Based on who's behind it (Kate Gregory and Michele Leroux Bustamante), there's hope it might be useful - plus you get the sources, so you can adapt / tweak at your heart's content!
(haven't had the time to take a serious look at it myself - yet - it's on the endless "To-Do when I get around to it" list....)
Plus check out this blog post here by Pedram Rezaei showing how to influence the Visual Studio "Add Service Reference" step with your own custom code.
Sorry that I don't have time in full to reply to this but there is an answer to your question. There is an interface that you can implement called IWsdlImportExtension which has two methods that you will be interested in. They are:
GenerateContract() and GenerateOperation()
If you implement these methods, you can actually control the way SvcUtil pumps out code by adding or removing CustomAttributes and so on. You need to compile a dll with the interface in it and then point the SvcUtil configuration at the DLL and the interface.
Using this method, you can can for example add Xml documentation to your outputted proxies and so on. There are some interested articles around about this.
I have a simple business workflow with the following conditions
Users need to change the workflow itself using a desinger
The workflow is a long rinning workflow, so it will be serialized
Is there a way to automate the task of versioning different workflow assemblies?
The versioning of different workflow assemblies is not a trivial task and has a lot of complications. Here you can find a series of posts that deal exactly with this.
You can rehost the WF designer in your own application to let the end users change workflows. As you are hosting the designer you pretty much control what they can do. For example you can prevent them from removing or disabling activities and only allow them to add specific new activities in predefined area's of the workflow. The best approach is to save these workflows as XOML files and start them as such. This does mean you cannot add code to the workflow itself but you are free to define your workflow base class derived from SequentialWorkflowActivity (or the state equivalent) and use that as the workflow base class. This allows you to add code and properties. For example you can still add a CodeActivity but you need to link to code in the base class.
Workflow serialization, or dehydration as it is called, is used with running workflows to persist them to disk. This uses standard .NET binary serialization and can be a but tricky due to the long running nature of workflows. But no big deal once you know what to look for. See http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx for the start of a series of blog posts.
Not sure if you need it but there is also the capability to change already executing workflows. This uses the WorkflowChanges object. See here http://wiki.windowsworkflowfoundation.eu/default.aspx/WF/RuntimeModificationOfWorkflows.html for more details.
Here is another article on workflow versioning:
http://www.adefwebserver.com/DotNetNukeHELP/Workflow/VacationRequest3.htm
Basically you can version workflows that use assemblies if:
Any assembly used with workflows
must be strong named.
If a assembly
uses an interface it also must be strong
named and placed in a separate
assembly.
An entry in the web.config
can instruct asp.net where to find
the proper assembly.