Sir/Madam,
I want to know where WSDL exists. Do user need to do interact with it for any kind of scenario during programing?
WSDL (Web Services Description Language) is an XML-based language for describing Web services and how to access them.
Web Services Description Language
With respect, this is a bad question. You're in effect asking us to do your research for you. When I say "bad" what I mean here is that you're in danger of harming yourself by asking questions like this. If instead you do some preliminary research, for example by googling WSDL, and find resources such as this then you expose yourself to the "Encyclopedia Effect", you encounter other related (or indeed unrelated information) and you learn more. When you research and come across something you don't understand then you can ask specific questions in places like this, and you have a context to understand the answers. I truly believe that researching in the way I describe will be most helpful to you in the long term.
To give one answer to your questions: you will find examples of useful WSDLs here.
As a programmer you can develop service clients from those WSDLs, or more usually use code generators to write the "boilerplate" code for you.
If you want to provide your own services then you may write WSDLs your self.
WSDL stands for Web Service Description Language, it uses XML to define functions that a web service exposes and the types that these functions receive as arguments and return.
http://en.wikipedia.org/wiki/WSDL
You can usually access the WSDL for a web service using a query string (in .NET web services at least). A developer usually won't look at the WSDL as it will be generated by a tool like Visual Studio or soapsuds and code will be generated to represent the types based on the definition in the WSDL that the developer will make use of instead. Changes to the WSDL will result in regeneration of this code.
Related
I found PACT in some videos from youtube and looks great and quite interested to start POC for my team.
I've read previous questions and try to follow the examples in Pact-JS, but still had some confusion on very basic stuff, so excuse my noob questions.
1. Which repo do I need to refer as official repo?
I assumed ones under Pact-foundation organization are official, but some links in document usually go to different ones.
2. What do I need and from which repo for all the parts of PACT working?
Consumer/provider.
For the start, I think I need PACT_JS.
github.com/pact-foundation/pact-js
Mock service.
Do I need either pact-node or pact-mock-service-npm, or both as well for mock service?
github.com/pact-foundation/pact-node
github.com/pact-foundation/pact-mock-service-npm
Broker
If I want to use broker, then this will need.
github.com/pact-foundation/pact_broker
I think those 3 are the parts I need to use. Is it correct?
3. If there are multiple teams involved, does 1 shared mock server need/help or not really matter? I'm not clear the benefit of stand alone mock server.
https://github.com/pact-foundation/pact-js is the official top-level JS repo.
a) That's correct:
b) You won't need to explicitly include it soon (I'm in the process of an API uplift which should simplify usage), but currently you will need to pull in pact-node to do provider verification
c) If you want to share via a broker, head to https://github.com/bethesque/pact_broker for details (this is not strictly necessary, but recommended)
You won't need the standalone mock service if you use Pact JS. It is designed to be used in cases where there is no language support for Pact (in this case, JS wraps this under the hood for you)
I would check out the end-to-end example which contains all that you'll probably need, including integration to a Broker.
I'd like to access some web api's using .net code, but am not sure if there's a way to generate a client side wrapper of some kind for these? Perhaps a code generator that can look at the web api documentation or through sample calls and generated .net classes and methods to encapsulate the api?
There isn't. REST-based APIs do not have a WSDL or service contract that could be used to generate a client stub.
That said, consider the following alternatives:
REST Coder: this is interesting research but no definitive tools yet.
Google for .NET WCF REST client: it turns up a lot of interesting results.
As far as I know, there isn't.
However, you can try one of the many wrappers available, that makes your life easier once you have to write less code.
Check this one out I've written a few months ago:
http://webapiclient.azurewebsites.net
I work in a software company that delivers a software product. Many times we must integrate with other applications. 70% of the time we integrate with a single application. Currently we do not use middleware (MuleESB, Biztalk, ...) in these situations: the data conversion, transport conversion, etc is handled inside the applications.
Wouldn't it be better to ALWAYS use a middleware solution? (no matter if your integrating with 1 or more systems) This way, all the customizations (data formatting, restructuring, transport conversions) of both parties, can be handled by the middleware, instead of by the applications.
Logically this seems to me the right approach. But I ask myself: Is middleware in the case of two applications justifiable?
In practical terms, you will always be using a "Middleware" solution, either custom or packaged.
I'd look at it this way, rather than requireing a "middleware" package, I'd focus on making the app itself integration friendly by using a consistent and as-standard-as-practical API for exchanging data.
Then the decision on what "middleware" to use is more driven by the circumstance on site. If the customer has only one app to integrate, then a simple custom solution might be perfectly serviceable. If they have 5 apps and defined processes for each, then a package makes more sense.
I don't always use middleware, but when I do, I use BizTalk. ;)
I found this to be a useful read when considering appropriate architecture. If you get a chance to see Richard Seroter's "Decision Framework" presentation, you should.
Wiki site on Publish subscribe pattern http://en.wikipedia.org/wiki/Publish/subscribe shows an interesting comparison between how publish subscribe relates to client server.
I am creating basic .NET webpages as a UI, to invoke WCF service and display the result. I feel many web developers must have come across this situation, earlier.
Is there any existing tool out there, which could take WSDL as input and generate input fields either in HTML or .NET webpages.
There is also a tool named storm that I read about but I don't have direct experience with.
http://storm.codeplex.com/
Testing a service from a web page is definetely a bad practice.
Depending of your service, there are many tools available like WcfTestClient, soapUI, WCFStorm, ... but is also a bad usage.
From my point of view, you will never find any better tool than your favorite unit test framework. The test client, nor soapUI will create a test that can run in a Continuous Integration scenario.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.