I want to upload a large file maybe 500MB. on CMIS based servers. Alfresco, Documentum and Microsoft SharePoint
Would I face problems ?, if yes, are there suggestion to handle that ?
edit
I am still searching to build a java client using opencmis. I think I will face such problem and I want to know is there a possible handling using this lib
Use OpenCMIS to upload your content it is the most advanced CMIS client implementation.
As stated by Florian Müller (Apache Chemistry Chair, CMIS Committee
Member) OpenCMIS is tested to handle 2GB, so your 500MB documents are
supported without problems.
There are two bindings for CMIS which are REST/ATOM and SOAP
Webservices. There might be differences in performance between the
two, with SOAP most likely being slower. This is something you should
test if performance is an issue.
Use the OpenCMIS Workbench Desktop Client to easily try out the
transfer to your target repositories. This is the best way the see
how your content repositories work together with OpenCMIS.
Related
I want to upload a folder that contains many subfolders, those subfolders contains also many documents, into alfresco repository. I did this with Bulk Import Tool using for each folder/document an xml metadata file for importing also their properties. But to do this I must generate for each an xml file containing the metadata. So I search for an alternative solution and I found that I can do this with Alfresco Rest API calls without that xml metadata file. But I really don't know how to use it for upload.
Please if someone can help me with that. Thanks a lot.
If you can get your files moved to the same server where Alfresco is running, using the Bulk File System Import Tool (BFSIT) is likely going to be the best import approach in terms of performance, even if you have to create the XML manifest files that describe the metadata that accompanies each file you are importing.
If that approach does not meet your needs you can use a variety of alternatives to do the import. That includes:
Writing a client that leverages CMIS using Java, Python, .NET, or any other languages for which you can find a CMIS client library. Apache Chemistry has several, but there are others out there.
Using the client-side JavaScript API that is shipped as part of ADF.
Using the Alfresco public REST API. Prior to Alfresco 5.2, the "Alfresco API" was a mix of CMIS and Alfresco-specific REST calls that handled things the CMIS API did not cover. With 5.2 there is a new set of RESTful endpoints that can be used for all sorts of things, including creating nodes.
Defintely recommend taking a look at the API Explorer to see the Swagger doc on the API.
I am in the process of creating and negotiating a specification for some new functionality on a web app. The new functionality includes enabling users to send PDF files along with some other data (a name, a creation date, a city, etc.) to a server on a different domain. So it is really multipart data, binary and plain text mixed together.
What would be your preferred way of doing this, knowing that
the PDF files will not exceed 5 MB and the plain text data fields are very small
our development time is limited to about 10 days
The developer of the receiving application is in favour of SOAP (not sure if he wants to encode the file or send it as an attachment), because it is tried and tested in their application. I think I am in favour of using just plain POST, because it's simple and doesn't require additional protocols. My argument against SOAP would be that our app is written in Java and theirs in .NET and I don't want to run into compatibility issues with SOAP.
I have little experience with web services, so any arguments against or in favour of these technologies will be appreciated.
The reason you are being downvoted is that you have shown little to no effort.
There are no compatibility issues with java to .NET for the most part. Additionally if your vendor(developer) has proven success with a method then why are you going to spend money developing an entirely separate solution which will have to be maintained specifically for you.
It sounds like you are just spewing rhetoric because you wish to win an argument rather than be correct.
Is Google Web Toolkit is fine to develop database based web application or do you have any other suggestion?
Thanks to answerers!
For a heavy Database based web application, nothing beats Grails. Check out this tutorial by IBM. It will show you the power of Grails and how easy it is to develop database based web applications in minutes. I love GWT and smartGwt, but will go for them over pure grails only if there is a lot of non-database based front end (client side) logic.
If you do not have a programming language of choice (Grails is groovy based, which is based on Java), you could even look at Ruby on Rails which was the inspiration for Grails itself.
Alternately, you can add both grails and gwt in the mix by using this gwt grails plugin so that you have a powerful database integration, as well as a powerful front end developer. (I haven't used this though)
Sure, but you will need to create your own RPC service to get records from server to client and to deliver modified records back the server. But it isn't difficult at all.
Alternatively you could also use SmartGWT, which is an extension for GWT with more widgets, etc. They have data bound objects but in free version would would need to create your own data sources. If you decide to buy a license they seem to have database integration out of the box.
And additional note to consider with SmartGWT is that it has relatively big download size - about 3MB uncompressed and almost 1MB compressed (HTTP server should compresse it; it is in HTTP standard and it is transparent). So if it is going to be a service in public internet it might get quite long to load (often exceeding magic 8 seconds).
I had been working on GWT (Google Web Toolkit) for 1.5 years and learned that its a perfect platform for developing web application which uses backend database for its operation unless you have the right skill sets working on your project and a basic design which is developed according to the requirement of your project.
I am in the process of scoping the development of an iPhone app for a client. Among other things, the app will allow users to browse through and place orders on specific (tangible) products.
The client has a website that currently does a similar thing and due to their limited budget and the fact that the website runs on a third-party proprietary platform which they have no control over, we are investigating possible alternatives to building a web service.
On the website, user registration and authentication, as well as order placing is done through POST requests via secure HTTP. The response is always a formatted HTML page which will contain strings indicating whether the request was successful or not, and if there was an error, what the error is etc.
So provided I can replicate the POST requests on the phone, and parse the HTML responses to read the results of each request, do you think this is an acceptable alternative to building a web service to handle this?
Apart from the possibility of pages changing (which we can manage) and the fact that I will probably have to download and parse a relatively large HTML response, are there any other drawbacks to this solution and is there anything else that I might be missing?
Many thanks in advance for your thoughts.
Cheers,
Rog
You could create an intermediary server that will communicate with the client server, and on it expose some REST web services with json (small overhead and easy to handle) responses that will be consumed by the iPhone app.
So, you're going to parse HTML and formulate POSTs off a third-party server, and pray that they don't even so much as rename a form field.
Your question is in two parts:
Do I think that a miracle is an acceptable solution? I don't.
Do I think that aside from the fact a miracle is required, are there any other drawbacks? None that I can think of.
You didn't ask, but this is a terrible course of action. Two suggestions.
I spy an assumption that the providers of the third-party platform aren't interested in enabling third-party applications by providing an API. They have a very good business reason for this, which is that it promotes platform lock-in. Reach out to their support department and have a talk with them.
You have to sell the client on building an intermediary web service. To at least try to mitigate the damage that changes on this third-party platform can do to your app, I recommend that you build and operate a proxy that receives requests from your applications, and proxies them over to the third-party platform. You should build into this client-server protocol a means for returning "we are in maintenance mode, go away" messages to apps, for that inevitable day when the third-party server changes something that breaks your app (they swapped the billing and shipping address pages, for instance) and you have to rush through an update through Apple to deal with it.
The proxy could be written in something more flexible and easy to bash stuff out in, such as PHP, Python, Perl, or Ruby. It could be hosted at Amazon in a micro instance.
p.s. This question is inappropriately tagged objective C.
HTML is the worst because of parsing (1-2secs per page), memory, and changes, but you already know that. Check in advance that ALL the data you need is exposed on the HTML.
If you use an intermediary server you are moving work elsewhere and you have another server to maintain. I would only do that if memory is an issue. Check How To Choose The Best XML Parser for Your iPhone Project for memory/performance/xpath support. libxml2 is a good option, but it depends on your needs. And maybe you'll want to check ASIHTTPRequest features before using the SDK.
I think utilising the web language of JSON would contribute to the diminishing of the parsing time. By building a REST service that, when sent a GET request, returns the correct information for easy sorting, you could then display the output a lot faster than that of parsing straight HTML.
I prefer JSON over XML, but everyone has their personal preference. You should look at a few very good libraries that are built specifically for parsing purposes of both XML and JSON.
For XML I recommend using the inbuilt libxml parser. Albeit, this can sometimes deem very difficult to use. A simple Google search will bring up a heap of results that relate specifically to what parser should be used depending on what task is to be completed.
As for a JSON parser, I recommend SBJSON. I am currently using it one of the biggest projects I have undertaken and it is definitely working perfectly for my use.
If you need a good way to connect to a RESTful web service, you should try LRResty.
Don't go for a parsing solution on the iPhone for 4 reasons:
Server can change their design and break your application (AppStore submition is long) + They can also detect that the request are sent from an application based on user agent which you have to update the application to change it.
Some of the requests might be made thru Javascript so you not only have to parse (X)HTML but also Javascript request (which can be in the form of XMLHttpRequest, but don't have to)
Long term evolution of the mobile market : maybe your client want (or will want) an application for android, Blackberry, Bada OS (Samsung), Symbian (Nokia/ OVIStore), Java Mobile or Windows Phone 7?
Of course network traffic, Memory and CPU needed to parse HTML (look the time it takes to the browser to do it?)
Regarding the traffic, if the application will not have a huge traffic you can home-host your proxy. Or you can find some provider to host it for you. I guess you won't need more than a couple of Megabytes of storage but maybe traffic. For less than 100€/year you can find some with unlimited traffic (like OVH Pro plan or Infomaniak). But if you want to go Java have a look at Google App Engine : you pay only if your traffic is important and if your application generate many CPU Cycles. If not : you don't have to pay. And it's hosted on Google server : reliable.
If the client is open, you could consider the paypal API.
I've started my degree project, a mobile application suitable for iPhone, Android and (in the near future) Symbian. The server architecture is the following:
web site (for "standard" users);
web service (for mobile connections), based on TomCat and Axis2;
mySQL DB to storage users data.
Surfing across the web, I've read a lot of discussion about the interaction between the iPhone and Web Services, and I've to say that I've not a clear idea of what I can do and what not.
Let's start from the protocol used to retrieve data from the DB: the Android-side application uses SOAP protocol, can I do the same with iPhone? Are there some limitations or problems?
I have also read about the using of REST instead of SOAP, could it be possible with the server architecture described above? Which are the main advantages/disadvantages?
Sorry if these questions sound "n00b", but it's my first real experience with iPhone and the lot of informations found on the web messed up my mind and I'm scared to be confused. Forgive me for any error.
SOAP is simply too heavy for mobile communications. Why do all the work to wrap requests in an additional XML layer you'll have to parse? You send more data than you need to, and impose greater CPU burden on client and server.
Use REST. If you are doing a cross-platform project JSON makes a great payload container, otherwise plists work well for sending data from the server.
You can definitely do SOAP on the iPhone. Here is a nice tutorial on the subject. After all, SOAP is a HTTP based protocol and you have all the libraries you need to do HTTP on the iPhone.
Having said that, RESTful APIs are simpler than SOAP, so you might want to consider them. They're also HTTP based so you won't have any problems on doing that on iPhone. On the server side, if you use Java, you will have to use JAX-RS to implement that part.
Hope it helps.
Google Buffers
If your looking for a language and platform agnostic solution have a look at Google Buffers. You can easily serialise objects for transmission over the wire.
This question should get you started in Objective-C.
JSON
I have also used JSON within iPhone Apps with great success. Again, relatively language and platform agnostic but much simpler than Google Buffers.
SOAP with Fast Infoset is suited for small devices:
JAX-WS 2.0 and its reference implementation support both Fast Infoset and MTOM/XOP. This article includes information about Web Service Performance for Fast Infoset vs. MTOM/XOP:
http://www.devx.com/xml/Article/35385/1954
Fast Infoset is optimized for small
devices that have bandwidth
constraints, and is supported by many
vendors such as Microsoft .NET and
.NET CF, Sun GlassFish, BEA WebLogic,
IBM SDK for Java 6.0 and others.
http://en.wikipedia.org/wiki/Fast_Infoset