There seems to be a number of options for interfacing to Documentum; WDK, DMCL, DFC, DFS, DQL, etc.
What else is there?
When whould you use which interface? For .NET developers, for Java developers?
WDK is for making websites.
DMCL is an old api for communicating with Documentum, in last versions it's only present as an emulation layer, so it should be avoided.
DFC is the preferred API to interact with Documentum, provides all functionality.
DFS is for using Documentum from webservices.
DQL is for querying, it's SQL-like.
DFC and WDK are Java, the others are probably usable from .Net
David provides a good overview but to expand a bit...
DFC is the base Java api for interacting with Documentum. WDK is actually built on top of DFC. The DMCL is the legacy api built in C(or C++ I'm not 100% sure). Prior to D6, all DFC calls used the DMCL under the covers but that layer was rewritten in java for D6 and the DMCL is there just to provide backwards compatibility at this point.
As for accessing Documentum via .NET there is a Documentum PIA that you can use to access the DFC libraries from a .Net project rather than using the traditional Java route.
You could also consider using the CMIS (Content Management Interoperability Services) interface that's being developed for Documentum. It's a web service interface that expands upon AtomPub. It won't be able to leverage all the bells and whistles of the Documentum platform, but it should allow you to use other backends like Alfresco and SharePoint. There's an Early Access Release available via EMC for Documentum.
Massive operation, like bulk upload, you must use DFC, because some feature are accesible only via DFC.
Web operation, I suggest the use of DFS, with is own caching system (can be a problem) and session manager.
The code is more decoupled using DFS instead using of DFC.
DFC use is deprecated, but at the moment you cannot have the same result using DFS.
There is also some technical difference: for example DFC is RMI shared object, so the object is connect to the content server. Instead DFS after web service give you the object, the object is disconnect from content server.
In DFC you have to manage Session, connection, and so many other things tipical of RMI.
DQL is only a way to make query, and so other basic operation on Documentum.
Both David and shsteimer is right.
But Documentum PIA for .Net is not encouraged now because it will be deprecated in future edition of Documentum.
I just found this old discussion, but based on the following link, the "EMC Documentum REST Services" is something to consider:
https://community.emc.com/community/edn/documentum/blog/2013/06/22/announcing-emc-documentum-rest-services-70
Related
I have been very happily using Ninject for a long time now, and I really like it, but I am faced with a difficult choice since the release of ASP.NET Core and MVC Core.
Basically, out of the gate, Microsoft has revealed their own dependency injection system; Which is one that to my knowledge has gotten a lot of criticism. But my bigger problem lies with how it affects other libraries.
From another question I asked and other resources online, it seems that Ninject does not work out of the box with MVC Core. Though there is a "solution" given in the form of a verbose library Microsoft.Framework.DependencyInjection.Ninject and Ninject. This is even trickier because that library requires adding https://www.myget.org/F/aspnetmaster/ to your list of NuGet feeds.
I have done some digging and found where this library is hosted; It looks fine, it seems to work okay from what I can tell, but there are a few things that trouble me.
The library does not really appear to be headed by the Ninject creators
The library is buried pretty deep in an obscure repository
The actual Ninject resources online never mention it
So basically, I am very concerned that this is some kind of band-aide, and that support for Ninject (and even other container libraries) is dying out. Is there some hidden information that I'm just not discovering?
There is a discussion going on between maintainers of the existing DI libraries, whether or not to build, maintain and support an adapter for the new ASP.NET built-in DI system. The Autofac maintainers have confirmed that they will create and support an adapter, while the Ninject team has been silent, and other teams such as the Simple Injector team (that includes me) have explained that they won't support an adapter.
Personally, I think that the ASP.NET Core built-in DI library is a nice and clean DI library, but it is limited to simple applications. As I explained here, many features that are required for developing maintainable applications built around the SOLID principles are not supported. However, just like the Unity DI library did a couple of years ago, I think that this built-in container might actually trigger developers to start using dependency injection, which is a win for our industry.
These limitations make the built-in container especially suited to configure and extend the ASP.NET system itself. To build large maintainable applications, you will need to use a different DI library. This of course is fine; you will have to pick the right tools for the job.
Unfortunately, up until now, the ASP.NET team has communicated publicly that using a different DI library, means you will have to write/use an adapter. This unfortunately is the wrong message IMO, because most DI libraries are incompatible with the API presented by the built-in container (as I explained here and here in detail). Only Autofac seems reasonably in sync, which explains why the Autofac team choose to maintain an adapter. But do note that even Autofac has proven to be incompatible with the abstraction that Microsoft defined, and they (just like StructureMap) had to make big changes to their product to even be able to comply with the abstraction. And the Autofac maintainers are severely frustrated about the whole process and the abstraction in general. And as I explained here, even the ASP.NET provided adapter implementation of Ninject is broken.
This message by the ASP.NET team to use an adapter is IMO a big error, because this stifles innovation (while the DI library itself doesn't; it's just another DI library). The ASP.NET team is promoting a model where both your application components and the ASP.NET system (and all other sub systems that will plugin in the future) will be registered in your custom container. It is much more reasonable and practical to keep your application configuration separate from the configuration of the ASP.NET system (as explained here).
Because of this, I find the use of an adapter for any container rather useless. As I shown here it is really easy to plugin your own DI container, while keeping it completely separate from ASP.NET's registrations. This means that you don't need support for Ninject to be able to effectively use Ninject on an ASP.NET Core project. The only thing Ninject needs to do is to create a version that is compatible with .NET Core (in case your product needs to run on that new platform).
UPDATE: "Ninject 3.3.0 was released September 26th 2017 and now targets .NET Standard 2.0 and thus also runs on .NET Core 2.0." source
So in a nutshell, I'm not sure that support 'is dying out', although some DI maintainers (such as the Simple Injector team, and probably Castle Windsor and Ninject as well) have chosen not to build, maintain and support an adapter implementation for ASP.NET Core, because it is not needed, and is only in the way.
UPDATE November 2016
I've been discussing some improvements to ASP.NET Core with Microsoft to make it easier to plugin a container that don't have an adapter (take a look at my example repository and especially to the Startup.cs of the Ninject sample project), but until now Microsoft seems to stall progress because (as Fowler states hisself) their "bias towards conforming containers [is] clouding [their] vision".
The library does not really appear to be headed by the Ninject
creators
That library, and it would seem these also, look to be Microsoft created samples of Dependency Injection providers that were removed in beta7. Note that the link to DI in MVC 6 referenced by your original question says the following;
These DI container adaptors are temporary and are there for reference;
we expect that they will eventually be removed and replaced by the
respective container owners.
As they should be. Microsoft should not be responsible for maintaining 3rd party providers.
The library is buried pretty deep in an obscure repository
If you are not aware, ASP.NET 5 is still in development. Beta 7 is available on nuget as a pre-release, but there are other sources as well including;
https://github.com/aspnet/ (source code)
https://www.myget.org/gallery/aspnetvnext (nuget dev branch builds of the above)
https://www.myget.org/gallery/aspnetmaster (nuget master branch builds of the above [same as your question])
These sources are maintained by Microsoft.
The actual Ninject resources online never mention it
As with any new development, 3rd party library providers must themselves determine when (if at all) they will provide implementations of their products that support the new codebase. For some, it will be seen as most efficient to wait until the new framework is officially released, as API breaking changes are still highly likely to occur until that point. Whether support will be implemented at all is of course up to the providers resources, and/or in the case of open source the community.
Is there a common data interface for RavenDB? For example, how could Java, Python, or even PHP interact with RavenDB?
In RavenDB 3.0 they added a Java client as well. I haven't tried it myself, but you can read about it here:
http://ayende.com/blog/168354/what-is-new-in-ravendb-3-0-jvm-client-api
In that blog post Ayende also mentions:
RavenDB has always been accessible from other platforms. We have users using RavenDB from Python and Node.JS, we also have users using Ruby & PHP, although there isn’t a publicly available resource for that.
With RavenDB 3.0, we release an official Java Client API for RavenDB. Using it is pretty simple if you are familiar with the RavenDB API or the Hibernate API.
So to answer your question: No, there isn't a "common data interface" for everything, but most things are certainly doable.
Almost every ravendb command is available through HTTP via REST.
For version 2.5 it is documented http://ravendb.net/docs/article-page/2.5/csharp/http-api/http-api-single. For version 3 they ommitted that documentation (or it is not available yet), but it is still there.
The client (.net or java) is 'just' a wrapper around those HTTP REST calls that does things like caching, serializing, failover, etc..., to make it much easier to work with RavenDB in your application.
I just discovered this Language and I'd like to know if it's possible to make basic CRUD web app using a database.
There are libraries for mysql and postgresql, and the core library provides a web server with HTTP, HTTPS and WebSocket support.
There is a templating library which isn't part of the official release. And, there is also a community mustache port (I don't think it builds at the moment, so you may need to fix it).
So it's definitely possible. But you'll be an early adopter. If you want to get stuff done quick, I'd choose something else, but if you're wanting to learn new skills, dive in.
Sure. It's a pretty new language though so you aren't going to find the robust library support you will in other languages just yet. It's rapidly growing however so I don't think it will be long. You can either write your server in dart or write your server in another language and expose a basic HTTP interface for your Dart client to consume.
Here is an example of writing a simple web application which creates and stores "blog" posts. Both the client and server are written in Dart. The database is MongoDB.
Also check out this question for more information.
I want to know how to enable the developers to create add-ons for my application like chrome, firefox, blender and VS?
I'm asking here about the concept how the made it? programmatically, what I need to provide in my application with to make this?
any references I may help me?
There is a number of options.
You can embed a scripting language (or an entire VM, like .NET or JVM) into your application, providing a decent API for all the internal functionality. If your application is built on top of such a VM already, chances are you don't need to do anything specific to enable an extensibility, just make sure your API is available and documented. Popular embedded scripting choices are Lua, Python, Guile and Tcl.
Alternatively, for a purely native code, you can provide your API as a separate dynamic linking library, and allow to load third party modules (linked to that library).
You can also make your application modular (split into separate processes), with the components talking to each other over a simple, text-based protocol via pipes or sockets. A very elaborate and powerful infrastructure is available for such an integration option, which is known as the "Unix way". In this case users will be able to choose any way of integrating their extensions with your core functionality.
Choose any, depending on a nature of your application.
Can anyone provide a suggestion on the best way to use Exchange Services 2007 in a Mac application using Cocoa? I need to access Inbox mail messages and their headers to parse the information I need.
I have written an implementation in my .NET application, but of course .NET provides some nice libraries to handle all the complex types and such.
Thanks in advance.
Cocoa doesn't really have any decent SOAP libraries available that I'm aware of. You could either try to access Exchange via IMAP if it's enabled for your server (e.g. with MailCore) or embed another language with better SOAP support (e.g. Java, Python). Here's an example of using Java/JAXWS to talk to EWS.
Microsoft has an EWS Java API but it was apparently so poor-quality that they pulled it. However, there's a link to the download on that page if you want to try it anyway, and it's open source so you could potentially fix any bugs you ran into.
Doc,
I came across this EWS OSX Widget in my search for the same thing. It would be good to know if this works for you.
http://ewsmacwidget.codeplex.com/releases/view/16559