search

drewwills / Soffit

The underside of an arch or architrave
Apache License 2.0
7 stars 7 forks source link

Consider renaming #16

Open apetro opened 8 years ago

apetro commented 8 years ago

Soffit

Aesthetically, great name.

evocatively, though, I'm not seeing it.

n. the underside of an architectural structure such as an arch, a balcony, or overhanging eaves.

Whereas it seems to me that Soffit is one of those tubes that the Internet is a series of. It's WSRP, except with JSON and REST rather than XML and SOAP. It's a proxy, a client-server architecture, a remoting of the portlet. Soffit is less the underside of an architectural structure and more a tunnel.

Brainstorming alternative cute names:

drewwills commented 8 years ago

http://www.wordfind.com/ends-with/scope/

Some possibilities from there:

drewwills commented 8 years ago

http://www.wordfind.com/ends-with/pod/

cousquer commented 8 years ago

just my 0.2€

andrewstuart commented 8 years ago

Call me super boring (I can be creative I swear) but for something like this I'd heavily lean on a very obvious name, much like JSRP. That's the pattern adhered to by standards, and definitely adheres to portlet naming conventions (web proxy portlet, survey portlet, simple content portlet, etc.)

So something like:

I don't know. Realistically I think most of the names I cone up with are just semantically equivalent to "remote portlets" with maybe less of the capital-P "Portlet" stigma and some added shiny buzzwords. Ultimately, I think portlet and portal convey the use case of content aggregation. We're just extending the scope beyond the JVM/local host and distilling away some of the cruft that crept into the JSR spec.

So I think I'd ultimately throw my hat into one of the JSRP or "* Aggregation Protocol" rings. It's a little more evocative of the actual underlying ideas.

cousquer commented 8 years ago

@andrewstuart :+1:

drewwills commented 8 years ago

There's definitely something to be said for @andrewstuart's perspective above. I often argue against descriptive names, but the reason is that in the beginning of something (when a name is chosen) it can be hard to see enough about what the thing will turn out to be to choose well. The Java Architectures Special Interest Group (JA-SIG) is an example of how that approach can miss the mark.

But this thing isn't an org, a framework, or even an app. We are creating it for a purpose that is reasonably narrow, and with a mandate that is reasonably narrow. It's more reasonable to assume we see what this thing will become than it would be for other kinds of efforts.

What about JMAP: "JSON Microservice Aggregation Protocol?" (Can this tech reasonably be labeled a protocol?)

"Microservice" is a nice buzzard-compliant (holy crap autocorrect... that would be "buzzword-compliant") term for 2016. Also, I'm very interested in positioning/pitching uPortal as a "Microservices Architecture Aggregation Platform."

(Using completely different thinking) I'm also somewhat interested in @apetro's suggestion of "cephalopod." We could call the tech "cephalopod" but the things we build with the tech "pods," which has a reasonable ring.

andrewstuart commented 8 years ago

Now that I think about it too, "JSON" may also be a Bad Idea:tm:. There's lots of activity in the binary transport space (HTTP/2, protobuf, thrift, msgpack, etc.) since that significantly speeds up serialization while simultaneously optimizing transmission size.

We could go with JMAP and, in the event we decide binary is a good idea (which it is, IMO), just pivot and be cleverly recursive (as is somewhat popular): "JMAP Microservices Aggregation Protocol/Platform"

Funny too that you mention JASIG being an acronym -- I had no idea. Maybe a "descriptive name" is a moot point (though I do know what HTTP stands for). There's certainly precedent for starting with something creative to test the waters, with Google's SPDY becoming the foundation for HTTP/2.

Ultimately I'm fine with whatever. Cephalopod works fine too. Is Cthulhu taken? Since a portal is a bit heavier than a regular proxy?

apetro commented 8 years ago

I'm -1000 on "microservice" being in the name.

Soffit ain't microservices. That's not to say Soffit is bad or uninteresting, it's just to say that it's not the good and interesting thing that microservices are. :)

drewwills commented 8 years ago

It's not that using Soffit allows you to check Get 'dem microservices of your list and move on, it's that using uPortal with Soffit is microservices-friendly; if you have a plan/desire to implement a Microservices Architecture, uPortal with Soffit will align smoothly. That's really the message I'd like to bring to the market on this approach.

Looking at the summaries of Microservices Architecture I can find on the web, I'm having a difficult time finding any language that doesn't describe these components...

Microservices: a definition of this new architectural term (Martin Fowler)

http://martinfowler.com/articles/microservices.html

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

The Soffit approach offers:

Microservices (Wikipedia article)

https://en.wikipedia.org/wiki/Microservices

Like in SOA, services in a microservice architecture[1] are processes that communicate with each other over the network in order to fulfill a goal. Also, like in SOA, these services use technology agnostic protocols. [...] In contrast to SOA, microservices gives an answer to the question of how big a service should be and how they should communicate with each other. In a microservices architecture, services should be small and the protocols should be lightweight.

Here is is an example of the kind of service Soffit lends itself toward: https://github.com/drewwills/soffit-samples/blob/master/src/main/java/org/apereo/portal/soffits/rest/HealthCheckRestController.java#L41

It's...

It returns...

[
  {
    "url": "https:\/\/www.facebook.com\/",
    "title": "Facebook",
    "alive": true
  },
  {
    "url": "https:\/\/www.yahoo.com\/",
    "title": "Yahoo!",
    "alive": true
  },
  {
    "url": "http:\/\/localhost:8090\/not-a-real-url.wtf\/",
    "title": "Blackboard",
    "alive": false
  }
]
cousquer commented 8 years ago

I'm +1000 on "microservice" being in the name.

2016-07-21 0:44 GMT+02:00 Drew Wills notifications@github.com:

It's not that using Soffit allows you to check Get 'dem microservices of your list and move on, it's that using uPortal with Soffit is microservices-friendly; if you have a plan/desire to implement a Microservices Architecture, uPortal with Soffit will align smoothly. That's really the message I'd like to bring to the market on this approach.

Looking at the summaries of Microservices Architecture I can find on the web, I'm having a difficult time finding any language that doesn't describe these components... Microservices: a definition of this new architectural term (Martin Fowler)

http://martinfowler.com/articles/microservices.html

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

The Soffit approach offers:

  • Suite of small services
  • Running in own process
  • Communicating over lightweight, HTTP-based API
  • Independently deployable
  • May be written in different programming languages/frameworks

Microservices (Wikipedia article)

https://en.wikipedia.org/wiki/Microservices

Like in SOA, services in a microservice architecture[1] are processes that communicate with each other over the network in order to fulfill a goal. Also, like in SOA, these services use technology agnostic protocols. [...] In contrast to SOA, microservices gives an answer to the question of how big a service should be and how they should communicate with each other. In a microservices architecture, services should be small and the protocols should be lightweight.

Here is is an example of the kind of service Soffit lends itself toward: https://github.com/drewwills/soffit-samples/blob/master/src/main/java/org/apereo/portal/soffits/rest/HealthCheckRestController.java#L41

It's...

  • HTTP GET
  • application/json
  • small, lightweight

It returns...

[ { "url": "https:\/\/www.facebook.com\/", "title": "Facebook", "alive": true }, { "url": "https:\/\/www.yahoo.com\/", "title": "Yahoo!", "alive": true }, { "url": "http:\/\/localhost:8090\/not-a-real-url.wtf\/", "title": "Blackboard", "alive": false } ]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/drewwills/Soffit/issues/16#issuecomment-234106965, or mute the thread https://github.com/notifications/unsubscribe-auth/ABaa1k4VQ4obKUrS3G8zIap2eIrKy3qHks5qXqS-gaJpZM4JKvyk .