ccs specs - Forum - OpenEdge General - Progress Community
 Forum

ccs specs

This question is not answered

Heard a rumour that the ccs specs are published. Now that the nda has been silently (!) dropped there's no restriction to publish and discuss them here now is there? ;-) In how far an eventual evolution to a micro services architecture (http://martinfowler.com/articles/microservices.html)  will be kept in mind?

  I would be happy with a small brms included. Not an interface to that expensive and vast corticon, just a small one written in abl. Easy integration possibilities with an os solution like http://openl-tablets.org/documentation/apologia would be nice. Furthermore dynamic catalog generation for datasets with more than one table. I could use that for batchmode insert of orders f.e. (so not first save an order and afterwards save orderlines one by one). Mailed this link before with a demo: http://eurekaaddons.co.uk/products/web-so-for-sage-200/   nice eh?

--
Kind regards,
 
Stefan Houtzager
 
Houtzager ICT consultancy & development
 
www.linkedin.com/in/stefanhoutzager
 
All Replies
  • If you are right the component specification group could have a look at microservices, if they did not evaluate that architecture already

    As noted, CCS has explicitly decided *NOT* to make any architectural recommendations.

    One imagines that, if they ever provided multi-threaded ABL sessions, they would simultaneously provide a light-weight communication protocol for ABL to ABL communications.  In the meantime, there are a number of non-ABL solutions which people use.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • > As noted, CCS has explicitly decided *NOT* to make any architectural recommendations.

    Ah! So the components will be usable in a microservices architecture!  ;-)

  • That is for you to determine!  It is possible the requirements of such an environment were not considered when specifying the interface, but then neither were other architectures.  One imagines that each contributor did a kind of mental scan relative to architectures they were familiar with and liked, but that was neither a formal part of the review process nor exhaustive.  Hence the review ... "what didn't we think of?"

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • LOL! So a seven-headed beast has almostly been born already!

  • Thomas is correct on the goals around CCS.

    It is specifying application interfaces and some aspects of application lifecycle. We want frameworks that support the CCS specifications to be able to distinguish themselves from each other on things like architecture, deployment models and companion tools.

    This intent is to allow application developers choice around frameworks and to not be locked in to a single framework.

  • >We want frameworks that support the CCS specifications to be able to distinguish themselves from each other on things >like architecture, deployment models and companion tools.

    As Thomas said architecture is implicit then. Would not have been my choice. Good luck with it, very democratic of you, but this does not give me any hope for opening up oe to the real world. But I had none, so no matter.

  • Not sure why it does not give you hope for "opening up to the read world". However, your best wishes are appreciated.

  • First that came to my mind when I wrote "opening up to the read world" is taking part in the microservices world. I see a great potential for this architecture. But I have afterthoughts also that have to do with the closed nature of psc (the nda's and bureaucracy surrounding this whole ccs project being a clear sign),  and psc with it's abundance of proprietary and expensive products that have at least in part a hard time competing with the opensource movement. At the base of my frustration stands my own position. I have explained that before but in case you did not read it:

     I'm a dutch contractor with openedge as main expertise. Over the years I have seen many companies leaving openedge in Holland, and none starting to use it. Nowadays most work is on legacy.  I don't feel like doing this the rest of my life.

     Furthermore concerning this ccs project: I would appreciate psc taking the position of thoughtleader, not thought follower. It's as with politics. I do not vote for weak leaders following the vox populi. This microservicestrend is already running a couple of years and seemingly no one writing in these groups has heard of it before (of course there are silent readers that have knowledge, Julian f.e. I suspect). In what bubble do you live? Psc should be the first here signaling and valuing the trends! It could have prepared the language and tools to be able to take part in the microservices world now, but it did not. 

  • Thank you very much for your candid comments.  I believe understand your perspective. 

  • I am skeptical regarding the claims made for microservices.

    In the past, we have had CORBA, DCOM, RMI, .Net remoting, OLE, DCE/RPC and a bunch of other distributed component architectures. None have been what I would call roaring successes.

    Having small bits of code that communicate via network messages is not an especially efficient way of doing things compared to function calls. And quite a bit more complex too. Proponents of such architectures always claim fewer dependencies, scalability, etc. Paraphrasing Leslie Lamport: A distributed system is one in which my application won't work because some machine I never heard of is down.

    Building secure, reliable, performant distributed systems is /hard/.

  • You have a point. Of course there are cons, see beside the links I sent highscalability.com/.../microservices-not-a-free-lunch.html. Regarding performance some benchmarks should provide insight.

  • Moreover it does not have to be an all or nothing decision. See via the former link ("not a free lunch") a reaction on the article:

    "Our approach in the end was to modularize the monolithic application (so we can share code repository, deployments, and code between modules - but still have nice, loosely coupled components) and pull out the modules into their own independent micro-services that can be deployed/managed independently only if really necessary."

    And f.e.:

    medium.com/.../a-false-choice-microservices-or-monoliths-484345baeef0

    http://blog.bettercloud.com/microservices-architecture/

  • > I am skeptical regarding the claims made for microservices.

    And I am skeptical about the survival of openedge. My observation in Holland is that it is dying a slow death.

  • The financial statements argue elsewise.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • You can have good financials and still be in trouble if you're not growing your base.