File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes What to do, if we have 130 to 150 attributes/fields/parameters for a web service..??? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "What to do, if we have 130 to 150 attributes/fields/parameters for a web service..???" Watch "What to do, if we have 130 to 150 attributes/fields/parameters for a web service..???" New topic
Author

What to do, if we have 130 to 150 attributes/fields/parameters for a web service..???

Nachiket Patel
Ranch Hand

Joined: Sep 16, 2007
Posts: 110
Greetings,
We have to consume one event, from SAP, which has 150 attributes (fields).
And we have about 50 different web service interfaces for consuming/producing.

Now what should be the approach for consuming/producing???

Should we pass array, map,object or method with 150 parameters???
[Please also consider that, we do not want to change interface a lot. ]

Another point,
We were discussing passing parameter as map....and almost everyone was agreed, [because 150 parameters are there, and change frequency will be high)
So one college suggested that then can also combine 50 interfaces and create only one interface with additional parameter describing type of web service.

Please suggest, what should be appropriate solution? or how you are doing it???

Regards,

Regards,


Before software can be reusable, it first has to be usable. - Ralph Johnson
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
I am not sure I have understand your requirements correctly, but here are some suggestions:
You can write a Document/Literal web service that accepts any XML fragment. This enables you to add support for new document types without changing the interface of the web service.
Depending on how you want to process the data in the web service, you can choose between the following options:
1. Use JAXB to automatically bind the XML data to Java objects.
Use SAX or something to find the namespace of the document received and create the appropriate JAXB unmarshaller based on the namespace.
2. Implement your own parsing for each document.
Again, use SAX or something similar to find the namespace of the received document and create the appropriate parser accordingly.

Additionally, if you need to support different kinds of operations on the data, then provide corresponding operations in the web service. Such operations can also take any XML document as parameter.
Best wishes!
Nachiket Patel
Ranch Hand

Joined: Sep 16, 2007
Posts: 110
okay,
Let me simplify it,
1. I want to validate my approach with standard approach.
2. There are 50 web service most of these are having 50 to 150 parameters ( Like array[flat] not object[hierarchy])..

If you have to implement these web-services, what kind of web-services you will make?

Regards,

Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
You said something about frequent changes - are these changes to the parameters of existing services or addition of new services?
Best wishes!
Nachiket Patel
Ranch Hand

Joined: Sep 16, 2007
Posts: 110
parameter of existing services..
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
My best suggestion is still a Document-based service as above. Since you will have frequent changes in the parameters, I would not consider JAXB to be a viable option, but rather implement parsing of the request documents using SAX, StAX or similar. One XML schema per document type, or per request type - not enough details to say which is better. Depending on how strict validation you want of incoming request data, the XML schemas can be written to accept information specified to a low or high level of detail. However, with greater detail follows less flexibility and greater impact of changes.
If you have less stringent requirements considering validation, you may also want to consider passing JSON data. Since you already has spoken about putting parameters in a map, JSON sounds like a good match.
Best wishes!

P.S. Found this article that may be of interest to you:
http://soa.dzone.com/articles/soa-and-xml-factor-designing
 
Don't get me started about those stupid light bulbs.
 
subject: What to do, if we have 130 to 150 attributes/fields/parameters for a web service..???
 
Similar Threads
long post IBM.158
Application hosted on Tomcat has datasource DBCP issues
Interface Queries : Java
Different Message Exchange Pattern interfaces
some java interview Questions