The «meta»-Interface concept is simply wonderful for port-based engineering in Java:

• It encourages clients to access services via service accessor Operations that provide service Interfaces via Ports.
• The service Interfaces group related Operations together nicely, and make for very efficient, robust, and easy programming.
• One can prompt on the service accessor Operations in IDE to discover the Interfaces effectively provided by a port-based Class.
• One can use the service accessor Operations to trigger creation methods for Ports:
  • these creation methods can exploit flexible techniques like:
    • on-the-fly (lazy) instantiation of Port implementors
    • fetching Port implementations from an injected PortFactory for maximum flexibility.

Sounds simply wonderful. Just one big problem:

The «meta»-Interface approach fails notationally in UML2 because
a UML2 Interface is not an EncapsulatedClassifier, so it can't show Ports !

In other words, if you type a part Property by a «meta»-Interface you completely lose nearly all the advantages of holons and port-based engineering NOTATIONALLY (only), in UML2. Again: there is no problem with the elegant «meta»-Interface concept for port-based engineering in Java, it is only a notational problem for UML2 -compliant tools. And yet the Interface does support attributes typed by Property, and a Port is a specialization of Property, so the «meta»-Interface strategy is tantalizingly close to working in UML2.

There is another possibility; use an abstract Class to declare the Port contract. However it turns out to be a problem for single-inheritance Java .. 

Image: