Building Rule Based on JSON Object - rule-engine

Currently, we are exploring CodeEffects for our one of the rule engine proposal.
We have a dynamic type which is a JSON string. During runtime, we need to apply the rule for JSON using CodeEffects. Is it support for FlexSource or any other possibility.

You need to serialize your Json string into a .NET object, fill it with data if needed, and pass that object to the Evaluator together with your rule for evaluation. The FlexSource is designed specifically to support this kind of scenarios. Download the FlexSource demo project from Code Effects website and replace the XML data file used there as the source object with your Json.

Related

sapui5 what are the differences between XML Model and JSON Model

Currently in all of my projects im using JSON Model for all client side manipulations. But XML Model also do the same.
Can someone help me the exact differences between XML Model
and JSON Model. And why developers are preferring JSON Model over XML Model??
It is easier to use JSON in JavaScript, as it is derived from JavaScript.
Some JSON benefits:
less verbose
easier to read and write
easily accessible with JSON.parse() function. XML parsing is inherently more work in JavaScript (XMLModel would be doing the work, but it is still more work being done).
Some XML benefits:
schema support
comment support

Retrofit: Update only specific fields

I've been trying out Retrofit and I really it's simplicity.
However I have an otimization concern.
I'm using Parse for my backend and it has a pure Rest API.
When I want to update an object I use a PUT HTTP Request and pass in the body only the specific values I want to update.
However, using Retrofit I always have to serialize the entire object when passing it using the #Body annotation. If I have a very large object, this is very inneficient.
All the solutions I see is using Annotations to inform the Converter which fields are exposed. However this affects all requests and won't work if I have different update methods for updating different fields.
I think I have two options:
Pass the parameters I want to update as Form parameters and use
the #URLEncoded annotation. However this is not really RESTful
and I don't think Parse supports it.
Create an annotation to inform which fields should be added to JSON in the body. For doing this, how can I access the method's annotations in the Converter, in order to select which fields to serialize?
Retrofit uses Gson by default. And Gson excludes null values by default. So it shouldn't be a problem (unless you are using primitive types in your object)

Transfering OWL data from client to server using GWT

I am working on a web application which is being developed using GWT. I am also using OWL ontologies and Jena framework to structure semantic contents in the application.
A simple function in the application would be getting some data from the user and send it to the servers side to be stored as a data graph using the ontology. I suppose one way would be to store the data as java class objects equivalent to the ontology classes and send them using the GWT async communication. To convert OWL classes to java, I used Jastor.
My question is that after the server receives the java class, is it possible to easily convert is to an OWL individual and add it to the data graph, using the functions of Jena and/or Jastor? For instance in the server side interface implementation we call something like this:
Public void StoreUser (User userObj) {
//User: a Jastor created java class. userObj is instantiated using the user data on the client side.
OntModel ontModel = ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM);
//Open the ontology here using inputstream and ontModel.read!
Individual indiv = (Individual) userObj.resource();
//Add the individual to the model here! }
Unfortunately I wasn't able to find any Jena function that can add an existing individual to the model.
Would you suggest another way to pass the ontology data to server side and store it, rather than using Jastor created classes (for instance using an XML file)?
Thanks for your help
There are two parts to the answer. First, an Individual is a sub-class of a Jena Resource, which is definitely something that you can add to a model. However, individual resources, or properties or literals are not stored in a Model. A Model stores only triples, represented as Statement objects in the Java API. So to add some resource to a model, you have to include it in a triple.
In Jena, an individual is defined as a subject of a triple whose predicate is rdf:type and whose object is not one of the built-in language classes. So if you have:
ex:my_car rdf:type ex:Ferrari .
ex:Ferrari rdf:type owl:Class .
(note: this example is entirely fictitious!), then ex:my_car would be an individual, but ex:Ferrari would not (because OWL Class is a built-in type). So, to add your individual to your model, you just need to assert that it is of some type. Since I don't know GWT and don't use Jastor, I can't say whether the type association that is normally part of a Jena Individual is retained after serialization. I suspect not, in which case you'll need to have some other means of determining the type of the individual you want to add, or use a different predicate than rdf:type to add the resource to the the Model.
All that said, personally I probably wouldn't solve your problem this way at all. Typically, when I'm working with client-side representations of server-side RDF, I send just the minimal information (e.g. URI and label) to the client as JSON. If I need any more data on a given resource, I either send it along with the initial JSON serialization, or it's just an Ajax call away. But, as I say, I don't use GWT so that advice may not be of any use to you.

Using RPC serialization/deserialization mechanism built in GWT

I am developing GWT offline application using HTML5 Local Storage. I would like to cache/store the transfer objects using com.google.gwt.storage.client.Storage (introduced in version 2.3). But the problem is that as for now (version 2.3) the Storage can only save the string values.
Is there any possibility to use GWT's built in rpc serialization/deseralization mechanism from client side code? So that I will be able to serialize transfer objects and store them in Local Storage and retrieve them when needed and deserialize the content.
GWT Docs have this to say:
Local Storage is String Storage
HTML5 local storage saves data in
string form as key-value pairs. If the data you wish to save is not
string data, you are responsible for conversion to and from string
when using LocalStorage. For proxy classes used with the GWT
RequestFactory, you can use RequestFactory#getSerializer() to do
string serializing. For non-proxy objects, you could use JSON
stringify and parse.
EDIT:
RequestFactory#getSerializer() returns an implementation of ProxySerializer. But
ProxySerializer Serializes graphs of EntityProxy objects. A
ProxySerializer is associated with an instance of a ProxyStore when it
is created via RequestFactory.getSerializer(ProxyStore).
So you cannot use it to serialize arbitrary objects. Only EntityProxy objects can be serialized this way. GWT documentation does not mention any method for doing such serialization for non-EntityProxy objects, so I think it is safe to assume that there is no ready-made solution for doing this so far. For non-EntityProxy objects, GWT docs (quoted above) recommend using JSON serialization.

Can an API in SOAP/WSDL be kept backwards compatible easily?

When using an IPC library, it is important that it provides the possibility that both client and server can communicate even when their version of the API differs. As I'm considering using SOAP for our client/server application, I wonder whether a SOAP/WSDL solution can deal with API changes well.
For example:
Adding parameters to existing functions
Adding variables to existing structs that are used in existing functions
Removing functions
Removing parameters from existing functions
Removing variables from existing structs that are used in existing functions
Changing the type of a parameter used in an existing function
Changing the order of parameters in an existing function
Changing the order of composite parts in an existing struct
Renaming existing functions
Renaming parameters
Note: by "struct" I mean a composite type
As far as I know there is not such stuff as per the SOAP/WSDL standard. But tools exists to cope with such issues. For instance, in Glassfish you can specify XSL stylesheet to transform the request/response of a web service. Other solution such as Oracle SOA suite offer much more elaborated tools to manage versioning of web service and integration of component together. Message can be routed automatically to different version of a web service and/or transformed. You will need to check what your target infrastructure offers.
EDIT:
XML and XSD is more flexible regarding evolution of the schema than types and serialization in object-oriented languages. Some stuff can be made backward compatible by simply declaring them as optional, e.g.
Adding parameters to existing functions - if a parameter is optional, you get a null value if the client doesn't send it
Adding variables to existing structure that are used in existing functions - if the value is optional, you get null if the client doesn't provide it
Removing functions - no magic here
Removing parameters from existing functions - parameters sent by the client will be superfluous according to the new definition and will be omitted
Removing variables from existing structure that are used in existing functions - I don't know in this case
Changing the type of a parameter used in an existing function - that depends on the change. For a simple type the serialization/deserialization may still work, e.g. String to int.
Note that I'm not 100% sure of the list. But a few tests can show you what works and what doesn't. The point is that XML is sent over the wire, so it gives some flexibility.
It doesn't. You'll have to manage that manually somehow. Typically by creating a new interface as you introduce major/breaking changes.
More generally speaking, this is an architectural problem, rather than a technical one. Once an interface is published, you really need to think about how to handle changes.