Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I created a web service using vb.net in IIS that selects data from database and returns a List of objects with the results.
Is it possible to read that list of objects with a program made in MAC OS X that interacts with the method of the IIS web service?
Another option is use text files, but would be more effective using objects
It's possible, but there is no out-of-the-box solution.
Your options are:
Take a look at Mono project. It's cross-platform .NET framework implementation. You can write program for MAC OS X here and it seems to be the simplest way to go. However I'm unaware of the compatibility between Mono and Microsoft's CLR so you have to check yourself.
You could also possibly run your original service under Mono in which case it would be very simple. The problem is Mono does not cover 100% of the whole .NET framework.
Introduce serialization on service side and deserialization on MAC OS side. For example if you are be able to serialize your objects to strings, you can simply deserialize them on any platform.
Theoretically you could implement your own Object deserializer directly from your existing service. But in practice it would be almost impossible. You would have to handle so many cases, cross-platform issues and much, much, much worse things. I mention this only for completeness of the list. DO NOT go this way.
Appendix:
You must realize, what your service actually sends. It actually sends just some sequence of bits. Computer must correctly parse them to reconstruct original objects. This is tightly related to what Object is in memory. It's memory image depends on the CLR implementation. Without equivalent CLR you won't be able to simply read Object from source CLR.
So your task is to ensure you are able to reconstruct the objects
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Can anyone please clear me about following terms in simple way
1-IDL Interface Definition Language
2-Interoperability
3-Portability
4-API
Thank you in advance
Interoperability generally just means that the system has been designed in such a way that other systems can communicate with it (either sending it information to store/process, request information from it, or both.)
An IDL is a meta-language that allows for a program (dll, etc.) to describe its inputs and outputs - it's an interface definition language because that's all it provides, an interface. Many specific implementations exist, but they're all very similar in function, most are similar in syntax, and they're ''all'' entirely declarative (they specify names of functions with inputs and outputs, but not what those functions ''do''). Often they're used specifically for calling functions via RPCs.
An API is more general than that - an IDL can specify an API, but so can a web service (SOAP or REST), or any other way for one application, dll, etc. to call functions in another. "Abstract" means just that - it's just the concept of having an interface to call a set of related functions without knowing or caring about their implementation. It's completely language independent.
Portability is a different concept - that generally means being able to compile or run your program on different platforms without a lot of work. Of course, APIs can help with that, if they abstract away platform differences. If you wanted to read images from disk into memory, for instance, you would do that very differently on Windows vs. Linux, somewhat differently on Windows 8 vs. Windows 95, and perhaps slightly differently in x64 vs. x86 versions of the same OS. If someone gave you wrappers so that you could compile or link to different files based on your platform, such that you could always call the same functions in your code and get back the same data regardless of platform, the functions themselves would be the API, the wrappers would be implementations of the API, and your code would be considered portable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am Balu from Hyderabad. I have writing WCF Restful services for our Andriod / Iphone developers()They can use JSON format so that we are choosing REST). Actually we can do Mobile Application only one APP that can runs differnt projects. All the projects are dynamically comes from WEBSERVICE to MobileApp. So we can configure all the dynamic data from Web services only.
Only one App can handle 5 projects having totally 100-150 users. so i can write only one service using Factory Reflection methods to load projects dynamically.
Q) I have doubt that for our projects which WCF instance mode is suitable?
By reading WCF instance mode articles i understand that "percall" instance is suitable for our WCF service. Is my guess correctly or not? Please suggest me.
And i have one more doubt that If we are not specify an attribute as serialize then that object will not go through network properly? i have tried without serialization (i.e not mentioned "datamember" for particular property) its going well to Mobile App.
Please clarify my doubts and tell me whih instance mode i have to use?
Which instance is better?
Which ConcurrencyMode is better?
The PerCall instance mode is preferred when you don't need to maintain state between calls for the same client. In other words, your service is stateless. PerInstance is used when you need to maintain some state between calls for a client. And finally, Singleton is used when you need to reference state between multiple clients. Depending on your binding and security settings, you will default to either PerCall or PerInstance. PerCall is ideal because it's easier for you to scale your service if/when you need to.
For your ConcurrencyMode, the default is single threaded. Since you're asking, I would suggest leaving this as the default (generally). However, take a look at the tricky case I talked about here.
The [DataContract] and [DataMember] attributes are not necessary as of .NET Framework 3.5. Prior to that version, you had to be explicit and specify these attributes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
One question that I have long asked myself is in object oriented programming,how should data such as settings and properties be passed around in an object oriented manner?
For example, most programs have options, say you have an option to set the undo level. This must be obtained and then set to a new value. If these settings are saved in an xml file, that section of the application (the option dialog) still needs some kind of xml parser to load the data. In another scenario where you would instead have an object that represents getting and setting settings, each area that needs this would have global access to all settings and a pointer to it would need to be passed around.
In a scenario like Maya or 3DS Max where these use huge gui systems to set object properties, how is this done in a clean and OO manner? The widget, needs to be given the data from the 3D object, and needs to send information to this object. Should a dialog know anything about 3D objects? Probably not. So how is this usually done?
In another scenario, I might need to update a status bar when my frame gets a mousemove. Does that mean my frame should have a pointer to my status bar?
Any abstract examples or readings about this would be appreciated.
Thanks
In a previous job, we had several XML files for our various apps, and much of the configuration was similar, but varied depending on the environment and execution context. Much of this configuration was usernames and password for third party services. When a password would change, we'd have to scour through dozens of XML files and make the changes, then, re-deploy dozens of apps.
I migrated all of the XML configurations to objects using interfaces and a type hierarchy. The interfaces allowed me to code against a common configuration structure, and get compile time support as well as use dependency injection to resolve the run-time instances. The type hierarchy allowed me to define the non-changing configurations once, in a base class, and only override the actual values that differed.
This would be overkill, I think, for a small app, but was imperative in our case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm looking for a 'best practice' in the industry for integrating SAP with a .Net application. So far I only need to read data from SAP, there's no need to update.
The most straightforward way I've found is using SAP Connector and call a BAPI. I am using SAP Connector 3.0. But I'm just wondering whether there's better design out there for retrieval of data? The requirement is - to touch SAP as little as possible and able to transfer data in bulk.
Also, if using this design, other than the SAP login info which I can safeguard via standard encryption etc, is there any other security concern?
Thanks.
I've written many SAP RFC applications. I believe that the .Net connector sits on top of their RFC protocol as does the Java connector. In my experience, the best practice depends on who you ask at SAP. They do have a web application server (WebAS I think it is called these days....it was renamed a few times) that can probably host a web service, but it depends on what you have installed. I think many people opt for the .Net or Java connector still. (I prefer the C++ library personally since it is quite fast, but that is only for the extremely foolish ;) )
My information may be dated, but if they have been consistent then the RFC communication layer is not encrypted out of the box. There is a third party plugin that is used on SAP GUI and all RFC type connectors (.Net/JCo) to encrypt the data stream. You have to set it up in the rfc .ini file.
Then there are IDOCs, which I don't think you want to play with. It is a flat file format much like EDI but dumber.
About the security part, if you're using the equivalent of JCO with .Net, you have a user on the SAP backend to connect with.
This user should be of type "Connection" (so that no-one can use it with the SAPGUI), and should have authorizations that are limited to what is needed (so that no program can use it to perform others operations that you did not thought). While the chance that someone manage to get this user/password are low, you don't take chance with productive datas. Also, password should not be a simple one.
This may sound like basic security, but since i just found the exact opposite on a productive system, i prefer to state it.
Regards
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
With all the key value data stores out there I have started to create an abstraction layer so that a developer does not have to be tied in to a particular store. I propose to make libraries for:
Erlang
Ruby
Java
.NET
Does anyone have any tips on how I should go about designing this API?
Thanks
First off, and as a general rule for anytime you build "pluggable" abstraction layer, build it to support at least two real implementations to start. Don't build it for just one datastore and try to make it abstracted, because you'd overlook a details that won't plug into another implementation very well. By forcing it to use two seperate implementations, you'll get closer to something that is actually flexible, but you'll have to make further changes to support a third and fourth data store.
Second, don't bother, these things already exist. Microsoft has provided a ton of these for their technologies (ODBC, ADO, ADO.NET, etc), and I'm sure Ruby/Java/etc has several as well. I understand the desire to encapsulate the already existing technology, but the more data stores you need to support, the more complexity you need to build in, and the closer you'll get to ADO.NET (or similar technologies). Companies like MS have spent a ton of money and research on solving this exact problem, and that is what they came up with.
I would strongly recommend checking out Twitter's Storehaus project - this is a key-value store abstraction layer for the JVM and written in Scala, supporting (to date) Memcache, Redis, DynamoDB, MySQL, HBase, Elasticsearch and Kafka.
Storehaus's core module defines three traits:
A read-only ReadableStore with get, getAll and close
A write-only WritableStore with put, putAll and close
A read-write Store combining both
In the Ruby ecosystem, you should check out moneta, which again provides a unified interface to key/value stores. It has a lot more features than Storehaus.