Skip to content

Commit a870464

Browse files
author
Andrew Lohr
committed
init
1 parent 0564453 commit a870464

File tree

602 files changed

+348595
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

602 files changed

+348595
-0
lines changed

.gitignore

+2
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
*.html
2+
.DS_STORE

.travis.yml

+31
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
language: generic
2+
branches:
3+
only:
4+
- develop
5+
6+
install: gem install travis --no-rdoc --no-ri
7+
script: >
8+
if [ ! -z $GITHUB_TRAVIS_TOKEN ]; then
9+
echo "Start requesting a travis build from upstream repository...";
10+
# Doesn't use --debug on `travis login`. --debug will show the github token
11+
travis login --skip-completion-check --org --github-token "$GITHUB_TRAVIS_TOKEN";
12+
export TRAVIS_ACCESS_TOKEN=`cat ~/.travis/config.yml | grep access_token | sed 's/ *access_token: *//'`;
13+
UPSTREAM_REPO_SLUG="OpenLiberty%2Fopenliberty.io"
14+
body='{
15+
"request": {
16+
"message": "Build request: OpenLiberty/docs",
17+
"branch": "multiPane"
18+
}}'
19+
curl -s -X POST \
20+
-H "Content-Type: application/json" \
21+
-H "Accept: application/json" \
22+
-H "Travis-API-Version: 3" \
23+
-H "Authorization: token $TRAVIS_ACCESS_TOKEN" \
24+
-d "$body" \
25+
https://api.travis-ci.org/repo/$UPSTREAM_REPO_SLUG/requests
26+
echo "SUCCESS: Completed request for travis build from upstream repository...";
27+
else
28+
echo "ERROR: Missing token. Cannot request a travis build for upstream repository...";
29+
fi
30+
31+
sudo: false # route your build to the container-based infrastructure for a faster build

concept/microprofile.adoc

+79
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
:page-layout: intro
2+
:page-description: Microservice architecture is a popular approach for building cloud-native applications in which each capability is developed as an independent service. It enables small, autonomous teams to develop, deploy, and scale their respective services independently.
3+
:page-categories: MicroProfile
4+
:page-permalink: /docs/intro/microprofile.html
5+
:seo-title: MicroProfile simplifies developing cloud-native Java microservices
6+
:seo-description: Microservice architecture is a popular approach for building cloud-native applications in which each capability is developed as an independent service. It enables small, autonomous teams to develop, deploy, and scale their respective services independently.
7+
= MicroProfile simplifies developing cloud-native Java microservices
8+
9+
Microservice architecture is a popular approach for building cloud-native applications in which each capability is developed as an independent service. It enables small, autonomous teams to develop, deploy, and scale their respective services independently.
10+
11+
https://microprofile.io/[Eclipse MicroProfile] is a modular set of technologies designed so that you can write cloud-native Java(TM) microservices. In this introduction, learn how MicroProfile helps you develop and manage cloud-native microservices. Then, follow the Open Liberty MicroProfile guides to gain hands-on experience with MicroProfile so that you can build microservices with Open Liberty.
12+
13+
== Rapidly deploy cloud-native Java microservices at scale
14+
15+
Cloud-native is an industry-wide approach to developing and rapidly deploying applications to the cloud at scale. Cloud-native applications are designed around team-aligned microservices and developed by using agile practices and continuous integration/continuous delivery (CI/CD) to streamline deployment. With a range of vendors providing cloud platforms, open source and open standards are essential enablers for avoiding vendor lock-in.
16+
17+
MicroProfile enables you to develop and deploy cloud-native Java applications as loosely-coupled, lightweight services, each representing one unique business function. This approach is modular and makes the application easy to understand, easy to develop, easy to test, and easy to maintain.
18+
19+
== Production benefits of a Microservice architecture
20+
21+
Writing code more quickly isn't the only reason that MicroProfile is popular. It also helps your applications scale on a more granular level because each service is built and managed independently. The high-traffic services can be individually scaled to efficiently use resources rather than scaling up the entire system. Another benefit is that failures in one service can be isolated from the rest of the system; if a service fails, services that are independent are unaffected while dependent services can employ fault tolerance strategies to prevent the failure from cascading to other services.
22+
23+
Although a microservice architecture provides many benefits, it also introduces new challenges not apparent in traditional monolithic applications. MicroProfile addresses these challenges so that you can easily develop cloud-native applications. These challenges include toleration of service failures, end-to-end security for an authenticated user request flowing through a set of microservices, and problem determination for requests spanning many services.
24+
25+
=== Developing RESTful, scalable, observable microservices: MicroProfile layers of functionality
26+
27+
MicroProfile can be organized into three layers of functionality. The bottom layer represents RESTful services, the middle layer is for writing microservices that can be operated and managed at scale, and the top layer contains tools to help you write observable microservices that enable you to detect and diagnose issues.
28+
29+
:!figure-caption:
30+
image::/docs/img/microprofile-layers.png[]
31+
32+
33+
// Bottom layer
34+
==== MicroProfile simplifies developing cloud-native Java microservices
35+
36+
The vast majority of cloud-native microservices are based on REST APIs, making the bottom layer the most essential. At its foundation, MicroProfile provides a set of technologies that make developing and using REST APIs easy. MicroProfile takes a small set of Java EE APIs: JAX-RS; CDI; JSON-B and JSON-P and augments them with a simple type-safe REST client API making it easy to consume REST services.
37+
38+
===== Build REST services
39+
The JAX-RS, CDI, JSON-B and JSON-P Java EE technologies provide the base for MicroProfile. If you're new to Java EE and MicroProfile, this is a good place to start. JAX-RS is a Java API that allows you to build REST APIs by creating resource classes and adding appropriate annotations to create the necessary web endpoints. Context and Dependency Injection (CDI) provides objects with the dependencies that they need through the `@Inject` annotation rather than directly creating an object or finding them using a factory. JSON-P and JSON-B makes it easy to automatically serialize and deserialize classes to and from JSON.
40+
41+
===== Consuming a REST service with type-safe Java
42+
MicroProfile Rest Client provides a type-safe approach for invoking REST services over HTTP. This API greatly simplifies the client-side API as defined by JAX-RS. MicroProfile Rest Client handles the communication between the client and service. You only need to define and annotate an interface that describes the actions that you need to perform on a REST resource. An implementation of this interface is automatically generated for you when CDI is used to inject your client into a dependent class.
43+
44+
45+
// Middle layer
46+
==== MicroProfile simplifies scaling your organization
47+
48+
Handling hundreds of autonomous, collaborating and frequently evolving services introduces a number of new challenges. These challenges include, for example, documenting and sharing APIs across teams, propagating security across services, handling network or service failures, and continuously integrating and deploying service updates. The middle layer of MicroProfile features provide a number of APIs to simplify these tasks.
49+
50+
===== Document your REST APIs
51+
MicroProfile OpenAPI provides a Java API for the OpenAPI specification that you can use to expose API documentation for your REST APIs. You can natively produce OpenAPI documents from your JAX-RS applications. OpenAPI is a standardization of https://swagger.io/blog/difference-between-swagger-and-openapi/[the Swagger specification].
52+
53+
===== Handle unexpected failures in your microservices
54+
MicroProfile Fault Tolerance provides an API and annotations for building robust behavior to cope with unexpected failures in the service you depend on. Aspects of fault tolerance include timeouts, retries, fallbacks, bulkhead processing, and circuit breakers.
55+
56+
===== Authentication and role-based access control
57+
MicroProfile JWT provides for interoperable authentication and role-based access control for your services. It allows for an authenticated JWT token to be shared across multiple microservices even if these services are running on multiple vendor implementations. It also allows for access to microservice operations to be controlled based on user and role information passed within the JWT token.
58+
59+
===== Externalize configuration to improve portability
60+
MicroProfile Config externalizes configuration from the application to improve portability of the application. A core principle is to be able to override configuration at deployment time using system properties and environment variables. This means you can build your microservice once and deploy it many times through your CI/CD pipeline by changing the configuration for each deployment.
61+
62+
// Top layer
63+
==== MicroProfile helps you write observable microservices
64+
65+
Handling hundreds of microservices requires a strong operations focus. If the system is beginning to exhibit problems, how do you track down the root cause when a request might span tens or hundreds of services? How can you tell which service is not performing well, or understand the journey a request took through those microservices? The top layer of the MicroProfile feature set helps you answer these questions. It provides APIs to help you understand the health of services, how they're performing, and how requests are flowing through them.
66+
67+
===== Determine a microservice's availability
68+
MicroProfile Health Check provides a common REST endpoint format to determine whether a microservice is healthy or not. Health can be determined by the service itself and might be based on the availability of necessary resources (for example, a database) and services. The service itself might be running but considered unhealthly if the things it requires for normal operation are unavailable. The Health Check endpoints are also designed to be easily integrated into Kubernetes liveness and readiness probes.
69+
70+
===== Monitor a microservice's telemetry data
71+
MicroProfile Metrics provides common REST endpoints for monitoring the telemetry data of a running microservice, similar in nature to JMX but a much simpler API that uses JAX-RS. Both built-in and application-defined metrics are accessible, with the output in either JSON or Prometheus text formats. This API provides more extensive detail than the simple up and down reporting provided by MicroProfile Health.
72+
73+
===== Enable distributed tracing of your microservices
74+
MicroProfile OpenTracing allows services to easily participate in a distributed tracing environment. OpenTracing defines behaviors and an API for accessing an http://opentracing.io/[OpenTracing]-compliant Tracer object within your microservice. These trace logs can then be consumed by a third-party distributed tracing facility such as https://zipkin.io/[Zipkin] or https://github.com/jaegertracing/jaeger[Jaeger].
75+
76+
== Where to next?
77+
78+
Now that you’ve seen the tools that MicroProfile provides for creating and managing microservices, you’re probably itching to try them out yourself! Check out the https://openliberty.io/guides/?search=MicroProfile&key=tag[MicroProfile guides] written by our team. Your next project will be ready to launch in no time!
79+

img/microprofile-layers.png

24.2 KB
Loading

img/microprofile-layers.pptx

41 KB
Binary file not shown.

ref/commands/server/README.md

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
# ol-supporting-docs

ref/commands/server/index_list.adoc

+34
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
////
2+
Copyright (c) 2018 IBM Corporation and others.
3+
Licensed under Creative Commons Attribution-NoDerivatives
4+
4.0 International (CC BY-ND 4.0)
5+
https://creativecommons.org/licenses/by-nd/4.0/
6+
Contributors:
7+
IBM Corporation
8+
////
9+
10+
== List of commands
11+
12+
* link:server-create.html[server create]
13+
* link:server-start.html[server start]
14+
* link:server-run.html[server run]
15+
* link:server-stop.html[server stop]
16+
* link:server-package.html[server package]
17+
* link:server-debug.html[server debug]
18+
* link:server-list.html[server list]
19+
* link:server-version.html[server version]
20+
* link:server-help.html[server help]
21+
* link:server-dump.html[server dump]
22+
* link:server-javadump.html[server javadump]
23+
* link:server-pause.html[server pause]
24+
* link:server-resume.html[server resume]
25+
26+
// NOTE: THIS PAGE IS TO EMULATE THE LIST OF ENTRIES IN THE NAVIGATION SIDE-BAR RATHER THAN A PAGE ITSELF. MAYBE BETTER ALPHABETICAL LISTING?
27+
28+
// NOTE: Needs something somewhere mentioning that you have to run as `./server create` etc if you're on Mac/Linux unless the `bin` directory is on the PATH(?). Because I bet this hits developers new to Open Liberty.
29+
30+
31+
== Some other reference topics
32+
33+
* link:server-xml.html[Server configuration file (server.xml)]
34+
* link:runnablejarfiles.html[Runnable JAR files]
+95
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
// INSTRUCTION: Please remove all comments that start INSTRUCTION prior to commit. Most comments should be removed, although not the copyright.
2+
// INSTRUCTION: The copyright statement must appear at the top of the file
3+
//
4+
// Copyright (c) 2018 IBM Corporation and others.
5+
// Licensed under Creative Commons Attribution-NoDerivatives
6+
// 4.0 International (CC BY-ND 4.0)
7+
// https://creativecommons.org/licenses/by-nd/4.0/
8+
//
9+
// Contributors:
10+
// IBM Corporation
11+
//
12+
:page-layout: server-command
13+
:page-type: reference
14+
= Runnable JAR files
15+
16+
// Pithy single sentence description of the command.
17+
Runnable JAR files contain applications, server configurations, and a Liberty installation.
18+
19+
// If relevant, more info.
20+
21+
== Usage
22+
23+
Run the JAR file by using the standard java command with the `-jar` option, for example:
24+
----
25+
java -jar package_file_name.jar
26+
----
27+
28+
When the JAR file runs, it gets extracted to a temporary location and then the server runs in the foreground, started by the Liberty server run command. All output is written to stdout or stderr. By default, files are extracted to temporary locations:
29+
30+
* For Windows: `%HOMEPATH%/wlpExtract/<jar file name>_nnnnnnnnnnnnnnnnnnn`
31+
* For all other platforms: `$HOME/wlpExtract/<jar file name>_nnnnnnnnnnnnnnnnnnn`
32+
33+
You can control the output location by using the `WLP_JAR_EXTRACT_ROOT` or `WLP_JAR_EXTRACT_DIR` environment variable (see [Environment variables]).
34+
35+
To stop the Liberty server press Ctrl-C. When the Liberty server stops, the extraction directory is automatically deleted. If you stop the active shell in any other way, the extraction directory is not cleaned up automatically, you must clean it up manually.
36+
37+
38+
=== Environment variables
39+
40+
[%header,cols=2*]
41+
|===
42+
|Environment variable name
43+
|Description
44+
45+
|WLP_JAR_EXTRACT_ROOT
46+
|Extracts JAR file to directory `${WLP_JAR_EXTRACT_ROOT}/<jar file name>_nnnnnnnnnnnnnnnnnnn`.
47+
48+
|WLP_JAR_EXTRACT_DIR
49+
|Extracts JAR file to directory `${WLP_JAR_EXTRACT_DIR}`.
50+
51+
|WLP_OUTPUT_DIR
52+
|Writes Liberty server output files to directory `${WLP_OUTPUT_DIR}`. By default, server output is written to the extraction directory, which is deleted when the server stops. If you want to save the output, specify a durable output location by using the `WLP_OUTPUT_DIR` environment variable before you start the server.
53+
54+
|WLP_JAR_DEBUG
55+
|Runs Liberty server by using `server debug <server name>` instead of `server run <server name>`. You can run the Liberty server in debug mode if you set the environment variable WLP_JAR_DEBUG before you start the server.
56+
57+
|WLP_JAR_ENABLE_2PC
58+
|Set to value `true` to enable two-phase-commit transactions when the runnable JAR file runs.
59+
60+
By default, two-phase commit commit transactions are disabled because the transaction logs are in the expansion directory and are deleted when the Liberty server is stopped. Therefore, transaction recovery is not possible.
61+
62+
To enable two-phase commit, configure the transaction log to be in a durable location in the file system or an RDBMS and set the `WLP_JAR_ENABLE_2PC` environment variable.
63+
64+
To configure the transaction log, use either the `transactionLogDirectory` or `dataSourceRef` attribute on the transaction element in your `server.xml` configuration.
65+
66+
|WLP_JAR_CYGWIN
67+
|Set to value true if you are running the JAR file under CYGWIN. This variable causes the Liberty server JAR runner to do UNIX-style file and process handling when it is running in the CYGWIN environment.
68+
69+
Run under the bash shell, not `mintty`.
70+
71+
Automatic extraction file deletion occurs only when you run under the bash shell. You can run under mintty, but you must delete the extraction files manually. Mintty does not forward the necessary signal that is required to trigger Java shutdown hooks.
72+
|===
73+
74+
75+
== See also
76+
77+
* link:server-package.html[server package]
78+
79+
80+
// Include server script exit codes
81+
include::server-exitcodes.adoc[]
82+
83+
84+
// Include description of server process
85+
include::server-serverprocess.adoc[]
86+
87+
88+
89+
//NOTE: Info taken from the following sources:
90+
91+
//* https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_admin_script.html
92+
//* https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_setup_package_server.html
93+
//* https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_setup_jarserver.html
94+
95+

0 commit comments

Comments
 (0)