On the project I am working on, we are defining multiple WSDLs in the same target namespace. (That is each WSDL definition has a different name attribute but they share a common namespace).
The SOA guys here are saying they need each WSDL definition in its own namespace. (Looks like some technical constraint in their software or bug; I am not sure).
My understanding is that having multiple WSDL definitions in the same namespace is not illegal. Can anyone confirm or deny this and perhaps point to relevant standards documentation that will support it?
UPDATE:
After reading a little more, it seems (for example from the WSDL 1.1 specification) that while referring to various schemas that are all part of the same target namespace is OK, the examples that I see of WSDL definition target namespaces indicate a unique namespace per WSDL definition, but I wonder if this ends up being a matter of interpretation, as I find no official directive saying you must have each WSDL definition in its own namespace.
What is the general consensus out there? What examples have you seen in the wild? Do you ever create multiple WSDL definitions in the same namespace? I would be interested to hear your input.
Just for reference, I am working with SAP software and they use namespaces to reflect a software component/version or solution, thereby having many WSDL definitions in a common namespace. Guys from SOA.com, on the other hand, seem to be of the opinion that each WSDL definition must have its own namespace.
Related
I'm using the F# Type Provider to consume a web service. All requests work with the exception of one that give me the error below
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Xml.dll
Additional information: The XML element 'ResponseBO' from namespace 'http://com.x.xx/xsd' references a method and a type. Change the method's message name using WebMethodAttribute or change the type's root element using the XmlRootAttribute.
All solutions I've seen so far involve updating the webservice which is not an option for me. What is the way around this?
You have two options:
Rewrite on webservice end
Get all files and what not, rewrite the WSDL-/XSD-files to something valid/acceptable AND something working against live servers again
Since 1. is not an option you are left with 2., and you might as well go all in and possibly drop the F# type provider, since it uses svcutil.exe below the surface, and then do it all by hand/scripting with svcutil.exe:
getting relevant files to some storage
then rewrite WSDL (by hand or otherwise)
and then svcutil.exe to generate code again (or WSDL F# type provider to rewritten files)
The second point (rewrite WSDL) might possibly not be necessary/relevant depending on if you can use any of the svcutil-switches when generating code to make the code right: https://msdn.microsoft.com/en-us/library/aa347733(v=vs.110).aspx
svcutil.exe is in general a quirky piece of shit software, especially if the writers of the service are not taking special good care of following all advice, best practices and what not when delivering services and descriptions.
It might in fact be that the service is not totally conformant, and as such you might check that with f.i. SoapUI and if it is not entirely conformant you might have a stronger case with regards to fix the service. See https://www.soapui.org/soap-and-wsdl/working-with-wsdls.html for more info on this part.
I am still hoping that someone will write a new WSDL type provider for F# not depending on svcutil. But then again, if the writers of svcutil.exe has a hard time to handle every wild WSDL/service description, it wont be easy to write a new type provider either so...
In French, a "donkey bridge" is some apparent difficulty in a subject to be learnt that throws off newcomers - the donkeys. The expression is used with patronizing assurance by educators who know the difficulty is apparent, not real, and the donkeys just have to cross the bridge.
Well I'm the donkey, and I'm having real trouble settling down with the folder structure and "virtual" urls of asp.net mvc projects. Urls are now a blend of pseudo-path information, encoded in routes, and arguments, that resolve to controller classes that, being classes, have no notion of their directory. So, it seems, there is no simple way of using relative paths/urls to reference static resources associated with a dynamic page: script file, stylesheet, razor view, images. .Net helpfully gives me default search locations for views, and default folders for "Content", "Scripts", "Images". I get the feeling they want me to file things by type. But this obliges me to invent file and subfolder names in each of these locations, then to hardcode the resulting paths in the controller and the view. Since a given controller generally has only a handful of tightly coupled views, and 99.9% of views have 1 script file and 1 stylesheet, all this name invention, and categorization by type, introduces needless brittleness and complexity, and masks any expression of what the project actually does.
Is anyone else fighting this? Is their a tried-and-tested strategy for naming in large mvc projects that
Expresses what the project does at the top level of the folder structure (or any level of the folder structure!).
Provides a default location or generated names for .cshtml, .js and .css, such that I don't need to search through code to find the names of associated resources.
Preserves the flexibility and decoupling of naming/indirection where this has proved useful.
I'm aware of areas as a way subdividing an mvc project into functional groupings, but this just seems to recreate the problem inside each area. I've looked at this method for customizing the search location for views, but there's no dynamic element. I've implemented a view engine to have fine-grained run-time control over the view path, which is fine if you're brave but I'm still unsure how best to use it, and I'm put off by the potential caching issues. For all the dissing of opinions, I'm particularly interested in answers addressing what I should do.
Thanks to all the downvoters, intolerant village folk. The donkeys that refused to cross the bridge are right, and they're all hanging out in a green field, munching happily on Nancy and building fabulous Owin pipelines. Feature folders are the future.
I agree with you that trying to arrange elements by type is usually problematic. For example putting C# interfaces for a customer and a product in the same "Interfaces" folder is not something I am keen on personally, I'd rather have a Customers folder and a Products folder, each with an Interfaces folder inside.
However, with MVC, there is a lot of enforced and unenforced convention in place which you will probably have to live with. As an example, if you have a controller called ProductContoller, it will automatically look for views in the Views\Product folder. So your product index.aspx/cshtml view is nicely segmented from your other index views.
For things like scripts and CSS, these are not enforced and technically you could put them anywhere, but it's a convention across many web frameworks to keep them in the same root folder. In some frameworks you would be explicitly allowing public access to certain folders to read files, so you'd want to do this for all scripts or CSS files together.
It's not an answer but I hope it helps.
then to hardcode the resulting paths in the controller and the view
No.
Use UrlHelper (Url property in controllers and views). Extends it with ad-hoc functions for resolving your specific urls, as this blog post do.
For resolving views, stick to MVC conventions as explained in Dorian's answer.
I am a Java Developer making the transition to the C# world. I've gotten a pretty good handle on ASP.NET MVC (and can compare/contrast it to the concepts I learned for Struts).
However, I'm looking for advice on how to structure my project. Currently, I have two solutions in the project: the MVC Web Application and a ClassLibrary section.
The application uses a tiered architecture: Controllers/Services/DAOs. To make things work "right", I have the Controller and Model classes in the MVC solution, and Services, DAO, and Security in the ClassLibrary solution. Unfortunately, this is causing all sorts of minor issues (example: extending the UserAccount object from the Entity Framework on the ClassLibrary side is ambiguous when I try to extend it on the MVC side for form validation).
The only solution I can come up with is to put EVERYTHING into the MVC project, and organizen what is currently in the ClassLibrary under the App_Code folder. It would solve some issues, but just seems "wrong" to me; my Java projects separated code into a src directory and views (jsp's) into ta webapp directory.
What do some of the more experienced .NET developers think?
Generally in .NET solutions, the best bet is to separate code into different projects only if that code may be useful to other applications, or when the code itself represents a complete solution to some problem domain. A class library that is only referenced by one application project is a waste.
Also, keep in mind that .NET does not allow circular references between objects in two different assemblies (which translates one-to-one with projects usually).
In your example I would suggest that you consider one class library for the model, services, and security... depending on what you mean when you say "services" though.
In most cases, data access is somewhat coupled to the concept of the MVC model, so you might consider putting the data access in there too... but if you have a very cleanly separated data access layer it might fit into it's own class library.
The controllers and views generally should go into the web project directly.
In general, my advice is to split stuff into separate projects ONLY when you have an actual "need" to do so. But assemblies and projects are NOT a good way to represent layers or tiers in most applications. Those are logical concepts that don't always map well to a physical project structure.
If you design your actual classes well and avoid tight coupling, you can usually move code into class libraries later if a real compelling need does arise.
What do you mean by making things work "right"? I find that most issues can be fixed by simply including the namespace in the web.config's namespace import section. When you do that, your models from the other assembly are automatically resolved and they show up in the MVC dialogs, and in intellisense when coding views.
I have an architectural question. We have many applications in our company and we are planning to use ASP.NET MVC and Entity Framework in our future projects. The next project that we need to implement is a central authorization/authentication system. There is no option to use an existing one for reasons that doesn't mater right now. This system probably will be structured as a service. What we don't know is: how the other applications will know about "the model" of this authorization/authentication system? I mean, how they will know user, roles, etc. classes? What is the best practice? One of our colleagues suggested to create the entity framework model (.edmx) in a class library. The problem is that in this case we should copy this dll for all projects that will access the authorization/authentication system. Is it a good solution? Does anybody has a better idea?
You can implement your service as a SOAP-based web service, which means your data model and methods will be exposed via SOAP and described using WSDL. The web service can be consumed from any language, without requiring you to distribute any class libraries.
Many languages also have tools which auto-generate client side class wrappers based on WSDL description of your SOAP interface (e.g. wsdl.exe for .NET clients).
Just to add to what DSO already said, the standard way to do this is through the "Add Sevice Reference" dialog box in Visual Studio. It will query your web service, figure out the classes that are needed, and put them in a reference.cs file. You can also use the svcutil.exe (or if you're using Silverlight, SLSvcUtil.exe) to do the same thing. You have to regenerate the reference.cs file every time you change the interface of your web service, but that usually only takes a few seconds.
It's also possible to create a distinct set of Data Transfer Objects that can be shared back-and-forth between the various layers of your application, but unless you have very strong architectural requirements, I've found the auto-generated classes to work reasonably well.
See also this article here about the self-tracking entities available in EF 4.0, if that's an option for you: http://msdn.microsoft.com/en-us/magazine/ee335715.aspx.
I've been looking at Groovy on Grails and noticed a line at the bottom that says:
Grails aims to bring the "coding by convention" paradigm to Groovy.
What exactly is coding by convention?
Convention over Configuration (aka Coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.
The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called sales by default. It is only if one deviates from this convention, such as calling the table "products_sold", that one needs to write code regarding these names.
When the convention implemented by the tool you are using matches your desired behavior, you enjoy the benefits without having to write configuration files. When your desired behavior deviates from the implemented convention, then you configure your desired behavior.
From "Convention over configuration" article on Wikipedia.
In the context of Grails, "coding by convention" means that a lot of (tedious and repetitive) explicit code and/or configuration is replaced by simple naming and directory structure conventions. For example:
Any class whose name ends with Controller in the grails-app/controllers directory is automatically a Spring controller and closures defined in it will be bound to URLs - you don't have to configure this in an XML file as you would have to when using pure Spring.
The same goes for taglibs (grails-app/taglib directory) - no more tedious TLD files!
Domain classes in grails-app/domain probably have the most "convention magic", being automatically mapped to an automatically generated DB schema - with DB table and column names being by convention identical to the domain property names.
Coding by convention vs coding by configuration:
The idea that you have certain placing or naming conventions for stuff so you don't have to explicitly tell the program where stuff is or what it is called.
For example, in ASP.Net MVC there is a convention for where the views are stored and what they are called. This means that when your code instructs the server to return a view, the runtime will look for a view with a certain naming structure in certain folders. See page 20 in this pdf for more clarity.
Another example would be naming conventions for methods. For example, in an event-driven language you could have a choice to explicitly declare which method handles which events or you can rely on a naming convention - like ..._OnOpen or ...OnClick and then rely on the runtime to figure out the correct method to call for a given event.
Lots of conventions here:
How to name HTML elements so they're easily accessible as parameters from the HTTP request;
How to relate object attributes to table and column names in the database;
How to arrange a project into directories/packages;
It's what you do when you find yourself solving a common problem in a particular style. You notice similarities and codify them into some automation scheme.
See Convention over Configuration. It's the concept of designing a tool or framework to have the most common configuration options as the defaults, so for the vast majority of users no configuration is required.
It means if you stick to certain coding conventions as defined by whatever convention-based framework you are using, you get a lot of functionality for free. In other words, if you structure your application in accordance to what the framework expects, a lot of work can be saved.
It would be a good idea to look up the advantages and disadvantages of coding by convention.