Consider renaming

[apetro]

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:

• kaleidoscope : a tube with two ends that transforms in the passing from one end to another, like Soffit somewhat transforms.
• viaduct
• telekinesis
• telepathy
• jsrp (JSON services for remote portlets)
• cephalopod (a nod to squid, which is also a proxy)
• ...

[drewwills]

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

Some possibilities from there:

• Telescope
• Periscope

[drewwills]

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

[cousquer]

• "keystone"

  in french : clef de voûte
  Personally, I liked the concept of arch behind the term "soffit" and the architectural concept behind it. uPortal built one (or more) arch over one (or many) IT systems.
  Maybe it is also because I am a big fan of Ken Follett: The Pillars of the Earth.
  and within "keystone", there is the term "key", with all the work of @drewwills and @andrewstuart around securing and JWT...

just my 0.2€

[andrewstuart]

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:

• JSRP +1 (JSR* could be confusing, though)
• JSON Content Aggregation Protocol (JCAP)
• Microservice Aggregation Protocol (MAP/MIP?)
• Web Content Aggregation Protocol
• Web Services Aggregation Architecture
• Dashboard Content Aggregation Modules (DashCAM) (90% j/k, but I had to throw in something creative)

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]

@andrewstuart 👍

[drewwills]

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]

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]

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]

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
  }
]

[cousquer]

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

2016-07-21 0:44 GMT+02:00 Drew Wills [email protected]:

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
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABaa1k4VQ4obKUrS3G8zIap2eIrKy3qHks5qXqS-gaJpZM4JKvyk
.