I am using HazelCast to cache data from a database in a Proof Of Concept to a likely customer.
Client layer is in C#. I am using the .Net dll to retrieve data from the HazelCast layer.
My requirement is to execute some business logic steps followed by a transaction. This transaction will insert/update few records in the database.
So, I want to execute a service method which will take an object as input and return another object as output. The method implementation will have the business logic followed by the transaction. The method should return the result of the execution.
I see that I cannot invoke a generic service through the HazelCast client.
Client only provides methods to get data through HazelCast datastructures.
Is there a solution for my requirement?
Thanks for your answers.
s.r.guruprasad
Distributed Executor Service or Entry Processor is what you are looking for but apparently it is not made available for a .NET client.
Solution would be have another webservices layer which can make use of Hazelcast's Java client which supports them.
http://docs.hazelcast.org/docs/3.5/manual/html/distributedcomputing.html
Related
We are using kogito runtime and data index. Need to have distributed transaction management for the process.
What we see is domain object is persisted and process instance is not created if there is issue with Kafka. Similarly process instance gets created but not. Domain objects if there is issue with kogito runtime persistence.
What can we do for correct rollback for the apps.
How to enable dostributed transaction manageme t between kogito apps and kogito runtime especially data index.
Processing of Kafka messages in Data Index is transactional so it should be all or nothing for domain and process instance. That means, for every message received from Kafka it will update the domain and process instance in the same transaction to avoid inconsistencies, if that is not working somehow we need to investigate.
As for consistency with the runtime, I would recommend looking into the outbox pattern using Debezium there is an example using MongoDB (https://github.com/kiegroup/kogito-examples/tree/stable/kogito-quarkus-examples/process-outbox-mongodb-quarkus). We plan to extend that to other DBS such as PostgreSQL.
Which persistence backend are you using? And Kogito version?
I have been reading much Spring Cloud DataFlow and related documentation in order to produce a data ingest solution that will run in my organization's Cloud Foundry deployment. The goal is to poll an HTTP service for data, perhaps three times per day for the sake of discussion, and insert/update that data in a PostgreSQL database. The HTTP service seems to provide 10s of thousands of records per day.
One point of confusion thus far is a best practice in the context of a DataFlow pipeline for deduplicating polled records. The source data do not have a timestamp field to aid in tracking polling, only a coarse day-level date field. I also have no guarantee that records are not ever updated retroactively. The records appear to have a unique ID, so I can dedup the records that way, but I am just not sure based on the documentation how best to implement that logic in DataFlow. As far as I can tell, the Spring Cloud Stream starters do not provide for this out-of-the-box. I was reading about Spring Integration's smart polling, but I'm not sure that's meant to address my concern either.
My intuition is to create a custom Processor Java component in a DataFlow Stream that performs a database query to determine whether polled records have already been inserted, then inserts the appropriate records into the target database, or passes them on down the stream. Is querying the target database in an intermediate step acceptable in a Stream app? Alternatively, I could implement this all in a Spring Cloud Task as a batch operation which triggers based on some schedule.
What is the best way to proceed with respect to a DataFlow app? What are common/best practices for achieving deduplication as I described above in a DataFlow/Stream/Task/Integration app? Should I copy the setup of a starter app or just start from scratch, because I am fairly certain I'll need to write custom code? Do I even need Spring Cloud DataFlow, because I'm not sure I'll be using its DSL at all? Apologies for all the questions, but being new to Cloud Foundry and all these Spring projects, it's daunting to piece it all together.
Thanks in advance for any help.
You are on the right track, given your requirements you will most likely need to create a custom processor. You need to keep track of what has been inserted in order to avoid duplication.
There's nothing preventing you from writing such processor in a stream app, however performance may take a hit, since for each record you will issue a DB query.
If order is not important, you could parallelize the query so you could process several concurrent messages, but in the end your DB would still pay the price.
Another approach would to use a bloomfilter that can help quite a lot on speeding up your checking for inserted records.
You can start by cloning the starter apps, you could have a poller trigger an http client processor that fetches your data and then go through your custom code processor and finally to a jdbc-sink. Something like stream create time --triger.cron=<CRON_EXPRESSION> | httpclient --httpclient.url-expression=<remote_endpoint> | customProcessor | jdbc
One of the advantages of using SCDF is that you could independently scale your custom processor via deployment properties such as deployer.customProcessor.count=8
Spring Cloud Data Flow builds integration streams for data based on the Spring Cloud Stream, which, in turn, is fully based on the Spring Integration. And all the principles exist in Spring Integration can be applied everywhere there on the SCDF level.
That really might be a case that you won't be able to avoid some codding, but what you need is called in EIP Idempotent Receiver. And Spring Integration provides one for us:
#ServiceActivator(inputChannel = "processChannel")
#IdempotentReceiver("idempotentReceiverInterceptor")
public void handle(Message<?> message)
Background
We are looking at porting a 'monolithic' 3 tier Web app to a microservices architecture. The web app displays listings to a consumer (think Craiglist).
The backend consists of a REST API that calls into a SQL DB and returns JSON for a SPA app to build a UI (there's also a mobile app). Data is written to the SQL DB via background services (ftp + worker roles). There's also some pages that allow writes by the user.
Information required:
I'm trying to figure out how (if at all), Azure Service Fabric would be a good fit for a microservices architecture in my scenario. I know the pros/cons of microservices vs monolith, but i'm trying to figure out the application of various microservice programming models to our current architecture.
Questions
Is Azure Service Fabric a good fit for this? If not, other recommendations? Currently i'm leaning towards a bunch of OWIN-based .NET web sites, split up by area/service, each hosted on their own machine and tied together by an API gateway.
Which Service Fabric programming model would i go for? Stateless services with their own backing DB? I can't see how Stateful or Actor model would help here.
If i went with Stateful services/Actor, how would i go about updating data as part of a maintenance/ad-hoc admin request? Traditionally we would simply login to the DB and update the data, and the API would return the new data - but if it's persisted in-memory/across nodes in a cluster, how would we update it? Would i have to expose this all via methods on the service? Similarly, how would I import my existing SQL data into a stateful service?
For Stateful services/actor model, how can I 'see' the data visually, with an object Explorer/UI. Our data is our Gold, and I'm concerned of the lack of control/visibility of it in the reliable services models
Basically, is there some documentation on the decision path towards which programming model to go for? I could model a "listing" as an Actor, and have millions of those - sure, but i could also have a Stateful service that stores the listing locally, and i could also have a Stateless service that fetches it from the DB. How does one decide as to which is the best approach, for a given use case?
Thanks.
What is it about your current setup that isn't meeting your requirements? What do you hope to gain from a more complex architecture?
Microservices aren't a magic bullet. You mainly get four benefits:
You can scale and distribute pieces of your overall system independently. Service Fabric has very sophisticated tools and advanced capabilities for this.
You can deploy and upgrade pieces of your overall system independently. Service Fabric again has advanced capabilities for this.
You can have a polyglot system - each service can be written in a different language/platform.
You can use conflicting dependencies - each service can have its own set of dependencies, like different framework versions.
All of this comes at a cost and introduces complexity and new ways your system can fail. For example: your fast, compile-time checked in-proc method calls now become slow (by comparison to an in-proc function call) failure-prone network calls. And these are not specific to Service Fabric, btw, this is just what happens you go from in-proc method calls to cross-machine I/O - doesn't matter what platform you use. The decision path here is a pro/con list specific to your application and your requirements.
To answer your Service Fabric questions specifically:
Which programming model do you go for? Start with stateless services with ASP.NET Core. It's going to be the simplest translation of your current architecture that doesn't require mucking around with your data layer.
Stateful has a lot of great uses, but it's not necessarily a replacement for your RDBMS. A good place to start is hot data that can be stored in simple key-value pairs, is accessed frequently and needs to be low-latency (you get local reads!), and doesn't need to be datamined. Some examples include user session state, cache data, a "snapshot" of the most recent items in a data stream (like the most recent stock quote in a stream of stock quotes).
Currently the only way to see or query your data is programmatically directly against the Reliable Collection APIs. There is no viewer or "management studio" tool. You have to write (and secure) an API in each service that can display and query data.
Finally, the actor model is a very niche model. It serves specific purposes but if you just treat it as a data store it will not work for you. Like in your example, a listing per actor probably wouldn't work because you can't query across that list, or even have multiple users reading the same listing simultaneously.
Its a Spring Integration application.I have a requirement where I need to persist to DB and then post to Queue/Topic. This should be part of a single transaction. I am planning to use the JTATransactionManager. Application Server is Tomcat. Would someone please provide some sample configuration code required for this implementation.
You need a third party stand-alone XA transaction manager such as Atomikos. Tomcat doesn't have one.
You might also consider alternatives to using full-blown 2pc.
I have a app in which I need to query a sharepoint site via services. The app will be under heavy usage so performance and scalability will be two of my priorities.
I started to investigate which service approach is better and from a perf point of view it seems that client object model is the one officially suggested, but when I came to scalability I personally found that actually web services seem more potent than client object model. This is because it seems that web services have async support for IO bound operations rather than client object model that doesn't. I say doesn't because as Stephen Toub said the ability to invoke a synchronous method asynchronously does nothing for scalability and I think BeginInvoke does just that.
I have to mention that I am using in my app C# 5 async/await feature in order to return the thread to the thread pool when queries are executed on the server.
My question is, what should weight more in order to take a decision?
Edit: It is worth to mention that I am not using the Silverlight CSOM, I am using the more generic .NET one.
This is an answer with no answer. :)
You are correct in that BeginInvoke is fake-asynchronous (i.e., it just issues the blocking call on a thread pool thread). So it would actually be worse, scalability-wise, than just invoking the blocking methods.
First, consider your scalability as compared to your Sharepoint server. If you're running on roughly equivalent hardware, then you probably don't need to scale any more than the Sharepoint server will. You would probably be fine with either solution.
If you do need to scale better (e.g., the Sharepoint server is a cluster or cloud, or if your machine is much lesser than the Sharepoint machine), then it requires more thought and likely testing.
The better performance in the client model is purely from its batching capabilities. So if your application won't use batching, then the (asynchronous) web services model would be better.
However, if your application uses batching and needs to scale better, then there isn't an answer. In this case, the only way to know is to build a test case both ways and measure it.
Actually, the client object model not only provides, but sometimes requires asynchronous access. You can find more info in the Data Retrieval Overview but the short version is that:
You create and load one or more queries in a ClientRuntimeContext then
Execute all loaded queries either synchronously with ClientRuntimeContext.ExecuteQuery or asynchronously with ClientRuntimeContext.ExecuteQueryAsync with two callbacks for success or failure
You don't have to use BeginInvoke anywhere.
In fact, the Client object model in Silverlight provides only the Async method in which case you are forced to execute the call asynchronously.
The syntax is quirky, but the client object model targets .NET 3.5 and Silverlight, so it wasn't possible to provide a Task based interface. You can even argue that callbacks are somewhat simpler than the Begin/End pattern and definitelly better that raising completion events.
EDIT
As #alexb noticed, ExecuteQueryAsync is available only in Silverlight. There are other ways to work asynchronously though.
You can take advantage of Sharepoint's OData support to query lists using WCF Data Services. The query scenario is a bit similar, as you submit your query and wait for a callback when the results come in. In the meantime, you get access to a DataServiceQuery object that represents the asynchronous query.
This method uses REST/Json and therefore lighter on the wire than the web services. The LINQ and ORM-like API are also easier to work with compared to the web services.
Sharepoint's support is described in Query SharePoint Foundation with ADO.NET Data Services and asynchronous querying is described in How to: Execute Asynchronous Data Service Queries (WCF Data Services)