I just read a book about web servieces at it says there is "RPC style web service" and "Document style web service". the second is using in WSDL sequence and complexType. When should I use this style?
You should use Complex Data Type when you want to transfer data-objects like Contacts, Messages or certain programming objects as it is to client apps in respective technology.
For example if you're using Complex Type webservice built in .NET or Java and you're calling that webservice from PHP or Ruby you will get object from .NET or Java exported as it is (in 98% cases with very minor language specific attributes changed) in PHP or Ruby.
So if you're one of those who don't like simple string, int, bool or array data type you can use Complex Type in your WSDL. It's not very easy to begin with but once you get it started it's fun.
Zend Framework auto-discovery of WSDL can let you generate WSDL automatically from PHP if you're using PHP for developing web services, but if your complexity grows nothing like hand-coding WSDL yourself.
Basically, just about everybody who's still using SOAP web services (i.e. hasn't migrated over to REST) is using "document style".
The distinction is pretty much meaningless unless you're hand-coding the WSDL. And who does that ;)?
If you're using tools like Visual Studio or Axis to generate your WSDL, and tools to generate your stubs, then the only thing that really matters is if the code generated by one tool understands the code generated by the other. Which leads back to "as far as SOAP is concerned, it's pretty much a doc style world". Or, more specifically, a "document style/literal wrapped" world.
Here are a couple of good links:
http://mangstacular.blogspot.com/2011/05/wsdl-soap-bindings-confusion-rpc-vs.html
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Document or RPC based web services
complexType in webservice will be used to represent user defined data types like Objects you want to transfer (not java default types), for example if you have UserVO which contains name, address, phone etc.,, you need to define this as ComplexType in WSDL to send. Java collections/array also treated as complex types. Here is good tutorial on Types of Webserices and example complex type.
Related
It's not a very concrete question. I created a simple project with a help of this tutorial, it's really fine. All the GWT code samples related to JSON I saw so far seem to work with a JSON (or immitate this work with some mock-up JSON), that is retrieved and processed in GWT. I'm a newbie in GWT, and I wonder, what are the cases of interacting with services that return JSON (services are mentioned in the same tutorial) and what are the pros and cons of such interaction.
I thought about two options (well, service is an overloaded term):
everything that is mentioned in these JSON GWT tutorials is about the third-party services, like GData and Yahoo! Web Services mentioned here, which would make sense, cause it's about retrieving some data and processing in the app,
and the second option is about services, that are created within the confines of a project (and, if there are some cases, and definitely there are some, my question is about them).
It's probably can't be fully explained in the answer, so a link (or a few) would be appreciated. Thanks in advance.
Your question is really quite generic. But here are some pointers:
JSON is just a data interchange format similar to XML or Protocol Buffers or some other proprietary format.
They are necessary in modern web applications because the UI is entirely controlled by the javascript code running in the browser.
However the data that a web application presents to the user usually resides on the backend. In order to get the data from the backend to the frontend you have to use some data interchange format like JSON or XML.
The advantage of JSON is, that is fairly efficient compared to XML and well accepted.
As you mentioned there are third party services that rely on JSON. These are very useful when you want to include the services in your applications.
The biggest advantage of applying this service oriented approach to your own project is that you decouple your components (frontend and backend). By doing this you achieve following things:
Make your services available to other (web-)applications and users because your service exposes a specific API/data exchange format that they can use.
Easily replace or add another frontend (for example create a desktop application in addition to your GWT application) that can work with your data (display or modify).
I know that there are two ways of creating web services:
Write wsdl first and generate java interface using web services tools like wsdl2java
Write java code first and then use tool to generate wsdl.
For me, the first method looks complex and second looks quite easy relatively. If so, I want to know
When is the first method used? Give me scenario where the first method is preferred over second.
What is the advantage of first method over second?
Which is the method which is widely used in industry for application programming?
If I am looking for a job in web services development, is it necessary for me to know how to write wsdl file for given requirements.
Sometimes you need to declare the interface upfront before you have any implementation - for example you might have to negotiate it with the customer so that he can start coding against it ASAP. Then you start with WSDL.
If you don't need to have a WSDL representation as early as possible you can follow whatever procedure is convenient for you. For example, if you develop an ASP.NET web service it's quite convenient to just write C# code and have the runtime to generate the WSDL on consumer request.
Can anybody help me with the code for generaing a Form dynamciall whenever a WSDL url is specified..
interesting idea. You want to create an application where the user can load a WSDL and the application pops up a screen that allows the user to access the underlying webservice?
You do realise that a single WSDL can contain many calls?
It can certainly be done, but it's far from trivial and certainly not something someone's just going to give you "the code" for.
you could try these links
form.io
A Form and Data Management Platform for
Serverless Form-based Applications
Simplify the connections between your forms and APIs.
Integrate with 3rd party providers and legacy systems.
All while maintaining control of your data.
jotform.com
Easy-to-use online form builder for everyone.
reinra/dynaform
A dynamic schema-based web form generator in Java
I am creating a WCF Service that will be consumed by both .NET and Java client applications.
We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.
Are our worries well-founded? If so, what should we be wary of?
Edit
One example of a concern is whether a .NET DateTime value is represented in the service interface in a manner that can be correctly understood by a Java client.
Edit2
A second example of a concern is the use of any nullable value types (bool?, int? etc).
Edit3
At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.
The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.
The downside is that this adds a development burden and also precludes us from documenting these classes using <summary> tags (.NET equivalent of javadoc comments).
The recommendation to start with XSD is a good one. That will not guarantee compatibility on each side, as XML Schema is really big and no web services stack supports all of it. (Example: lists).
So, start with XSD, but confine yourself to mainstream types. Primitives, complextypes composed of primitives, arrays of same. You can safely nest complextypes and arrays. (arrays of complextypes, complextypes that contain arrays or complextypes, etc).
Stay away from restrictions, substitution groups, lists, derivations, and any other XSD esoterica. Even XSD enumerations should be avoided.
About dateTime:
It's not enough to use a nullable datetime. There are formatting concerns as well. The .NET DateTime is a higher resolution quantity than a Java Calendar and as a result, shipping a .NET time to Java can result in de-serialization exceptions on the Java side. (EDIT: using the DataType="dateTime" decorator in the XmlElement attribute on the .NET side can make sure you serialize properly)
Some old advice on that.
Finally, it is not true that you cannot use in-code XML doc on the classes that get generated. With C#'s partial classes, you can write separate code from the generated classes with the in-code doc you want. Even if you re-gen the code, your partial class code will remain unchanged. EDIT: When you compile, the doc will appear on the classes.
EDIT: Someone asked, if using XSD-first is not enough to guarantee interop, why use it? My answer: it is not a guarantee but it is a good step, it helps. It keeps you away from designing interfaces in code (either Java or C# or VB, etc) that expose platform-specific things like .NET DataSets, generic Dictionaries, Java ResultSets, etc, all of which present interop problems. There are still pitfalls in the more marginal parts of XSD, but you can usually avoid those with thoughtful design.
I should have mentioned in my original answer that you can apply an iterative process to the development of the interface. Design in XSD, then generate (client) stub and (server) skeleton code from the XSD+WSDL, then adjust and do it again.
Using basicHttpBinding endpoint will guarantee that any SOAP 1.1 compatible client will be able to consume your service.
Use DateTime?, i.e. a nullable struct. Java does not have the notional of complex value types (i.e. structs). I believe there are ways to specify in the WSDL not to allow nulls, but I think WCF doesn't do it out of the box.
Use arrays instead of collections. If I recall correctly, the collection types do not translate very well over SOAP, but array types do quite well.
You should get a copy of Eclispe or Netbeans. After you create a prototype WCF service, run the web service wizard to create your proxies. Examine the object model for any major defects with particular emphasis on complex objects or non-primitive types (treat string as a primitive).
The learning curve to do that with Netbeans or Eclipse is pretty flat, so it's not a huge burden.
Edit: The other potential problems are with the bindings. If you stick with HTTP(S), you should be good... start going to the alternatives like TCP or MSMQ, you'll have to do a lot of work in Java. Also, some of the security features don't interop in all cases, such as using NTLM tokens... Take an iterative approach. Start with a simple HTTP w/SOAP binding with no security and go from there.
Does WCF provide standard SOAP interfaces? If it does, getting Java to talk to it should be a doddle.
Re: Edit1: The WSDL / XSD will use a standard date time format (Calendar at the Java end, a formatted datetime string in the SOAP, DateTime in .NET), or you could force it into a string format of your own choosing.
Read up on the Apache Axis (1.4 and 2.0) documentation for Java web services. It's very easy to use to get a Java web service client set up from the wsdl/xsd that your web service will provide.
Edit3: In Java you would define a Java model (with all your favoured documentation), then run Java2WSDL (preferably as an ANT/Maven task) to create your WSDL (however I have found you need to hand-reorder the fields in it). Axis 2 supports Collections and Enums just fine, Axis 1.4 likes Arrays and hand-rolled Java 1.4 style enumerations. From this WSDL you would create a server-side skeleton using WSDL2Java in which the only thing you need to do is implement your business logic.
In a Flex / Java app stack using remoting (via BlazeDS), classes to hold data passed back and forth between client and server need to be maintained in both the client (in ActionScript) and server (in Java).
I want a way to maintain theses classes in Java only, and have the corresponding ActionScript value object classes generated by the build process.
Check out the AS3 generator from the Granite Data Services project:
http://www.graniteds.org
If I recall correctly it's an Eclipse plugin which should be quite easy to use. Just remember that if you exclude a property from the ActionScript class that it will still be serialized by Blaze when it's sent back to the Flex client.
XDoclet2 includes an ActionScript plugin that can generate ActionScript classes from Javadoc comments in Java code.
The downside is that it's based on Javadoc rather than Java annotations, and does not appear to be well-documented or very widely used.
There are a couple of free Java to AS3 converters out there of varying quality:
http://osflash.org/projects/j2as3
http://osflash.org/j2as (this one is AS2, but may be OK for your purposes)
I cannot vouch for their quality but they claim to do what you are looking for.
Personally I take the overhead of maintaining the two code bases manually because once the objects settle there is not much to do and it means I don't have complex rules around the rest of the code which is in the objects.
Plus my Java objects all have getters and setters whereas the AS3 equivalents do not, which means the public/private accessors are different in any case.
HTH
If you're going to be doing a Flex RIA app of any degree of sophistication, then you'll probably be implementing the MVC pattern - ala Cairngorm, Mate, or PureMVC.
Take a look at this Flex code generator as it anticipates your use of MVC in the Flex client and generates code suitably to deliver an even higher degree of leverage:
FCG : a Flex Code Generator