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
Someone told be about this Service Platform: http://particular.net/ for implementing SOA oriented applications.
I really find it a bit confusing at first glance, so i would like to ask some questions about it:
Services are SOAP or REST?
How are data contracts and service contracts specified?
Are this services externalizable to outside consumers via WSDL metadata endpoints?
A service not implemented in .net (java, ruby) can be inserted in the service bus?
Which is the protocol used for messaging?
What are your general thoughts about this service platform?
For full disclosure, I'm the founder of the Particular Service Platform, but I'll try to keep my answers as objective as possible:
Services are SOAP or REST?
While the platform allows the use of WCF to expose endpoints for consumption by 3rd parties, the focus is on queuing - MSMQ, RabbitMQ, etc.
How are data contracts and service contracts specified?
Contracts are message-oriented from a philosophical perspective, but in practice they're just regular POCO classes and interfaces.
Are this services externalizable to outside consumers via WSDL metadata endpoints?
See the WCF comment above.
A service not implemented in .net (java, ruby) can be inserted in the service bus?
Interop can be done via WCF but the preferred model would be to use either ActiveMQ, RabbitMQ, or WebSphereMQ.
Which is the protocol used for messaging?
I'm not entirely sure what you mean by "protocol" beyond the queues mentioned above, but we support XML, Binary, and JSON serialization out of the box and also enable you to plug in your own serialization mechanism.
What are your general thoughts about this service platform?
As one of the owners of this platform, I feel my necessarily biased answer wouldn't contribute much on this point.
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 6 years ago.
Improve this question
What are the best practices in chosing specific communication protocol in building Microservices?
For instance, when building MySQL microservice, shall I use the native MySQL connection or prefer a wrapping API in REST or something else?
Secondly, shall I choose and use a single protocol like REST, JSON-RPC etc. for all interaction among microservices?
Thanks!
Use as little layers as possible, so don't do a REST API on top of MySQL if it's not needed. Keep it as simple as possible.
That being said, try to avoid RPC between microservices. Use messaging instead so that the services can be autonomous. We do not want them to be dependent on a service that might not be running or anything. Define bounded contexts and have microservices live within these bounded contexts, making them the owner of a specific business issue.
From that point on you can choose whatever storage, protocols, security, etc. you require for every single microservice. It's probably easier for the messaging system to choose a single option. Although not required, it makes sure you do not need to implement gateways everywhere to convert from one to the other.
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 7 years ago.
Improve this question
I am thinking of using either one of them in building our startup which is like a job portal with validation,verification and includes special features for freelancing and all.
Is meteor or sails good for using as a backend or should we go with more robust backend like Django? Will using javascript on our backend provide the ability to scale in the future moreso than Django/python?
I would really like some opinions in this matter to get to a decision.
sails.js and meteor are both great options for production.
Both frameworks have good real-time (socket.io) support, large/active communities, support a stateless backend design which make horizontal scalability possible, and are great for getting a web application spun up quickly.
sails.js - http://sailsjs.org
broad database support through the Waterline ORM (there are over a dozen supported databases)
concepts should more familiar to most node.js developers (it's built on express)
modeled after rails, grails, and django, so the paradigm is more familiar to developers with experience in those tools
extensible through npm package manager via express middleware and custom modules
meteor - https://www.meteor.com
better integration between the backend and frontend
project is VC-backed with a firmer corporate backing
extensible using custom package manager and extension system
built-in deployment system and hosting on meteor.com
Will using javascript on our backend provide the ability to scale in the future moreso than Django/python?
Probably. As with anything, you just have to do it right.
My overall opinion is that meteor is sort of cult-ish and monolithic, and that once you've chosen it, you're locked in. sails.js is built on express, so it's easy to split out functionality and integrate with other tools.
My disclaimer is that I work for Balderdash (the company that invented sails.js); but on that note, I can also tell you that millions of users are served by sails.js applications. We find that it's quite good, and our business is thriving because of the power of sails.js. I know folks who have used meteor with success as well.
I think this is a primarily opinion-based question, so you're going to receive answers from the very same "type".
But I can tell you one thing: Meteor is robust enough for production use, specially now that they hit the 1.1 release (https://www.meteor.com/blog/2015/03/31/meteor-11-microsoft-windows-mongodb-30).
Meteor is perfectly suited for startups, since it brings everything you need (and more) into a single "pack".
Check this: http://meteorpedia.com/read/Why_Meteor
So yah, that's my answer going for the Meteor side.. (not very technical, I know).
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 7 years ago.
Improve this question
I'm beginning to investigate service-oriented architectures and wonder how best to structure the messaging between processes. It seems that direct HTTP calls between services and/or a pubsub bus are two common approaches. In what sorts of situations is one more favorable than the other? I can see how pubsub would lead to more decoupled services but I also get the impression that it becomes much harder to track a message's path though the system.
What are some resources for learning more about this? I'm particularly curious about this in the context of very small, "hand-rolled" services (i.e. Ruby/Sinatra, Node/Express, Redis pubsub, etc.) as opposed to any of the prescribed SOA stacks/suites out there...though I'm sure the same principles apply.
Thanks!
I'll give you my two cents.
but I also get the impression that it becomes much harder to track a message's path though the system.
You're right that pubsub SOA architectures AKA (SOA 2.0) providing a great deal of decoupling, but you also pay a price, because this is exactly what happens, although tools like splunk can help a lot.
seems that direct HTTP calls between services and/or a pubsub bus are two common approaches
Actually if you look at the most used .net event soa frameworks (NServiceBus, Mule and MassTransit) they don't use http calls, but yes you can implement a microservices architecture and use http as the communication protocol.
I understand you want to start applying some of the best enterprise architecture concepts but I would say that you better off starting with simpler, yet stronger foundations. There is no point in you jumping to event soa, without knowing if you really need it. If I was starting a new system and wanted to make sure that I was properly adapting DDD and SOA principles, I would start by identifying the services for my domain. So say you have 3 services, you could start by declaring the public contracts for each of those services, you don't need anything special, you can start with WCF/ASP.NET Web API with a sync REST API. You would then make sure that each service would get its own database, because you're aiming for low coupling, and you could then create an API layer (the one visible to the outside world) again using WCF/ASP.NET Web API, because your microservices should not be exposed directly to the outside world. So at this point you would have a SOA like, yet simple in design, architecture, but because you would have well defined contracts, you could well extend your services by adding async capabilities to them and for that you would start by adding a message queue to each of the services. You know, you don't need to start with a complex system, start with something basic, well defined, which allows you to scale if you have to.
The system I described could be extended to support events easily if you wanted to, and the fact that you would at this point have already sync messages would not stop you from adding asyn messages to the system as well.
But these are just my two cents.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm in the position where I may be creating a new web service from scratch - without much pre-existing infrastructure to have to contend with. What resources are there that talk about the architectural aspects of deploying a web service? [Clarification: I'm not talking about an Enterprise SOA orientation here - rather setting up one family of services for the public.]
A first list of topics that I'd like to see covered are:
SOAP vs. REST
JSON vs. XML
Relational Database Backed vs. SimpleDB backed vs. ?
Scaling
Availability
Models for restricting access
Models for throttling access
What would you recommend?
I would recommend Restful Web Services. It's weel written, very complete and vendor agnostic. Also it has a fairly good coverage of both REST (with comparison to SOAP/WS-*), HTTP scaling, resource formats (JSON, XHTML, Atom, XML), security and service modeling.
If you have any specific scaling needs, then you might also want to read Building Scalable Web Sites. It will teach you everything worth knowing about etags, proxies, caching, edge computing and so forth. However if you are just starting out, then the Rest book I mentioned earlier will properly cover most people needs.
If you decide to use Microsoft technology (WCF) then you could check out the Microsoft Patterns and Practices group's online library of guidance.
They have a library located here as part of MSDN which deals with Web Service security, Enterprise Buses (obviously not applicable to you scenario) and PAG's own Web Service Software Factory.
Their main page is located here.
Otherwise, assuming you choose WCF it might be worth checking out further reading such as Juval Lowy's book on WCF, although I fear it may cover the implementation more than the theory and design facets.
Do you know roughly what technology platform you'll be working from?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
What is BPEL? I'm looking for some nice simple examples of BPEL usage. The wikipedia page isn't too enlightening. How about a "Hello world" in BPEL? A BPEL shell? A BPEL IDE?
BPEL is just a way to build centralized control of disparate but interdependent systems from a centralized place.
Users can create rules, workflows and other control structures to make sure everything plays nice.
For example, say you run a school district; in particular, a school districts information infrastructure. Over the years you have accumulated a motley assorted group of hardware and software. For each aspect of your district; grading, attendance, bus routes, nutrition, payroll, etc, etc, you have various distinct software written in different languages by different vendors. Well, you have some overlap in your data and different end users use the different pieces of software and they expect it all to agree with each other - you use your BPEL system to be sure all the data is where it is supposed to be when it is supposed to be there.
You also have some processes that absolutely have to run after the successful completion of another process on a different system. You use BPEL to make sure those are coordinated. BPEL is all about centralized coordination and you probably don't need it unless you are in a large organization and lots of different systems.
This BPEL tutorial covers on how to write a BPEL from scratch.
Writing a simple WS-BPEL process for WSO2 BPS and Apache ODE
This article covers the IDE based BPEL process development. Developing WS-BPEL Processes using WSO2 Carbon Studio
Have a look at the ActiveBPEL IDE. Also you can find a short 101 BPEL guide in Oracle. The demo is about Oracle's BPEL engine, but the source is general enough.
Background
I'll add a little bit to what has been said. BPEL is a procces orchestrator. You can use it to do any kind of serialised of parallel process automation.
For example: A customer buys something on the website of company 'AAA', this instigates a BPEL process in that companies service oriented architecture (SOA). Within this BPEL a series of BPEL components does their work on the payload generated by the consumers purchase. This payload can consist of all kinds of information regarding the buyer and the purchased item, such as <shippingAdress> and <itemId. An invoke BPEL component can be used to send information from the payload to another BPEL process or to another chained company through a webservice call in the composite wherin the BPEL lies. That company can be responsible for the shipping of the purchased item, another company can be responsible for the processing of the money. All of these companies dealings are automated through composite applications containing series of BPEL processes. All are communicating information across the web through (a)synchronous webservice calls.
The BPEL part is where the logic lies, where the true automation/orchestration of function resides.
Getting started
The Oracle documentation websites for soa suite 11g and 12c are quite extensive for those willing to read. If you like to do a tutorial from the basics and up you can use their suggested code to get started. It's a little bit trickier when it comes to applying their documentation to existing BPEL projects, but its still a good source for many basic questions and examples regarding SOA.
https://docs.oracle.com/cd/E12483_01/integrate.1013/b28981/async.htm
Also, a quick google search will lead you to some expert guides written by bloggers. Some of these are a bit more beginner friendly than the oracle documentation, but mostly lack details pertaining to your own project.
http://javaoraclesoa.blogspot.com/2016/02/asynchronous-interaction-in-oracle-bpel.html
You can also just youtube some videos about BPEL to get the gest of it :).
Good luck and have fun!