ccs specs

The CCS spec for the the proposed Community Draft of the Common Components Architecture Specification can be found here. Please check this out.

Thanks, can you resend the link? It does not work.

The tooltip is correct, the link isn't try this one community.progress.com/.../2698

Stefan, my understanding is they still wait for peoples that signed the NDA to agree to have it removed so not yet open party... the link gave by Carl gives 'access denied' welcome to everyone outside of the club I guess :(

Nope, rumours tell peoples (huh? hahaha) all approved. ;-) But it seems we'll have to give them some time to remove authorizations.

I'm glad to report that indeed the NDA has been removed and you all can now request to join the group. The registration process is rather simple and there is no more NDA. You'll only be asked to agree on the charter, contributor and release license agreements, and provide some additional information that will remain private. It shouldn't take you more than 3-5 minutes max to request to join the group.

If you'd like to review the charter and agreements, all these are available here under "Group Quick Links".

Only members of the CCS group have access to its content.

> Only members of the CCS group have access to its content.

Still a dark room session. Not my cup of tea.

shouldn't have to agree to the contributor agreement in order to /read/ specs.

hmm, finally took some time to fill in (most) off the required information to subscribe to this group (still pending registration)... still, found this on github although not much seems to be available there - http://progress.github.io/CCS/

Nice Gus! I dearly miss relatively independent voices like yours from inside progress. What is this? Fear to lose a ' position' ? What is that position worth then anyway, except some dull dollars for a ditto life? But anyway. It's too obvious to mention but: might it be that "outsiders" could have something valuable to say if the contents of what is offered is challenging and the trust exists ther is a responsive community? What are you afraid of that you do not just remove authorizations? I do no understand the point of keeping specs like these secret. Is there an nda or not?

I was the person who asked the questions, so I am the person who verifies if the answer is ... verified. So I removed the "question answered"  Jean. But the initial mail contained not only a question but also things to discuss. Please do not try to close the discussion too hasty Jean. ;-)

Available for consumption/use. Not discussion. That's quite poor and not a very clever idea I find. A  group without nda but closed, for which I have to sign agreements to view contents, does not attract me at all. 

Ok, but i still don't like the way this is proposed. I would like to decide for myself if and how i would like to participate. And if i attend or not attend meetings etc.

As just a member of the CCS community there is no obligation to attend any meetings. That's only expected once you volunteer to join a spec team.

> That's what the CCS community is intended for.

> Yes, we can do a better job of describing these steps/process . And yes, the NDA was a burden (as was the signup

> process). But hopefully it's now as easy to sign up as it was for these general communities.

"You'll only be asked to agree on the charter, contributor and release license agreements, and provide some additional information that will remain private." (Jean)

I just don't like / trust this. I did not have to go throught it to sign up for general communities. Moreover without being subscribed to a couple of groups I can still read messages (and decide if  I'm interested to join discussions etc).

Having clicked through and read the charter and contributor agreement I can confirm that, so far, there is currently no NDA.

There were 18 or 20 ridiculous qualifying questions that seem designed to wear down and discourage potential participants but I persevered and filled them out to the best of my rather limited ability to put up with that sort of nonsense.

Now I get to wait "up to 10 days" to see if I am approved.  It is a very popular project so not everyone can be accepted.

The contributor agreement does seem useful as it ensures that submitted material is unencumbered by secret patents etc.

Removing the NDA is definitely good.  Kudos for that!

That's good information.  I definitely got the wrong idea from reading the charter.

I am puzzled why the process isn't generally more open.  The charter says:

Progress is dedicated to providing an open platform for the exchange of ideas and, ultimately, the agreement of specifications for each component.

Locking something called "community" behind a closed forum in an already login limited site doesn't seem very "open" to me.

I'm not sure what a "community draft" is.  That term isn't defined in the charter.  There is a 30 to 90 day participant only review period for "community review drafts".  After another two weeks of finalization approved specs are supposed to be released to the "broader OpenEdge community".  So I think we must be waiting for something in one of those phases?

FWIW -- I also do not see the benefit of keeping review drafts in hiding.  A "public comment period" is a very useful thing in a specifications process.  It would be a pity to put months of work into something and then release it to find out that it has problems that could have been solved if a few more people had looked it over and commented on it.

Tom, you are a member now.

"It would be a pity to put months of work into something and then release it to find out that it has problems that could have been solved if a few more people had looked it over and commented on it".

Tom,  I believe this is why they are asking peeps to sign up not only for the community but also to consider signing up to participate on the committee teams; to get more people involved to not only vet the spec but become engaged with providing content.

Tom, I am not a lawyer. And I am glad I am not.

Challenge from a legal perspective is, that you own the intellectual property in your comments. So part of joining the community is accepting the contributor license agreement - so that it's clear to everybody that if your comment becomes part of the (modified) specification everybody knows that you have accepted to release your IP under the CCS terms.

> And yes, the NDA was a burden (as was the signup process). But hopefully it's now as easy to sign up as it was for these general communities.

The signup is still a PITA.  Way over the top.

Awesome :)

You definitely met the 10 day SLA :)

I am equally glad of my "not a lawyer" status.

None the less I find it curious that others can do these things successfully without all of this rigamarole.  

I am encouraged that Progress has finally started to see the light on pointless NDAs.  I will try to remain optimistic that it is but the first step towards whole-heartedly embracing an open community.

I don't trust this excuse for dark room sessions at all. And I'm very very sure this is not the best way to benefit from what is the potential in this community. That might be more than expected by some drs members. But that's implicit to 'potentials'  isn't it.

Marian, that was the case, but is so no longer. Everybody who previously signed the NDA has now agreed to waive it. People can participate in the community without the requirement of a Non Disclosure agreement.

We are working on eliminating the number of items you must supply when signing up for the process. We have heard that from a number of sources.

People have asked for read access even if you haven't taken the steps to sign up for the community. Well to allow read access to the world, we had to eliminate the NDA first didn't we :-).

Now that we have removed the NDA we can consider it.

We do use the term Community Review Draft in the charter document. However, you are correct it is not formally defined. We should correct that in a future revision the Charter Document.

Let me see if I can clarify where we are with this specification:

The Architecture Specification is now in the "Community Review Period". This means that the specification submitted by the spec. team has been reviewed by the steering committee to ensure it meets the goals of the Specification Proposal and has been "approved" to go through a review period by the entire community.

The group is not closed you are welcome to join. We have reduced the burden of joining by removing the NDA and will continue to seek ways to lower the effort required to join.

Hi Stefan

Can you possibly elaborate on your reservations for joining CCS?

Sunil.

For me there are questions I don't actually have an answer to.

Any specific question, James?

Hi Sunil,

What is not clear? I don't like to repeat myself, but I would just like things to be really open, so that everyone can take notice of what is done and give input. I think f.e. Tom Bascom has the same mindset, maybe he can make it clear personally to you? Really, it is not that difficult. ;-)

Stefan.

Not to put words in James' mouth but I suspect he is referring to the 20 or so mandatory questions regrading things like his company's total revenue etc.

My impression of James is that he is a stickler for following rules.  When a form says that something is mandatory he takes it a bit more seriously than some people might.

Removing the NDA is an excellent step forward.  I heartily endorse that.  Thank-you!

The 20 or so mandatory questions to get registered remain an imposing barrier to easy participation.  I managed to stick with it and get through them but not everyone will be so flexible.

Thanks Tom . We are working on eliminating some of the mandatory questions on registrations to make the process simpler.

Stefan - To review or contribute to CCS, you would need to sign-up to CCS. At this point, the read and contribute roles aren't different (with different contracts) and it is all part of single CCS agreement. Thanks for your input.

I'm in a bit of a unique position at the moment being between jobs. I can't truthfully answer questions about my employer etc. But to be honest I'm not sure I want to give that detailed information about my employer either. Not sure either for old or the new would be too happy with that information when I'm joining the group for personal reasons. If that makes sense.

[quote user="ChUIMonster"]

Not to put words in James' mouth but I suspect he is referring to the 20 or so mandatory questions regrading things like his company's total revenue etc.

My impression of James is that he is a stickler for following rules.  When a form says that something is mandatory he takes it a bit more seriously than some people might.

[/quote]

Thanks Tom - explained perfectly! :)

I've said that at the last pug challenge event and although haven't got kick off the room the long list of silly questions remained there after that NDA removal, one would thought reducing or even removing that sales/marketing information retrieval form should have been easier than lifting the NDA :)

That made me stop couple of time before but then went away and as Tom said fill in the form the best I've could, must admit gibberish over used, still that got myself in so you should relax your rules and give it a try.

On the other hand making it difficult to join goes against attracting community involvement in the first place, you should probably try to send in-person invites to some of the known community contributors out there... after all you're inviting peoples to join an effort on pro-bono basis ;)

Thanks Marian. I'll try and fill in as much as I can :)

Would be good to take broad view stories like www.richardrodger.com/monolithic-nodejs into account while writing specs.

"Our current approaches, from waterfall to agile, serve simply to enable monolithic systems. They enable us to build bigger and add more complexity. Even unit testing is an enabler. You thought unit testing was the good guy? It’s not. If you do it properly, it just lets you build bigger, not smarter." And a lot more. This is a readable, entertaining story.

It's about node.js: "the good parts" also (but misses a critical part). And on the microservices I named in the message starting this thread..

As bonus read http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ on microservices, and http://mmikowski.github.io/json-pure/ on restful api's.

  Moreover I hope you leave agile bullshit out (see above + this bonus https://www.youtube.com/watch?v=nvks70PD0Rs  :-). 

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Thanks for your feedback Stefan. Interesting posts and videos. What methodology is used to the develop the specs. is left up to the specification teams. Nothing mandates Agile.

> What methodology is used to the develop the specs. is left up to the specification teams. Nothing mandates Agile.

That's good, no scrum imposed. Not my business anyway of course. ;-)

Stefan,

you should join the group if you want to see for yourself but at first sight the CCS is about going further with OERA by defining interfaces for components/services with the aim to have those being interchangeable between different vendors/providers (might well be open-source implementations as well). Wether or not those services will leave inside the monolith or be independent micro-services is an implementation detail - for instance session management service can well use the same application database to store session information or use a memcache/redis external system.

However, a big part of the picture is appsrv and imho the design of it lately goes more toward monolithic approach (multiple apps/webapps deployed on one PAS), this is opposed to what we try to do with akera.io but then again you don't like node.js so not very interesting for you :)

However, I did like the 'death is expected and natural' phrase in your first article...

> However, I did like the 'death is expected and natural' phrase in your first article...

?? Meaning escapes me.

meaning we often try to build software that never breaks but somehow it still does eventually, maybe a better approach will be just acknowledge the fact that it will break and design it so it can restart (automatically) when it does.

by a strange coincidence this is the exact philosophy we use on our application server... every components there might fail, if set-up with redundancy another cell will take over while the one that died reborn ;)

Ok. My microservices question is rhetoric I confess, I doubt abl is fit for them. I think functional laguages are ideal for them (see the links already sent). Microservices, devops and continuous delivery are an interesting rage. nofluffjuststuff.com/.../session

is there any difference between using devops with continuous delivery and your developers doing their development on the production sytem ???

For me the most important first question is if standups and post-it walls or other nonsense are required. (for the rest I'm not informed enough to give a quick reply ;-).

No, if you take the name literally.  But as with anything real in this universe, continuous is a misnomer.  What they mean is that the quanta are small.  (Quanta is also a misnomer, as it implies indivisibility.  Each step still contains development, testing, and release.)

Technical details about microservices, clear language:

www.nginx.com/.../

"In a monolithic application, components invoke one another via language-level method or function calls. In contrast, a microservices-based application is a distributed system running on multiple machines. Each service instance is typically a process."

  How to implement this in openedge? Each service in a appserv or other .exe? Maybe distributed across multiple machines?  What are the communiction possibilities (see the nginx article) and how efficient would they be compared to what is available in other languages? 

  Don't have the time to expand a bit more, maybe a next time.

I expected silence after my previous mail with the question how to implement microservices in openedge. I would call the phenomenon the elephant in the standup: "A lot of agile teams deal with what’s been called the elephant in the standup. A situation arises that no one really wants to talk about. 'We need a technical sprint’, a 'refactoring sprint’ or similar concerns are voiced. What’s really happening at that point in time is the software is starting to creak under the weight of change and assumptions.

The longer we ignore the elephant, the bigger it gets and the more it slows us down. Instead of keep on pushing that elephant, the technical debt, around it’s time to fix the root cause! I know I certainly have been at the point with a team where we ended up taking more and more time to implement features."

  kmile.nl/.../simplicity-in-software-with-russ-miles-at-skills

> I expected silence after my previous mail with the question how to implement microservices in openedge

You recently said your question was rethorical. That usually means it is not really a question, so what is there to answer...?

(Even so, this thread doesn't seem particularly silent to me.)

The answers circumvent the questions about (the eventual evolution to) a microservices architecture. Of  course you can leave the elephant in the standup where it is. I doubt that is a smart decision.

It is misleading to suggest that it is impossible (or even difficult) to implement a micro services architecture using ABL. It is misleading to suggest that someone starting from s V6 style legacy architecture cannot overlay a micro services architecture.  

> The answers circumvent the questions about (the eventual evolution to) a microservices architecture.

You are likewise circumventing my observation that rhetorical questions are not meant to be answered...

Anyway, what changes would you like to see to make microservices possible? What do you think is missing now?

First things missing that catched my eye are realtime messaging possibilities between f.e. appserver exe processes. See the nginx link I sent for what microservices are and how they could communicate. Thinking it all out would be quite a task.

Moreover I don't know wherefore an appserver would be needed in a microservices architecture.

moreover, i don't know where a microservices architecture would be needed. what is it for?

Internet is full of arguments, if you're interested just google. Moreover, I sent some links that already explained some things. Did you digest those?

Counter question: what is the appserver needed for, Gus? I just googled a bit after some simple logical thought, that lead to "what is this appserver good for anyway". You know me. I read in one of the first hits "app servers are fading away in the move from monolithic middleware to microservices and cloud services" (www.jamesward.com/.../). Moreover "appservers are dead" etc. That's of course bad practice, googling to get my good rights, I should look for the opposite. So I thought let's ask Gus. Be my enemy, please, my virtual friend. ;-)  I'm not the smartest but I can google, lets say. :-)

I liked what I read in the nginx link, no wordiness there, here's one introducing microservices: https://www.nginx.com/blog/introduction-to-microservices/ .

  Another quick google result, sorry to bother you with so much letters but I think some of them make sense: "Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade."  (http://blog.xebia.com/the-end-of-common-off-the-shelf-software/)

You want to hear it in my own words? See if I learned my lesson? :-)

The Microservices Architecture pattern has a number of important benefits. First, it tackles the problem of complexity. It decomposes what would otherwise be a monstrous monolithic application into a set of services. While the total amount of functionality is unchanged, the application has been broken up into manageable chunks or services. Each service has a well-defined boundary in the form of an RPC- or message-driven API. The Microservices Architecture pattern enforces a level of modularity that in practice is extremely difficult to achieve with a monolithic code base. Consequently, individual services are much faster to develop, and much easier to understand and maintain.

Second, this architecture enables each service to be developed independently by a team that is focused on that service. The developers are free to choose whatever technologies make sense, provided that the service honors the API contract. Of course, most organizations would want to avoid complete anarchy and limit technology options. However, this freedom means that developers are no longer obligated to use the possibly obsolete technologies that existed at the start of a new project. When writing a new service, they have the option of using current technology. Moreover, since services are relatively small it becomes feasible to rewrite an old service using current technology.

Third, the Microservices Architecture pattern enables each microservice to be deployed independently. Developers never need to coordinate the deployment of changes that are local to their service. These kinds of changes can be deployed as soon as they have been tested. The UI team can, for example, perform A|B testing and rapidly iterate on UI changes. The Microservices Architecture pattern makes continuous deployment possible.

Finally, the Microservices Architecture pattern enables each service to be scaled independently. You can deploy just the number of instances of each service that satisfy its capacity and availability constraints. Moreover, you can use the hardware that best matches a service’s resource requirements. For example, you can deploy a CPU-intensive image processing service on EC2 Compute Optimized instances and deploy an in-memory database service on EC2 Memory-optimized instances.

Now did I learn my lesson or not? :-)

From what I've read so far in those NGINX articles (Which isn't all of it, have to leave that as a new year's resolution...), it looks like the architectural changes in the Pacific AppServer for OpenEdge (11.6)  take a few big steps towards enabling the micro-services pattern.

Every individual service can now be it's own self-contained ABL Web App, which can be distributed as needed/desired (see also: documentation.progress.com/.../index.html for the technical details on that).

And there's nothing that stops the code from one Web App to make requests to another.

How big or how small each service becomes is then left up to the developer.

I'd say that if you want to transition from a monolithic classic appserver towards microservices, you'll want to start by grouping together your different entry points by what functionality they provide, and then start splitting off those groups into their own service.

(In theory, you can do something similar with the classic appserver as well by using the often-overlooked AppserviceList functionality. But then you end up with a lot of extra work to avoid collisions between the different services running under the same brokers.)

Stefan, I think you are missing two things here.  One of them is fine because it is just a aversion for some things and a passion for others ... but not always remembering the context.  Some of the stuff you write about is perfectly interesting in and of itself, but not necessarily relevant in the context of building enterprise class business applications.  Of course, sometimes it is relevant, but just new words for something that has actually been around for a long time.  I readily agree that the ABL community needs to think about architecture a lot more than it does, but I think this should be grounded in where we are and what we have available now, what we can do with that, where we would like to go from here, and what we need to do that.

The local thing that you are missing is that the CCS effort explicitly excluded architecture from its mandate beyond defining interfaces for the components, which one has to do to have specified anything.  I wish that were not the case since I think that improving the architecture of our legacy systems is one of our most important challenges, but it is the choice they made.  So, really, there is no architecture here to argue about, only pieces.  One can imagine how those pieces are likely to be used in real systems, but really, that is up to the person using them.  So, really the only architectural criticism which is appropriate is to say that one would like to use a component in a particular way, but the current definition of that component presents an obstacle to that use.

The world is flat and on the borders monsters live (aka the elephant in the standup). When will the soapbubble burst? Did it burst already?

Dreaming of bright newyear, best wishes!

> First things missing that catched my eye are realtime messaging possibilities between f.e. appserver exe processes

I'm not sure why that would be so hard to implement using ABL. There are various ways to communicate i ABL. Many of the links you provided talk about keeping the communication simple, and just use any means available. However, I'm no expert on what would be most efficient or easy to do in ABL (if anything), so it would be interesting to see others make suggestions. (Someone mentioned PacificAppserver? But I would think other solutions for internal communication might be possible too.)

And I guess, providing some new bult-in mechanism in ABL specificially designed for even easier communication between processes could be a good idea for improvement. I guess that until now, using many separate ABL processes has not been so common, but being able (and encouraged) to do that more easily could open up new possibilities.

> Moreover I don't know wherefore an appserver would be needed in a microservices architecture.

One link you provided that differs somewhat from the others in an interesting way is the one to "Elixir", based on the Erlang Virtual Machine. Most of the other links talk about each microservice being run as a separate operating system process. In Elixir, they in stead have their own concept of a "process" being a lightweight thread being handled with the Erlang VM, with many may such threads probably within the same Erlang VM within one operating system process. (Although certainly there are mechanism for distributing the execution between different VMs and different machines too.) Also the programming model of Erlang itself is based on such small threads communicating internally within every single program, and probably also within each microservice, not just between microservices.

Several of the links you provided, which talk about microservices as separate processes, mentioned that it would be useful to have tooling for monitoring and controlling all the microservices, because otherwise you will soon have a big unmanagable mess of microservices with no control. Most of them seemed to rely on each microservice implementing their own monitoring, and how they are controlled wasn't really discussed much at all. Some mention using Docker, but I would guess that is only part of the solution. It seems to me, this part of using microservices may perhaps still be evolving, and hasn't settled. (Or maybe that is discussed somewhere else?) Anyway, it would seem that it would be useful to have a framework for managing microservices, if you are going to be running a large system with many microservces. And it would be useful not having to reinvent such a framework every time you need it.

In Elixir, apparently they already have a tool, apparently named "iex", for watching and analyzing and keeping track of all their fine-grained threads, simplifying this work (or at least parts of it).

Maybe something like the AppServer (or broker or something) could also evolve into providing support for this? Helping to keep track of separate microservices, in whatever way they are incarnated.

Also, as you see from Elixir, all microservice implementations might perhaps not need to revolve around using separate processes, although I do notice some advantages of having separate processes, as mentioned in your links. The essential part seems to be the ability to deploy, run and update each microservice separatly and independantly and easily, whether run as a separate process or as a separate thread as in Elixir, or some other way.

(Maybe it would be possible for AppServer and other technologies to evolve to become better at that, as a start? I'm not sure exactly what could be done, but maybe others know more?)

- Going back again to the question of communication between microservices, I also noticed some similarity between some suggestions for message passing mechanisms and the the ABL PUBLISH/SUBSCRIBE mechanism for sending and receiving events. Many of your links of course mention sending messages between microservices using HTTP, JSON, XML, and so on. But these are just mechanisms and message formats. Clearly, the only relevant thing is having some practical mechanism for getting the messages across and finding the right recipient. Various open source low-overhead message passing packages were mentioned too, when communicating with internal services within the same enterprise and not external third-party services. And one basic useful model mentioned was to be able to just publish messages about events that are happening, and having other interested microservices subscribing to the events they are interested to process. This makes it very extensible for adding more services for the same events. This sounds to me very much like PUBLISH/SUBSCRIBE in ABL, except that if microservices are run as separate processes, it would be nice to have this extended to work also between different processes. But if some microservices would be executed with in the same AVM process, like threads in the same VM in Elixir, then perhaps this could be used already to start designing programs in a more microservices-like manner. (Anyone else want to elaborate on this possibility?)

I must confess that I don't know much of pas. If you are right the component specification group could have a look at microservices, if they did not evaluate that architecture already. Thanks beforehand for all those quick replies to the question in my first email then!  :-(. Concerning the communication with the appserver agent I had a problem in the past (classic appserver), I could not contact idle sessions. Is this problem gone? The communcation was said to be impossible because of how the agent was built. Exerpts from community.progress.com/.../1674

"a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker

b) Running a remote AppServer procedure n-number of times in an attempt to cycle through all the 'idle' agents will almost certainly not produce consistent results"

"With regards to 'idle', an AppServer agent works very differently from an ABL client or WebSpeed agent.  An AppServer agent is not actively running any ABL procedure when in an idle state; it is actually sitting in an 'C' code idle loop outside of the ABL language interpreter.  So no, the agent is not idling in a 'wait-for' where it can be interrupted, timeout, or handle asynchronous [i/o] operations.  The agent re-enters the language engine when a client's remote procedure request arrives, exists the language interpreter when the remote procedure has completed, and then waits in its idle loop until the next remote procedure or broker operation is received."

>> First things missing that catched my eye are realtime messaging possibilities between f.e.

>> appserver exe processes

I commented:

> I'm not sure why that would be so hard to implement using ABL. There are various ways to communicate i ABL.

Maybe we are making things more complicated than they need to be. Why not just run one AppServer for each "microservice", and let them connect to and call each other using remote RUN in ABL?

After all an AppServer is just an AVM ready to receive calls from other processes. And they can be located on the same machine or other machines on the network; it doesn't matter. The calls don't necessarily have to go through HTTP, unless you really need that. And you can run as many instances of each one as you need. And each one can have its own database, if that is what you want for a microservice. Each one can be started, stopped, deployed, updated and so on whenever you want, separate from each others.

Just resist the urge to put your whole application in the same AppServer, that's all...

>>> First things missing that catched my eye are realtime messaging possibilities between f.e. appserver exe processes

> I commented:

>> I'm not sure why that would be so hard to implement using ABL. There are various ways to communicate i ABL.

----------------------------------------------------------------------------------------------------

You commented that, but I have had a problem in the past with idle appserver agents (classical appserver). See prev. email with comments from Michael Jacobs (psc).

> Why not just run one AppServer for each "microservice", and let them connect to and call each other using remote

> RUN in ABL?

----------------------------------------------------------------------------------------------------

See www.nginx.com/.../.

Beforehand you should take into account that the services might be replaced with non-abl services. You would want a communication protocol that is (as much as possible) language agnostic, and performs well. It could be that your call is an event that has listeners subscribed. Etc, see the nginx link. This has been thought over by others already of course.

> but I have had a problem in the past with idle appserver agents

I don't understand how that would be a general problem for microservices?

> I don't understand how that would be a general problem for microservices?

I was talking about a communication problem between two abl sessions that existed with the classic appserver.

blog.xebia.com/.../

"Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade. If you can scale your application by starting a new process on a fresh VM you don’t need complex software to share resources. That means you don’t really need a lot of infrastructure. You can deploy small components with negligible overhead. Key-value data stores allow you to relax constraints on data that where imposed by relational databases. A service might support two versions of an interface at the same time."

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.

> 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?"

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.

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

Come on Thomas, don't trust on our blindness. We got to make a living. Are you sponsored by psc or so?

Point being that new OpenEdge licenses are still being sold and are growing.

Any new Partners or ISVs being signed up?

Sold to the garbagehauler? Don't make me laugh.

www.youtube.com/watch

Looks like a nice presentation from 2015 about some trends. Take advantage of this psc.

This is what the speaker has to say about agile: https://www.youtube.com/watch?v=tIxHmsWCd7g.

Dave Thomas, who was one of the writers of the agile manifesto in an interview:

"What's wrong with current programming is something that almost everyone recognizes and most people hope will go away: Moore's Law still applies and for that to have happened, we find that the architectures of our machines have changed dramatically. So, we're looking at multicore, hyperthreading, off-loading processing on to GPUs, and so on. My laptop has a billion transistors in it, which is incredible. And no one can keep a billion transistors busy if they're doing sequential coding. You have to partition the work and do multiple pieces at the same time. And our tools for doing that at the moment are remarkably primitive. They're based on evolving old models. It's like we're saying we got here with object orientation and now we have to make it work concurrently — just slap a few more primitives in and hope. The reality is that doesn't work that well. Clearly, it works, but it takes a lot of effort and it's error-prone."

www.drdobbs.com/.../240166688

Read the whole interview, it's worth your time.

FWIW, in 1967 I was programming in Tranquil, an Algol-like language which had two levels.  It was developed for the Illiac IV, the first massively parallel computer (which did not physically exist at that point).  IlliacIV had four quadrants, each with a master control processor and 64 slave processors.  Tranquil addressed both levels.  One could start and stop the individual processors in response to data and move data between them.

However, programming in Tranquil was very hard!

I'm working myself through a Dave Thomas tutorial for elixir 1.2. Using elixir/erlang in a docker container. If you're interested here's an intro: media.pragprog.com/.../introduction.pdf. Elixir is not as hard to start working in as f.e. haskell. Times have changed since your tranquil + never too late to teach a dog a new trick eh Thomas? Whatever / anyway.  I will be learning the elixir phoenix web framework (https://www.youtube.com/watch?v=WIyXz2wxnJQ) lateron. "Elixir allows for massive scalability without the headaches of callbacks" (goodbye node.js!) www.reddit.com/.../

Communication between elixir processes is fast btw (google yourself for that). I think Dave Thomas is right: "Elixir is the next killer language. The future has to be functional, immutable data, and it has to be concurrent. It's the only way to grow. And very few of our current languages let us do that."

chapter 14 (concurrent programming) of Dave Thomas' tutorial (much enjoying the course) starts with:

"One of Elixir’s key features is the idea of packaging code into small chunks that can be run independently and concurrently. If you’ve come from a conventional programming language, this may worry you. Concurrent programming is “known” to be difficult, and there’s a performance penalty to pay when you create lots of processes. Elixir doesn’t have these issues, thanks to the architecture of the Erlang VM on which it runs. [..]

And each process can contain its own state - in a way, processes in Elixir are like objects in an object-oriented system (but they have a better sense of humor)."