理解できない状況-スクリプトを書く

スクリプトは、アプリケーションをより柔軟にする最も一般的な方法の1つであり、外出中に何かを修正する機能を備えています。 もちろん、このアプローチには欠点もあります;柔軟性と管理性のバランスを常に覚えておく必要があります。 しかし、この記事では、スクリプトを使用することの長所と短所について「一般的に」説明しません。このアプローチを実装する実用的な方法を検討し、Spring Frameworkで記述されたアプリケーションにスクリプトを追加するための便利なインフラストラクチャを提供するライブラリーを紹介します。

いくつかの紹介的な言葉

再コンパイルやその後の展開を行わずにアプリケーションのビジネスロジックを変更する機能を追加する場合、スクリプトは最初に頭に浮かぶ方法の1つです。 多くの場合、スクリプトは意図されているためではなく、発生したために表示されます。 たとえば、仕様には現在完全に明確ではないロジックの一部がありますが、分析に余分な数日（そしてより長く）を費やさないために、拡張ポイントを作成してスクリプト（スタブ）を呼び出すことができます。 そして、もちろん、要件が明らかになると、このスクリプトは書き直されます。

この方法は新しいものではなく、その長所と短所はよく知られています：柔軟性-実行中のアプリケーションのロジックを変更して再インストールの時間を節約できますが、一方で、スクリプトのテストはより困難であるため、セキュリティ、パフォーマンスなどの問題が発生する可能性があります

後で説明するこれらの手法は、アプリケーションで既にスクリプトを使用している開発者と、それについてのみ考えている開発者の両方に役立ちます。

個人的なものはなく、スクリプトだけ

JSR-233では、Javaでのスクリプト作成が非常に簡単になりました。 このAPIに基づいたスクリプトエンジンは十分にあるため（Nashorn、JRuby、Jythonなど）、コードに少しのスクリプトマジックを追加しても問題ありません。

Map<String, Object> parameters = createParametersMap(); ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine scriptEngine = manager.getEngineByName("groovy"); Object result = scriptEngine.eval(script.getScriptAsString("discount.groovy"), new SimpleBindings(parameters)); 

明らかに、そのようなコードがアプリケーション全体に散在している場合、それは理解できないものに変わります。 そしてもちろん、アプリケーションに複数のスクリプト呼び出しがある場合、それらを操作するために別個のクラスを作成する必要があります。 さらに進んで、通常の型指定されたJavaメソッドのevaluateGroovy()呼び出しをラップする特別なクラスを作成することもできます。 これらのメソッドは、例のようにまったく同じユーティリティコードを持ちます。

 public BigDecimal applyCustomerDiscount(Customer customer, BigDecimal orderAmount) { Map<String, Object> params = new HashMap<>(); params.put("cust", customer); params.put("amount", orderAmount); return (BigDecimal)scripting.evalGroovy(getScriptSrc("discount.groovy"), params); } 

このアプローチにより、アプリケーションコードからスクリプトを呼び出す際の透明性が大幅に向上します。スクリプトが受け入れるパラメーター、パラメーターのタイプ、返されるものをすぐに確認できます。 主なことは、型付けされたメソッドからではなく、スクリプトの呼び出しを禁止することを忘れずに、コード記述標準に追加することです！

スクリプトをポンプアップします

スクリプトが単純であるという事実にもかかわらず、多くのスクリプトがあり、それらを集中的に使用すると、パフォーマンスの問題が発生する可能性があります。 たとえば、多数のgroovyテンプレートを使用してレポートを生成し、それらを同時に実行する場合、遅かれ早かれこれはアプリケーションパフォーマンスのボトルネックの1つになります。
したがって、多くのフレームワークは、作業速度、キャッシュ、実行の監視、1つのアプリケーションでの異なるスクリプト言語の使用などを改善するために、標準APIにさまざまなアドオンを作成します。

たとえば、CUBAでは、次のような追加機能をサポートするかなり独創的なスクリプトエンジンが作成されました。

1. JavaおよびGroovyでスクリプトを作成する機能
2. スクリプトを再コンパイルしないためのクラスキャッシュ
3. エンジンを制御するJMXビン

もちろん、これはすべてパフォーマンスと使いやすさを改善しますが、低レベルエンジンは低レベルのままであり、スクリプトテキストを読み取り、パラメーターを渡し、スクリプトを実行するためにAPIを呼び出す必要があります。 したがって、開発をさらに効率的にするには、各プロジェクトで何らかのラッパーを実行する必要があります。

また、GraalVM-異なる言語（JVMと非JVM）でプログラムを実行でき、これらの言語のモジュールをJavaアプリケーションに挿入できる実験的なエンジンは言うまでもありません。 Nashornが遅かれ早かれ歴史に残ることを望み、1つのソースで異なる言語のコードの一部を書く機会が得られることを願っています。 しかし、これはただの夢です。

Spring Framework：断りがたい申し出？

Springには、JDK APIの上に構築された組み込みのスクリプト実行サポートがあります。 org.springframework.scripting.*パッケージには、多くの便利なクラスがあります-アプリケーションでスクリプトを作成するために低レベルAPIを便利に使用できるようにするためです。

さらに、より高いレベルのサポートがあります 。詳細については、 ドキュメントに記載されています 。 要するに、スクリプト言語（Groovyなど）でクラスを作成し、XML記述を介してBeanとして公開する必要があります。

 <lang:groovy id="messenger" script-source="classpath:Messenger.groovy"> <lang:property name="message" value="I Can Do The Frug" /> </lang:groovy> 

Beanが公開されると、IoCを使用してそのクラスに追加できます。 Springは、ファイル内のテキストを変更するときに自動スクリプト更新を提供し、メソッドなどにアスペクトを掛けることができます。

良さそうに見えますが、それらを公開するには「実際の」クラスを実行する必要があります。スクリプトで通常の関数を記述することはできません。 また、スクリプトはファイルシステムにのみ保存でき、Spring内に登る必要があるデータベースを使用できます。 はい。多くの人は、特にアプリケーションのすべての要素が注釈にある場合、XML構成は時代遅れであると考えています。 これはもちろん風味付けですが、しばしばそれを考慮しなければなりません。

スクリプト：難しさとアイデア

そのため、各ソリューションには独自の価格があり、Javaアプリケーションのスクリプトについて話すと、このテクノロジーを導入する際にいくつかの問題が発生する可能性があります。

1. 管理性。 多くの場合、スクリプト呼び出しはアプリケーション全体に散在しており、コードの変更により、必要なスクリプトの呼び出しを追跡することは非常に困難です。
2. ダイヤルピアを見つける機能。 特定のスクリプトで何か問題が発生した場合、ファイル名またはevaluateGroovy()などのメソッド呼び出しによる検索を適用しない限り、すべてのダイヤルevaluateGroovy()を見つけることが問題になります。
3. 透明性 スクリプトを書くこと自体は簡単な作業ではなく、このスクリプトを呼び出す人にとってはさらに困難です。 入力パラメーターの名前、パラメーターのデータの種類、実行の結果を覚えておく必要があります。 または、毎回スクリプトのソースコードを見てください。
4. テストと更新-アプリケーションコードの環境でスクリプトを常にテストできるとは限りません。「バトル」サーバーにスクリプトをアップロードした後でも、何か問題が発生した場合はすべてをすばやくロールバックできるようにする必要があります。

Javaメソッドでスクリプト呼び出しをラップすると、上記の問題のほとんどを解決できるようです。 そのようなクラスをIoCコンテナーで公開し、ユーティリティクラスからeval(“disc_10_cl.groovy”)を呼び出す代わりに、通常の意味のある名前でサービスのメソッドを呼び出すことができれば非常にeval(“disc_10_cl.groovy”)です。 もう1つの利点は、コードが自己文書化されることです。開発者は、特定のアルゴリズムがファイル名の後ろに隠されていることについて困惑する必要はありません。

さらに、各スクリプトが1つのメソッドのみに関連付けられる場合、IDEの「使用状況の検索」メニューを使用してアプリケーション内のすべてのダイヤルピアをすばやく見つけ、特定のビジネスロジックアルゴリズムごとのスクリプトの場所を理解できます。

テストは単純化されます-おなじみのフレームワーク、モックなどを使用した「通常の」クラステストになります。

上記のすべては、記事の冒頭で述べたアイデア、つまりスクリプトによって実装されるメソッドの「特別な」クラスと非常に一致しています。 しかし、開発者からスクリプトエンジンを呼び出すために同じステップのすべてのサービスコードを非表示にして、彼がそれについても考えないように（まあ、ほとんど）どうすればよいでしょうか？

スクリプトリポジトリ-コンセプト

アイデアは非常にシンプルで、Spring、特にSpring JPAを少なくとも一度は使用したことがある人には馴染みがあるはずです。 必要なのは、Javaインターフェイスを作成し、メソッドを呼び出すときにスクリプトを呼び出すことです。 ところで、JPAは同じアプローチを使用します。メソッド名とパラメーターに基づいてCrudRepositoryの呼び出しがインターセプトされ、リクエストが作成され、データベースエンジンによって実行されます。

コンセプトを実装するには何が必要ですか？

最初に、インターフェイスを見つけることができるようにクラスレベルの注釈-リポジトリとそれに基づいてビンを作成します。

また、メソッドの呼び出しに必要なメタデータを保存するために、このインターフェイスのメソッドの注釈がおそらく役立つでしょう。 たとえば、スクリプトテキストを取得する場所と使用するエンジン。

便利な追加機能は、インターフェイスの実装（デフォルト）でメソッドを使用する機能です。このコードは、ビジネスアナリストがアルゴリズムのより完全なバージョンを表示し、開発者が
この情報。 または、アナリストがスクリプトを記述し、開発者がそれをサーバーにコピーするだけです。 多くのオプションがあります:-)

そのため、オンラインストアの場合、ユーザープロファイルに基づいて割引を計算するサービスを作成する必要があるとします。 現時点ではこれを行う方法は明確ではありませんが、ビジネスアナリストはすべての登録ユーザーが10％の割引を受ける権利があることを誓い、1週間以内に顧客からの残りを確認します。 明日のサービスが必要です-結局のところ。 この場合、コードはどのように見えるでしょうか？

 @ScriptRepository public interface PricingRepository { @ScriptMethod default BigDecimal applyCustomerDiscount(Customer customer, BigDecimal orderAmount) { return orderAmount.multiply(new BigDecimal("0.9")); } } 

そして、アルゴリズム自体が到着し、たとえばgroovyで書かれた場合、割引はわずかに異なります：

 def age = 50 if ((Calendar.YEAR - customer.birthday.year) >= age) { return orderAmount.multiply(0.75) } else { return orderAmount.multiply(0.9) } 

このすべての目的は、 getEngine 、 evalなどのこれらのすべての呼び出しを台無しにするのではなく、インターフェイスコードとスクリプトコードのみを記述する機会を開発者に与えることです。 スクリプトを操作するためのライブラリは、すべての魔法を実行する必要があります-インターフェイスメソッドの呼び出しをインターセプトし、スクリプトテキストを取得し、パラメーター値を置換し、目的のスクリプトエンジンを取得し、スクリプトを実行（またはスクリプトテキストがない場合はデフォルトメソッドを呼び出し）して値を返します。 理想的には、すでに記述されているコードに加えて、プログラムには次のようなものが必要です。

 @Service public class CustomerServiceBean implements CustomerService { @Inject private PricingRepository pricingRepository; //Other injected beans here @Override public BigDecimal applyCustomerDiscount(Customer cust, BigDecimal orderAmnt) { if (customer.isRegistered()) { return pricingRepository.applyCustomerDiscount(cust, orderAmnt); } else { return orderAmnt; } //Other service methods here } 

課題は読みやすく、理解可能であり、それを実現するために特別なスキルは必要ありません。

これらは、スクリプトを操作するための小さなライブラリを作成するためのアイデアでした。 これはSpringアプリケーション向けであり、このフレームワークはライブラリの作成に使用されました。 さまざまなソースからスクリプトをダウンロードして実行するための拡張可能なAPIを提供します。これにより、スクリプトエンジンでの日常的な作業が隠されます。

仕組み

@ScriptRepositoryでマークされたすべてのインターフェイスについて、 ProxyクラスのnewProxyInstanceメソッドを使用して、Springコンテキストの初期化中にプロキシオブジェクトが作成されます。 これらのプロキシは、SpringのコンテキストでシングルトンBeanとして公開されるため、インターフェイスタイプでクラスフィールドを宣言し、 @Autowiredまたは@Injectアノテーションを付けることができます。 計画どおり。

スクリプトインターフェイスのスキャンと処理は、Spring、JPA、またはMongoDBのリポジトリがアクティブ化されるように、 @EnableSriptRepositoriesアノテーションを使用してアクティブ化されます（それぞれ@EnableJpaRepositoriesと@EnableMongoRepositories ）。 注釈パラメーターとして、スキャンするパッケージの名前で配列を指定する必要があります。

 @Configuration @EnableScriptRepositories(basePackages = {"com.example", "com.sample"}) public class CoreConfig { //More configuration here. } 

スクリプトを呼び出すためのメタデータを追加するには、 @ScriptMethodアノテーション（対応する特殊化された@GroovyScriptおよび@JavaScriptもあります）でメソッドをマークする必要があります。 もちろん、インターフェースのデフォルトのメソッドがサポートされています。

ライブラリの一般的な構造を図に示します。 青は開発が必要なコンポーネントを強調表示し、白は既にライブラリにあります。 Springアイコンは、Springコンテキストで使用可能なコンポーネントをマークします。


インターフェイスメソッド（実際には、プロキシオブジェクト）が呼び出されると、コールハンドラーが起動します。コールハンドラーは、アプリケーションコンテキストで2つのBeanを検索します。プロバイダーは、スクリプトテキストを検索し、エグゼキューターは、実際に見つかったテキストを実行します。 次に、ハンドラーは呼び出し元のメソッドに結果を返します。

プロバイダーおよびエグゼキュー@ScriptMethod名は@ScriptMethodアノテーションで指定され、 @ScriptMethodの実行時間に制限を設定することもできます。 以下にライブラリの使用コードのサンプルを示します。

 @ScriptRepository public interface PricingRepository { @ScriptMethod (providerBeanName = "resourceProvider", evaluatorBeanName = "groovyEvaluator", timeout = 100) default BigDecimal applyCustomerDiscount( @ScriptParam("cust") Customer customer, @ScriptParam("amount") BigDecimal orderAmount) { return orderAmount.multiply(new BigDecimal("0.9")); } } 

@ScriptParamアノテーションに注目して@ScriptParamコンパイラはソースから元の名前を消去するため、スクリプトに渡すときにパラメーター名を示すために必要です（これを行わないようにする方法がありますが、それに依存しない方が良いです）。 パラメーター名を指定する必要はないかもしれませんが、この場合、スクリプトで「arg0」、「arg1」を使用する必要がありますが、読みやすさはそれほど向上しません。

デフォルトでは、ライブラリには、ディスクから.groovyおよび.jsファイルを読み取るためのプロバイダーと、標準のJSR-233 APIのラッパーである対応するエグゼキューターがあります。 さまざまなスクリプトソースおよびさまざまなエンジン用に独自のBeanを作成できます。そのためには、対応するインターフェイスScriptProviderおよびSpringEvaluatorを実装する必要があります。 最初のインターフェースはorg.springframework.scripting.ScriptSourceし、2番目はorg.springframework.scripting.ScriptEvaluatorです。 Spring APIが使用されているため、既にアプリケーションに含まれている既製のクラスを使用できます。
プロバイダーとアーティストは、柔軟性を高めるために名前で検索されます。コンポーネントに同じ名前を付けることで、アプリケーションのライブラリの標準Beanを置き換えることができます。

テストとバージョン管理

スクリプトは頻繁かつ簡単に変更されるため、変更によって何も破壊されないようにする方法が必要です。 ライブラリはJUnitと互換性があり、リポジトリは単体テストまたは統合テストの一部として通常のクラスとして簡単にテストできます。 モックライブラリもサポートされています。ライブラリのテストでは、スクリプトリポジトリメソッドでモックを作成する方法の例を見つけることができます。

バージョン管理が必要な場合は、ファイルシステム、データベース、Gitなどからさまざまなバージョンのスクリプトを読み取るプロバイダーを作成できます。 そのため、メインサーバーで問題が発生した場合に、スクリプトの以前のバージョンへのロールバックを簡単に整理できます。

合計

提示されたライブラリは、Springアプリケーションのスクリプトを整理するのに役立ちます。

1. 開発者は、スクリプトに必要なパラメーターと返されるものに関する情報を常に持っています。 インターフェイスメソッドに意味のある名前が付けられている場合、スクリプトは何をしますか。
2. プロバイダーとエグゼキューターは、スクリプトを受信し、スクリプトエンジンと対話するためのコードを1か所に保持するのに役立ち、これらの呼び出しはアプリケーションコード全体に分散しません。
3. すべてのスクリプト呼び出しは、使用状況の検索を使用して簡単に見つけることができます。

Spring Bootの自動構成、単体テスト、mock'iをサポートします。 APIを使用して、「スクリプト」メソッドとそのパラメーターに関するデータを取得できます。 また、実行の結果を特別なScriptResultオブジェクトでラップすることもできます。スクリプトの呼び出し時にtry ... catchを使用したくない場合は、結果または例外インスタンスが存在します。 XML構成は、何らかの理由で必要な場合にサポートされます。 最後に、必要に応じて、スクリプトメソッドのタイムアウトを指定できます。

ライブラリのソース-ここ。