I'm trying to come up with a proposal for a client for an interface with a European Automotive manufacturer. The standard interface to transfer data files(EDIFAC) is ODETTE-FTP (OFTP).
I'm trying to find a native component solution, much like what's available for other FTP formats. After much Google searching I haven't been able to find that solution. IP*Works has a BizTalk add in, and there is an open source Java project is all I've turned up.
Anyone have any good leads on this? Having to roll my own OFTP solution from scratch is going to put us outside the time/cost constraints of our client.
I'm the one that developed the open source Java project for Odette FTP. ACCORD is a project actually being developed by Neociclo under the OW2 Consortium, focused to bring a set of tools around the OFTP connectivity, but so far we've a stable OFTP2 component library that is being used around.
I would propose you to consider the tools from www.iKVM.net and try creating a prototype for such interoperability between Java and .Net. If you find it's feasible or succeed in the prototype we can help you in setting up the component library to fit in your needs.
Get involved subscribing to accord-users#ow2.org mailing list.
Best regards,
Rafael Marins
Related
I am looking out for developing a C# application which posts message to a ebMS3 platform using AS4. I am new to this area. Could anyone please help? Is there any third party libraries to do this easily? If not, how we post messages using AS4 from a c# solution.
I have just implemented our own AS4 solution, and it is hard task to accomplish. Especially because .NET does not support SOAP with attachments out of the box. And there is a lot background knowledge you need to know about - all the different specifications AS4 is based on. I have not been able to find an AS4 API written in .NET without it being a standalone solution as well...
First thing is to understand AS4, and a good place to start is this blog:
https://www.codit.eu/blog/2016/02/03/as4-for-dummies-part-ii-messaging-overview/
And then you will have to understand most of the EBMS3 specification:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html
That being said - it is not impossible.
I have been looking at the AS4.NET framework as Sander talks about, and it is well-written and a very good starting point for exchanging AS4 messages. I have used it as a test-endpoint.
So unless you need to incorporate AS4 directly into an existing product (which we needed to), I can only recommend using AS4.NET.
AS4.NET is also open source (and e-SENS profile conformant), so you can have a look at their code-base and let you inspire by the hard parts in AS4.
For the MIME parts I can recommend Mimekit: https://github.com/jstedfast/MimeKit
And for some of the encryption/signing stuff Bouncycastle is great: http://www.bouncycastle.org/csharp/
Not sure whether it can be used as a library, but for a project within the European Commission an open source .NET based AS4 implementation was developed. You can find it here in the EC's code repository. I don't know if there is any support on this, so if that is important you should probably consider another implementation. A list of solutions tested by the EC for conformance with their own profile of AS4 is available here (or if that link doesn't work by searching for "as4 conformance tested implementations")
Note that most are standalone applications which you connect to for executing the AS4 message exchange. Most offer different integration options, so you should be able to integrate it into your solution.
I am doing a project and have a C# library but I need to call it in C code on Linux. What's the most efficient way to do this? Performance is the first consideration.
Of course, I can make a C# service and use TCP to talk. But I wonder if it's the best way...
Thank you!
You can also use CoreRT to create native libraries from C# code and call them from C. You can find an example here
Edit: CoreRT has moved to runtimelab feature NativeAOT. Updated link.
I think the most standard solution is to have your C# service export a "web services" remote API, which the C code can then access via the standard Linux web services packages. In effect these support a form of RPC, but with web pages encoding the request and also the reply. The advantage of using web services is generality; your solution will port to any platform and will work from any language, not just C.
Another way to go is to use one of the new open-source packages from Google, Facebook, Twitter, etc. A bunch of the cloud vendors are open-sourcing their RPC infrastructures because many customers pose your exact question and need these solutions. Those will definitely be faster and more powerful in other ways too: they include powerful performance visualization tools and debuggers of various kinds. Microsoft has a remote method invocation technology too. So these are an option, perhaps less general but definitely faster. So you then have to ask how important speed is, for this particular path...
The bottom line then is that there are maybe five packages you could use. No idea which is winning or best!
I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)
You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.
This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested
You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.
A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN
I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.
Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.
In a .NET C# program, is it easy to transition from FTP to SFTP? I'm trying to get a sense of how muh time it would take the contractor to make the transition. My personal experience is mostly with PHP, so I have no idea.
Basically, what I'm talking about, what steps would have to be made? Obviously, different commands, but would anything else in the code itself? Like do the commands require different formats, etc.?
Also, if anyone has a list of all the .NET/C# FTP and SFTP commands, that would be really helpful.
Clarification, as requested: The program is uploading extremely small files (20 KB) to a server. By format, I mean visually, because I was wondering about a find/replace job.
This is a pretty vague question. You haven't told us what the C# program is doing with FTP. Is it a server, is it a client, is it doing directory listings, is it uploading 100 GB files? What library is it using?
According to this forum post , there is no built-in support for SFTP in .NET, so you would have to use third-party libraries such as SharpSSH or Granados SSH.
I don't really know what you mean, "do the commands require different formats". Obviously, the code will use different:
Libraries
Types
Wire protocol.
It will obviously appear somewhat similar, thanks to the abstraction of the libraries. I suggest you provide more information, and a clearer question.
One thing that you'd need to consider is how well your current code is written. If your existing FTP implementation is horribly designed spaghetti code then converting it to SFTP may be next to impossible and take way longer than you'd like. Without knowing the current state of the code, it would be difficult for anyone to make a good estimation. And even if you do get an estimation from people on this site, I wouldn't recommend trusting it (even though the people on this site are great) since without all the information in front of them it will be next to impossible for anyone to come up with a reliable estimate.
Perhaps you should consider hiring a good consultant or business analyst to do a thorough estimate for you.
It really depends on what C# library your developer has used to implement FTP.
If, for example, they used edtFTPnet, a widely available open source library, then the upgrade path is trivial if you replace it with edtFTPnet/PRO. The PRO version has the identical API and just a few extra lines of code would be needed.
I've been down this road.
It depends, but keep in mind that SFTP, FTP-SSL and FTP are different.
If he's writing the SFTP libraries himself, a month or two, since it's a lot of work to make it perfect and compatible. But he should NOT do that.
In short, get him to use an external library to add SFTP functionality. This will make it pretty short. Maybe a week or two of full-time work, but it depends on how involved it is. There's open-source options.. But for $50-150 you can get a license to well-maintained code that's really easy to use. will save him days of work.
There's links above, but I'd look at:
Free:
http://www.enterprisedt.com/products/edtftpnet/overview.html
Commercial:
http://www.weonlydo.com/
Anyone successfully using this in c# or is there a better alternative to this? Also any good working project that I can look at and get a good feel? most projects i have come across is in C++ and was looking for a C# project
Yes, we're using it in a tool to let customers upload logs, dumps, etc. to our customer support department. You could use it directly via PInvoke/COMInterop, but I suggest to have a look at SharpBITS.NET, which wraps the BITS interface nicely.
I'm the PM for the BITS team at Microsoft -- and we have a new learn.microsoft.com page that talks about using BITS and C#, plus a brand-new C#/WPF sample on GitHub.