I am still new in CMIS subject , and I am still searching learn about that, What I want to do is to create a Java client that upload report to any content management that support "The CMIS v1.0 OASIS Standard Specification". such as Alfresco , Documentum or Microsoft SharePoint Server I found that opencMIS for Java is a good choice ..
But I am still a bit confused about what is required to write such application the communicate with these CMSs ans repositories .
Do I need to handle each one alone , or to create it once and it
will deal with any CMSs that support this standards ?
How the CMIS client will connect to the CMIS-based server. Do we will have authentication data and a communcation endpoint(URL)?
Please if possible-briefly- what are the steps required to do to make a CMIS client using OpenCMIS, does it a hard work for who don't have any previous experience in this topic on has a knowledge about xml, http ..etc?
Thanks in advance
OpenCMIS is really there to let you abstract from the low level protocol details such as XML payloads and the like. On the other hand, it's highly advisable to get a grasp of the protocol itself, just to know what's possible and what not, when designing your application.
Also, the idea behind CMIS is that the same library can access all the compliant CMSs without any code change. What happens in reality is that vendors might have specific extensions that might not be fully portable, and your application might need reworking to support a new CMS (Alfresco aspects are a good example).
The page linked by #Romain Hippeau is providing a number of examples of the OpenCMIS client API usage.
Related
I've been asked to look into adding an LDAP interface to an existing Java web application - that is, to make it possible for LDAP clients to connect to the application as if it's an LDAP server. I could write code to listen on a dedicated port and implement the LDAP protocol, and hook that into the existing database... but I'd have to understand the protocol first and then there are potential security issues if I write that from the ground up (not to mention the time it could take).
What I'm looking for is a library of existing code - something that handles the ports and protocols, and lets me focus on writing just the back end. There are plenty of client-side libraries out there, as you'd expect, but I've had no luck in finding something to help with server-side development. So the question is, does anyone here know of such a library that would help with this?
Yes you will most probably find many more client implementations than server, however LDAP is a request response protocol, so with a bit of playing around you should be able to use the same classes and their serialization capabilities. Instead of sending the request you would be receiving it, and responding with the response you would otherwise expect from the client.
You could look at the Apache Directory. https://directory.apache.org/api/
It has an embedded directory server project as part of it, which claims to be extensible and embeddable in your application. https://directory.apache.org/apacheds/
So maybe that could be the answer to your needs.
I'm working with a client that's on a currently purely-MRI Ruby/Rails stack, but we have a 3'rd party service we need to start interfacing with that is built on .Net with WCF and the only way to access it is SOAP. They are using MS-LWSSP (MS documentation) as a security protocol and none of the Ruby SOAP libraries seem to understand how to connect to it.
We are considering adding JRuby to the tech stack (as a separate small application) to connect to this service, as Java has offers more choices for dealing with SOAP. However, I'm not familiar with any of the Java SOAP libraries.
I have seen some other posts about using a Java client to connect to a .Net SOAP service, but I have not seen any specifically addressing using this security protocol. Their SOAP service is SOAP version 1.2 and it does have a WSDL we can access.
Has anyone done this? Could you please provide me with information about what libraries would be helpful in doing so?
Thank you very much for any suggestions or information.
This is an old question now, but I'll respond with what worked for us. Or more correctly, what never worked for us.
None of the Ruby SOAP libraries were compatible with the protocol we had to use. We spent quite a bit of time on trying them out but they simply didn't work with the client. We considered look into implementing the protocol ourselves, but that was far more effort than we wanted to spend on this.
In the end, we requested the client to give us access via a non-SOAP route and that worked out much better.
The moral of the story: try asking if you can have non-SOAP access. It'll save you a lot of effort and headaches.
I have an application in C++, but it'll need to 'talk' to Java based message-service. In the past we used WebSphere MQ and used their C++ libraries to do the 'talking'.
So I am in search of (ideally) free C++ to Java solution which doesn't hold the whole JVM in memory.
The other option I've looked into is SOAP.
I've looked into Axis2-C but it gives me the whole server implementation, which I don't need.
I've seen talk about gSOAP but saw mixed comments here. And again it seems to be providing me with a whole server.
I could write the code myself - but it goes against my (Java based) belief that excellent free code exists out there.
Thanks!
A'z
There are a couple of points here which don't make sense to me, JMS is a java specific abstraction over a generic messaging API, much the same way that JDBC is a java specific abstraction over a generic database API.
I can't imagine anyone wanting a JDBC driver for a C++ application, they would rather use an ODBC driver.
So if I assume that your objective is to send messages without using Websphere MQ from a C++ application, then I can recommend that you consider the following:
Do you need asynchronous messaging? i.e. store message on queue until message is consumed?
If yes, then web-services will not work for your application, unless you are prepared to host a web-server to receive the responses, and call back to your application.
You haven't mentioned whether the underlying java based message service is going to be JMS or WebServices.
You could consider using ActiveMQ as a messaging provider, it provides an implementation of the JMS API and also implements the STOMP protocol, which has client libraries for a number of languages including C++.
You could leave open your decision for end-point protocols while you try out various options, by implementing an integration layer using something like Mule.
You can quickly develop small integrations on Mule e.g. to accept a Message on ActiveMQ, and post it to a WebService and put the WebService response on a different ActiveMQ response queue. Or vice-versa, accept web-service call and post SOAP onto JMS queue, wait for JMS response and build SOAP response.
There are many ESB-like frameworks which can facilitate these sort of integrations to various degrees :
Mule
ServiceMix
Fuse
Apache Camel
Spring Integration
JBoss ESB
EDIT:
Given the clarification I will refine my answer:
You need a common message broker that is accessible to C++ and Java such as ActiveMQ.
You need a small / lightweight integration layer such as some of those above to accept from ActiveMQ and forward to SonicMQ, and vice-versa.
2.1 From what I know of Sonic, they have an ESB stack that should be able to do this instead of using one of the containers/frameworks mentioned above, but that will open up issues of integration ownership between you and the client.
I found 3 links showing Sonic support for C and C++ :
- http://www.sonicsoftware.com/products/docs/sonicmq_app_server_ds.pdf
- http://www.sonicsoftware.com/developer/documentation/docs/sonicmq_c_v60.pdf
- http://communities.progress.com/pcom/servlet/JiveServlet/download/10809-3-10161/cclients_readme_76.htm (dodgy mime type on this link)
The SonicMQ site seems to indicate that they support C++.
It would appear that this is suitable.
There are C++ libraries for SonicMQ. The main constraint is that you have to be using the same build (ie. STL libraries, etc) that Sonic used to compile the libraries.
http://web.progress.com/en/sonic/sonicmq-clients.html
Of course you asked this question over half a year ago, so this information is probably a bit late. :-)
At my current job we are using a product called JINTEGRA that lets us get access to users outlook folders (Contacts, email, calendar etc.) and make updates through a separate CDO/MAPI server.
I was wondering if anyone could recommend any alternatives to this ? We had initially tried WEBDAV which was good for reading information, but not writing.
JINTEGRA has an annoying licensing model that is constantly firing off license violations and requires us to manage separate licensed jars for every server and developer so we are looking to get away from them.
Thanks !
Some options:
you can consume Exchange Web Services (starting with Exchange 2007 I think) with jax-ws for example or any other webservice tool. We do this but we consume them from .net too
you can use javamail and access exchange via IMAP, but you don't have access to all items (Contacts etc), if you just need mails this is fine though (we do this too)
there are some opensource projects but never used them so cannot vouch for them, one is http://sourceforge.net/projects/j-xchange/
Has anyone successfully implemented a Java based solution that uses Microsoft SQL Server 2005 Reporting Services? Reporting Services comes with a set of Web Services that allow you to control the creation of a report, execution of a report, etc and I am just starting development on a POC of this integration. A couple of choices I have yet to make is whether I want to use Axis2 for the wsdl-to-java functionality or use WebLogic's clientgen (wsdl 2 java) solution. I guess I can also use JAX-WS and wsimport. Before I dive into this, I wanted to see if anyone was doing this successfully with one of the many options available.
In the past, I've had a few issues on how null/blank/empty's are handled between .NET and Java web-services and I just wanted to see if this had come up as an issue with SSRS and Java integration. Thanks
My experience with RS would lead me to suggest you go with just about anything else. I think the web services portion would work fine but I'd be concerned about how RS manages memory and how many reports you need to be running at once before making any decisions. I'm fighting with memory management problems today with RS and even on top of the line hardware it's hard to run large reports (large number of rows returned and a wide result set).
That being said if you think RS can handle your usage then it might be good. The development environment is sort of nice and it's easy to understand and lay out reports. The table layout paradigm it has is pretty good.
I just wanted to come back and answer my own question. I started with Axis2, Apache's implementation of SOAP. After generating the client using WSDL2Java, I was able to successfully invoke Microsoft Reporting Services WebService and generate reports, output in Excel, PDF, CSV and other formats. In my case, I also used Axis2 or HttpClient's NTML authentication mechanism to have my application automatically 'log-in' using credentials from Active Directory and generate and distribute reports to many users.
we've successfully implemented that: JBoss 5 -> IIS proxy -> MS Reporting Services 2008 (via webservice).
There are few pitfalls: MS RS 2008 does not support 'Anonymous' access anymore (2005 does), and does enforce using NTLM authentication. That is still a challenge in Java world, there is no good NTLM library available.
To overcome that, we've implemented trivial proxy (IIS7 + ashx) that does NTLM authentication on RS (user/password hardcoded) and allows Anonymous access for JBoss (by simply rewriting http response).
Works ok :)
Cheers
P