Building Extensible Composite Applications with SAP - inscope.net

Building Extensible Composite Applications with SAP®

Contents Introduction .....................................................................................................

1

Design Principles of Modern Java Applications ......................... 17 1.1

1.2

2

Application Architecture and Design ............................................... 1.1.1 Application Layering .......................................................... 1.1.2 , exclude=false) public ExportResult exportBusinessPartner(@WebParam(name= ð "BusinessPartner") BusinessPartner bp) { // default to standard implementation ExportService exService = null; ExportRequest exRequest = new ExportRequest(); exRequest.setObject(bp); try { exService = getExportService(); return exService.export(exRequest); } catch (Exception ex) { // in real life, we would need more sophisticated error handling ;) return null; } } Listing 3.3 Method “exportBusinessPartner()”

To complete our source code walkthrough, let’s look more closely at the getExportService method within the BusinessPartnerExportServiceBean (see Listing 3.4).

64

Creating the Example Application

protected ExportService getExportService() throws Exception { final String JNDI_NAME_APPLICATION_CONFIGURATION = ð "ApplicationConfiguration"; ExportService retVal = null; ApplicationPropertiesAccess propAccess = null; String classname = null; InitialContext ctx = new InitialContext(); propAccess = (ApplicationPropertiesAccess) ð ctx.lookup(JNDI_NAME_APPLICATION_CONFIGURATION); classname = propAccess.getApplicationProperties().ð getProperty(BP_EXPORT_SRV_CLASSNAME_KEY, null); if (classname == null) { // return default impl return new BusinessPartnerTXTExportServiceProvider(); } else { // create an instance of the specified export service Class clazz = Class.forName(classname); retVal = (ExportService) clazz.newInstance(); } return retVal; } Listing 3.4 Method “getExportService()”

The getExportService method uses JNDI to look up a reference to the ApplicationPropertiesAccess functionality that ships with SAP NetWeaver CE. In a nutshell, this is a service that allows providing properties (e.g., type-safe key-value pairs) for an application, which can be administrated via a designated view of the SAP NetWeaver Administrator without the need to restart the application. Within that application configuration file (sap.application.global.properties contained in the META-INF directory of the [EXT_TECH1] ext_tech1\app DC), a constant key has been defined (bp.export.class) that may point to the full-qualified classname of an ExportService implementation to be used for business partners (see Listing 3.5). Because the ExportService implementations are mere JavaBeans with a no-argument constructor, they can simply be instantiated by using the clazz.newInstance() method.

65

3.2

3

Extensibility Based on Java Class Loading

## Full-qualified Classname of the BP export service to be used #% type = STRING #? secure = false; onlinemodifiable = true bp.export.class = com.sap.demo.ext_tech1.model.export.provider.ð BusinessPartnerTXTExportServiceProvider Listing 3.5 File “sap.application.global.properties”

3.2.6

Specifying Dependencies Between Development Components

Before we can actually build and deploy the application, there is one remaining step that needs to be done: setting the dependencies between the DCs. In Section 3.2.3, Creating the Public Parts, we have defined the public parts (PP) of our DCs; now it’s time to define which component uses which PPs. 1. Switch to the Development Infrastructure perspective. 2. In the Component Explorer, highlight the [EXT_TECH1] ext_tech1\services DC, and then select the Dependencies tab in the Component Properties tab on the right side of the screen. 3. As you can see, there have already been two dependencies defined: engine. jee5.facade and tc/je/webservices/api, which are required for the standard functionalities of EJBs (see Figure 3.21).

Figure 3.21 Required DCs

4. Because the EJB uses both the ExportService interface and the model classes, it obviously needs to have access to these entities contained in the “compilation” PP. Furthermore, the services DC uses the application configuration functionality (ApplicationPropertiesAccess), so a dependency to the corresponding DC is required as well. Click on the Add button next to the list of required DCs. A pop-up window is displayed (see Figure 3.22).

66

Creating the Example Application

Figure 3.22 Adding Dependencies

5. Select tc/je/appconfiguration/api DC from the ENGFACADE [sap.com] SC, and select the ext_tech1/model DC from the EXT_TECH1 [demo.sap.com] SC. Click Next. 6. The concrete definition of which PPs should be defined as a dependency takes place in the next wizard step. We need only the build time dependencies on the PPs with purpose Compilation. Select Assembly PP and remove the Build Time dependency because it is not required (see Figure 3.23). Note that the enterprise application DCs are in charge of assembling the required DCs, which is defined in the next steps. Confirm the changes by clicking on Finish. The result should look as shown in Figure 3.24. 7. To complete the dependency definitions, maintain the rest as specified in Table 3.4. In principle, you now define the packaging of the two DCs (model and services) into their corresponding deployment unit (the enterprise application).

67

3.2

3

Extensibility Based on Java Class Loading

Figure 3.23 Specifying the Required Public Parts

Figure 3.24 Result Required DCs

DC Name

Required DC

Public Part

ext_tech1/app

ext_tech1/services

ejbjar

ext_tech1/app

ext_tech1/model_app

N/A

ext_tech1/model_app

ext_tech1/model

Assembly

Table 3.4 Required Dependencies

8. It is essential that you add the ext_tech1/model_app dependency to ext_ tech1/app to have access to the model objects assembled by ext_tech1/ model_app. Because we have not defined any PPs for ext_tech1/model_app, simply add the whole DC, and select the Runtime dependency details to ensure that the class loader of the ext_tech1/app enterprise application can access the required model classes. A complete overview of the DCs and their dependencies is illustrated in Figure 3.25.

68

Creating the Example Application

[demo.sap.com] EXT_TECH1

ext_tech1/model_app

assembly

compilation

ext_tech1/model

ext_tech1/app

ejbjar

client

ext_tech1/services

Figure 3.25 Development Components Overview

9. It should now be possible to build and deploy the application by highlighting the EXT_TECH1 SC from the Component Browser and selecting the Build Contained Local DCs option (see Figure 3.26).

Figure 3.26 Option “Build Contained Local DCs”

10. If the build was successful, you can deploy the two enterprise applications to the server (see Figure 3.27).

69

3.2

3

Extensibility Based on Java Class Loading

Figure 3.27 Deploying the Enterprise Applications

3.2.7

Testing the Application via the Web Services Navigator

To test the application, the Web Services Navigator (WS Navigator) can be used: 1. Start your browser, and open the start page of SAP NetWeaver CE (e.g., http:// :). Click on the Web Services Navigator symbol on the right side. (You could also use the direct link: http://:/wsnavigator). 2. On the first page of the wizard, you can search for the service interface you want to test by a variety of search types. Select the second option Provider System. The Provider System drop-down box is defaulted to the Local Java AS (application server), hence we leave it untouched. Enter “*Export*” into the Search For text entry field, and click Search. The BusinessPartnerExportServiceBean should be listed in the result set (see Figure 3.28). Click Next. 3. Select the exportBusinessPartner operation, and click Next. 4. Uncheck the Skip check box next to BusinessPartner to proceed with the input of parameters for the WS Navigator call. 5. Type in some contact encoding="UTF-8"?> ext_tech1/model_app cust_ext_tech1/cust_app

ð

Listing 3.6 File “application-j2ee-engine.xml”

Using Local Projects Instead of Development Components In a real-world scenario, when using the complete SAP NetWeaver Development Infrastructure (NWDI), you need to change the development configuration to be able to create a new SC. That may be considered unnecessary overhead or over-engineered if just a small implementation is required. In such cases, it is perfectly valid to simply create regular projects to develop the custom implementation. Because you cannot define DC dependencies, you need to set application references as shown in Listing 3.6. Note that, by default, the provider name for applications that have been created as standard projects (and not DCs) is “sap.com”.

75

3.3

3

Extensibility Based on Java Class Loading

After you have added the weak reference, deploy all of the enterprise applications from both the [EXT_TECH1] and [CUST_EXT_TECH1] SC to the server. Figure 3.35 illustrates all of the DCs and their dependencies. Take a moment to become familiar with the illustration so that you completely understand the dependencies between all of the DCs. [demo.sap.com] EXT_TECH1

ext_tech1/model_app

assembly

compilation

ext_tech1/model

[foo.net] CUST_EXT_TECH1

cust_ext_tech1/cust_app

assembly

compilation

cust_ext_tech1/export

ext_tech1/app >

ejbjar

client

ext_tech1/services >

Figure 3.35 Development Components Overview

There is yet another important aspect that you may have been wondering about already: Why did we use two enterprise applications instead of just one to assemble both model classes and EJBs? To answer this question, we need to elaborate once more about the dependencies between the custom application and the original applications. Let’s imagine for a moment that both the model DC and the EJB module DC would be assembled by a single enterprise application. Obviously, the customer application would be required to define a dependency to the original application because it needs to implement the ExportService interface defined in the model DC. However, at the same time, a weak dependency would be required from the original application to the custom application to load the custom implementation at runtime. This is called a cyclic dependency (shown in Figure 3.36) and is not allowed by SAP’s Component Model because it cannot be resolved.

76

Creating the Custom Implementation

[demo.sap.com] EXT_TECH1

ext_tech1/app

assembly

compilation

ext_tech1/model

Cyclic [foo.net] CUST_EXT_TECH1a dependency

cust_ext_tech1/cust_app

assembly

compilation

cust_ext_tech1/export

ejbjar client ext_tech1/services >

Figure 3.36 Cyclic Dependency

Anticipated Custom Implementation versus Modifications This chapter is intentionally structured so that the permissions to unrestricted access were not set in the beginning, but are left to be done during the setup of the custom SC. We did this because it may be easier to understand the purpose of these permission settings when stumbling across this issue. Obviously, if you create an application with such an extensibility concept in mind, you must set the permission before shipping the application. Strictly speaking, changing the permissions of a SC from an external vendor is a modification. The same logic applies to the application reference. Setting this application reference after shipment is a modification and hence should be done as a last resort only if no extensibility concept was anticipated in the original application design. If you create an application with extensibility in mind (using the technique described in this chapter), it makes sense to define a dedicated SC name to be used by customers/partners and ship the application with a corresponding application reference entry. You should define a naming convention for such SCs that clearly indicates their extensibility purpose.

3.3.2

Reviewing the Custom Implementation

Let’s take a quick look at the customer implementation provided. From a componentization point of view, we have simply created another Java DC with the name cust_ext_tech1/export and an enterprise application DC called cust_ext_tech1/ cust_app to assemble the Java DC. The customer implementation of the ExportService interface resides in the package net.foo.cust_ext_tech1.export, and

77

3.3

3

Extensibility Based on Java Class Loading

the classname is BPvCardExportServiceProvider. The coding is very similar to Listing 3.1, except that instead of simply invoking the toString() operation of the BuinessPartner class, a special method called getBusinessPartnervCardString() is in charge of returning the BusinessPartner string in vCard markup code (see Listing 3.7). /** * @see com.sap.demo.ext_tech1.model.export.ExportService */ public ExportResult export(ExportRequest request) throws ExportException { ExportResult retVal = new ExportResult(); Serializable obj = request.getObject(); if (obj instanceof BusinessPartner) { String encoding="UTF-8"?> EXT_TECH2 foo.net~ext_tech2~composite~web.war ext_tech2 Listing 4.6 Meta, type=ExtensionPointType.AROUND, interfaceName="....ManageBusinessð PartnerInExtensionPointsLocal", operationNames={"beforeSaveBusinessPartner", "afterSaveBusinessPartner"}) public BusinessPartnerStructure createBusinessPartner( BusinessPartnerStructure businessPartner) throws CAFCreateException, CAFServiceException Listing 6.2 Annotated Service Operation

The use of annotations as shown in Listing 6.2 binds the extension point to the EJB. Let us have a closer look on this custom annotation next.

6.1.2

ExtensionSpot Annotation

Listing 6.3 shows the source code of the ExtensionSpot annotation (with some of the JavaDoc omitted for readability purposes). Via the standard annotations (@Target, @Documented, and @Retention), the annotation itself was defined to be applied on the method level and that the annotation should be retained for runtime (and not be discarded during the build process). This may sound trivial but

147

6.1

6

Introducing an Extensibility Framework

is essential; otherwise, the extension point information provided would not be available during the execution of the application. @Target(ElementType.METHOD) @Documented @Retention(RetentionPolicy.RUNTIME) public @interface ExtensionSpot { ExtensionPointType type() defaultð ExtensionPointType.SUBSTITUTE; String name() default ""; String interfaceName() default ""; String[] operationNames() default ""; } Listing 6.3 “ExtensionSpot” Annotation Source Code

2. Let’s now take a closer look at the four attributes the ExtensionSpot annotation exposes: 왘

Name A unique name (with a common prefix) for the extension used for documentation and configuration purposes. Typically, it is also used to obtain the JNDI name(s) of the extension point implementation(s).

왘

Extension Type The extensibility framework supports four different types of extensions: 왘

Substitution The original service operation is completely replaced by a custom implementation. Note that if the custom implementation is inherited from the standard implementation, it is capable of calling the super implementation at any point of the processing logic as required. As such, it is arguably the most versatile type because it can mimic the behavior of the other types.

왘

Pre-processing An extension point of this type is executed prior to the execution of the intercepted service operation and can be used to alter or verify the request before any further processing takes place.

왘

Post-processing This type of extension point allows altering the encoding="UTF-8"?> * ð com.sap.demo.ext_framework.ExtensionPointInterceptor Listing 6.9 EJB Interceptor Binding via “ejb-jar.xml”

So far, the executed steps are all inline with the ones we sketched out at the beginning of this section. The next couple of steps, however, slightly differ due to the fact that we replace an existing extensibility mechanism instead of just implementing it anew.

159

6.2

6

Introducing an Extensibility Framework

1. Navigate to the sap.application.global.properties file located in the METAINF folder of the ext_tech2/composite/ear DC. Here we need to replace the key used to look-up the JNDI name(s) of the extension point implementation(s). The former extensibility mechanism used the fully qualified key of the extension point local interface as the key, while the newly introduced framework uses the name of the extension point as the logical key. The modified file should look as shown in Listing 6.10. ## Full-qualified Classname of theð ManageBusinessPartnerInExtensionPoints implementation to be used #% type = STRING #? secure = false; onlinemodifiable = true ExtensionPoint.ManageBusinessPartnerIn =ð demo.sap.com/ext_tech2~composite~ear/LOCAL/ð ManageBusinessPartnerInExtensionPointsð /com.sap.demo.ext_tech2.composite.modeled.ð appsrv.managebusinesspartnerin.ext.ð ManageBusinessPartnerInExtensionPointsLocal Listing 6.10 Updated Extensibility Configuration Settings

2. Change the service operation itself by removing the explicit invocation calls within the coding and replacing it with the ExtensionSpot annotation (as shown in Listing 6.11). For your convenience, we have included the corresponding method header again here. @ExtensionSpot(name="ExtensionPoint.ManageBusinessPartner", type=ExtensionPointType.AROUND, interfaceName="....ManageBusinessð PartnerInExtensionPointsLocal", operationNames={"beforeSaveBusinessPartner", "afterSaveBusinessPartner"}) public BusinessPartnerStructure createBusinessPartner(ð BusinessPartnerStructure businessPartner) throws CAFCreateException, CAFServiceException

ð

Listing 6.11 Annotated Service Operation

There is one last step needed before we can deploy the application and see the framework in action. Unfortunately, the extension point interface defined and used in Chapter 4, Extensibility Based on Enterprise JavaBeans, does not adhere

160

Implementing the Extensibility Framework

to the requirements of the extensibility framework. This issue clearly demonstrates the challenges one faces when trying to incorporate the extensibility framework into applications in a post-development approach. Several potential conflict-resolutions scenarios exist; which one is the best-suited solution greatly depends on the individual use-case (usage scenario, stage of the application’s lifecycle, etc.): 1. Change the previously defined extension point interface and implementations to match the requirements. This option is the most simple and recommended approach, especially if the application is still in development. I cannot stress enough the importance of embracing the design pattern of dedicated request/ response objects, so if the introduction of an extensibility framework reveals that this is not the case, the better. It may be perceived as additional refactoring effort at first, but from experience, I can say that this always pays off in the long run. 2. Extend the previously defined extension point interfaces or create entirely new interfaces within a new development component, change the implementations and extension point configurations to match the new interfaces, and adjust the DC dependencies. This strategy only requires a few modifications and can be considered a clean surgical intervention. 3. Using the SUBSTITUTE type instead of using pre-processing and post-processing hooks, it would be possible to mimic the other extension point types without facing any method signature limitations. However, you would then need to modify the extension points so that they inherit the to-be-replaced service. While this results in a modification at the right place (the extension point implementation), this is only possible if the service implementations can be accessed and referenced (they need to be exposed as a PPs of the component). If this is not the case, the component containing the service implementations would need to be modified to expose the implementations (which may violate security constraints or other aspects). 4. Enhance the extensibility framework to be less restrictive in regards to requirements for interface method signatures. Obviously, that requires some effort to develop, test, and maintain such a framework. Depending on the exact requirements of a particular use-case scenario, this may be a valid approach or the last option. All resolution strategies listed here may be considered as modifications (in varying levels of magnitude) in scenarios where the original service provider differs

161

6.2

6

Introducing an Extensibility Framework

from the extensibility framework implementer or when the application is already used productively. In the scenario at hand, we will take the first approach and quickly change the extension point signature to match the requirements. The reasoning behind this decision is that we simply take it for granted that this design decision (replacing the explicit extension point invocation calls with an extensibility framework) has been made during an early stage of development and consequently qualifies to be a refactoring activity and not a modification. Getting back to implementing the extensibility framework, the last step required to complete the integration is to adjust the signature of the post-processing extension point, which now looks like Figure 6.7.

Figure 6.7 New Post-Processing Method Signature

The new signature looks a little awkward at first glance, which is more credited to a lazily designed service interface. In this case, the interface of the service operation used the same structure (BusinessPartnerStructure) for both request and response objects, which may not be considered a best practice. As you recall, especially the service comprising the new functionality of an application (its API) should be modeled adhering to the design principles of Enterprise Services. In such a case, the request and response objects are completely distinct structures (e.g., the response should always include a Log). We made this mistake on purpose to emphasize one last time how important such design patterns are. I’m sure you are eager to finally see the result. If you simply read along without applying the necessary changes in parallel, you may now import the final SCAs (EXT_TECH2-0_4.sca, CUST_EXT_TECH2-0_2.sca and EXT-FRMWRK-0_1.sca) of this chapter and deploy the EARs to your server.

6.3

Testing and Debugging the Extended Application

As done many times during the course of this book, you could use two approaches to quickly test the application: via the WS Navigator or the CAF Ser-

162

Summary

vice Browser tool. These activities must be second nature to you by now, so we won’t elaborate the necessary steps here. Instead, we encourage you to launch the application in debug mode and debug your way through the extensibility framework and the extension points to get a thorough understanding of its working. You may also want to try to change the extension point implementation and replace the standard implementation with the custom implementation we developed in Chapter 4, Extensibility Based on Enterprise JavaBeans. You just need to change the application properties file to point to the JNDI-name (foo.net/ ext_tech2~composite~app/LOCAL/MailManager/com.sap.demo.ext_tech2.composite .modeled.appsrv.managebusinesspartnerin.ext.ManageBusinessPartnerInExtensionPointsLocal) of the MailManagerBean within the NWA.

6.4

Summary

To wrap up what we have learned in this and the previous chapters, we want to make a few statements about the road ahead. As stated several times, the usecases and usage scenarios for extensibility mechanisms are close to infinite and make it difficult to make any general recommendations. Which technology or extensibility approach is best suited greatly depends on the context of the intended usage or the requirements of a particular scenario. We provided you with the technical information and background required to make well-educated decisions on a case-by-case basis. The last chapter will provide you with a bit more information aimed to assist you in such decision making. Before we conclude this chapter, we feel obligated to point out again that the presented framework has been developed for educational purposes and is not intended for productive usage as is. We illustrated the general concept and workings of an extensibility framework, which should empower you to build your own framework based on the learned material.

163

6.4

The final chapter provides an overview of covered extensibility techniques and summarizes their individual strengths and weaknesses. Furthermore, the chapter provides a rough guideline concerning when to choose which approach and the reasoning it takes to make such decisions. We wrap up what we have learned by looking at a comparison matrix.

7

Summary

Now that we have reached the mountaintop, we can take the time to enjoy the view, look back at the trail that brought us here, and reflect on what we have learned along the way. We started by looking at application design and emphasizing the importance of proper application layering and componentization to ensure that an application can be characterized as being extensible. We continued by learning the essential concepts of extensibility techniques in general and listed common concerns that need to be addressed by the extensibility mechanism. With that background knowledge in mind, we started our venture into the realm of extensibility techniques and how to apply them with various technologies ranging from standard Java class loading capabilities, to dynamic EJB invocation, and up to Web service calls. In the preceding chapter, you learned how such a framework could be created and incorporated into newly developed or existing applications. Before we part, I want to provide you with insight needed to answer the question of which concept may be best suited for a particular scenario based on real experiences. Of course, I can only provide you with fairly generalized recommendations or solutions that proved successful in certain scenarios. As such, I can only document the reasoning that lead to the answer to such questions; it is up to you to adapt the underlying analytical way of thinking.

165

7

Summary

7.1

Extensibility Based on Java Class Loading

Leveraging the potential of the Java Reflection API and dynamic class loading capabilities this technique is very versatile because it induces only minor prerequisites that need to be granted. The key concept behind it is the loose coupling between components, which is achieved by the strict separation of interface and implementation. As this can be regarded as one of the most essential best practices in object-oriented programming, chances are high that these requirements are given in most applications. The use-cases are many, however, due to its lightweight nature, the approach of leveraging dynamic classloading is typically used to provide some sort of plug-in functionality (e.g., export and import functionality). The other prerequisite is that the original software provider has modeled the individual components as shown in Figure 7.1. The interfaces of the extension points (Service Def.) and all of the referenced data types and structures (Model) need to be encapsulated into separate DCs. The standard implementation of these extension points may reside in the same DC as the service implementation, yet it defines a dependency to the DCs that contain the service definition and data model.

WD/VC

Service Façades Java EE Appl. DC

Java EE Appl. DC

Service Impl.

Service Impl.

Service Def.

Model

Java EE Appl. DC

Hard reference Weak reference

Figure 7.1 Required Componentization for Extensibility Based on Java Class Loading

166

Extensibility Based on EJBs

The OSP ultimately declares a predefined name of a weakly referenced DC that the implementers of an extension point need to create their implementations in. This is important to ensure that the custom implementation can be located by the class loader(s) available to the original application. The original application declares a weak reference to this predefined development component and treats it as an optional component that may be existent or not. This concept is comparable to the approach taken for Java extensions (javax.*) because it ultimately reserves a namespace to be used for the provisioning of extensions. If the OSP did not adhere to these requirements, the component model need to be evaluated to see if it can be modified accordingly and how much effort that would take (including the continuous maintenance effort caused by this modification). Remember that the separation of interface and implementation, which results in the introduction of separate DCs, is also required to avoid cyclic dependencies between the service interfaces and the custom extension points. To summarize the characteristics of these techniques, it may be best to call it the Swiss knife of extensibility concepts because it is really simple to incorporate into new applications. Compared to the other techniques, the approach of using dynamic Classloading is definitely the one with the smallest footprint in both complexity and performance overhead.

7.2

Extensibility Based on EJBs

The beauty and charm of extensibility techniques based on EJBs is the tight integration of the underlying component model (EJB 3.0) and its natural support of the application server. The latest version of the EJB specification is a blessing and greatly simplified the former heavyweight component model. The new additions to the API such as dependency injection, interceptors, and annotations are powerful techniques that help to improve both quality and productivity. Most of the heavy lifting required for extensibility techniques is already natively provided by the EJB container such as looking up and binding the interface of a service to its implementation at runtime given the JNDI name of the implementation, which makes the definition of a dedicated extension namespace (required in scenarios based on Java class loading) obsolete (see Figure 7.2).

167

7.2

7

Summary

As looking up and binding the implementation is delegated to the EJB container, the performance overhead is neglectable, especially when using local interfaces only. As mentioned already, Java-based applications developed on a Java 5 Enterprise Edition application server typically use EJBs to encapsulate the business logic. So it makes perfect sense to use the same technology as the foundation for extensions to avoid two separate programming models.

WD/VC

Service Façades Java EE Appl. DC

Java EE Appl. DC

EJB Service

EJB Service Impl

Hard reference Weak reference

Figure 7.2 Required Componentization for Extensibility Based on EJBs

7.3

Extensibility Based on Web Services

As we examined at various occasions, system landscapes typically consist of heterogeneous systems and applications. In scenarios that require interaction across multiple systems, the need for a common communication protocol becomes inescapable. Web services standards have emerged to be this universal language and has established themselves as de facto standards in enterprise integration scenarios. Due to wide acceptance and support by most programming languages, Web services standards can be regarded as the least common denominator in the area of cross-system communication.

168

Extensibility Based on Web Services

As shown in Figure 7.3, the interface used to define the technical contract between the service and the implementation is the WSDL file. During runtime, the Web service is called using either a defined binding port or a dynamically-injected endpoint URL. The concept usually resembles the SUBSTITUTE extension type we discussed in Chapter 6, Introducing an Extensibility Framework, and is typically used to delegate the processing of a specific set of functionality to an external system. While it is indisputably the most universal approach, this technique bears a significant performance impact (caused by the marshaling/unmarshaling from/into XML in addition to the overhead of HTTP).

WD/VC

Service Façades Java EE Appl. DC

WS

WSDL

Java EE Appl. DC

WS

Hard reference Weak reference

Figure 7.3 Required Componentization for Extensibility Based on Web Services

The most common scenario for an extensibility concept is that the original software provider defines a Web service interface that exposes the semantic contract of a service (operation), which can be implemented by external service providers (e.g., an ATP-check). As such, the concrete backend system has been abstracted, and the solution can easily be adapted to interact with a completely different bakkend system by simply changing the configured endpoint (to point to an alternative implementation). Because such scenarios are the native breeding grounds for composites, such an extensibility technique comes in handy in a lot of use-cases (e.g., backend abstraction layer).

169

7.3

7

Summary

7.4

Implicit Extensibility Based on Interceptors

The existence of a generic and reusable extensibility framework that allows for both implicit and explicit extensions as an inherent characteristic/aspect of applications greatly helps to keep solutions flexible and supportability efforts low. Consequently, all software providers are best advised to incorporate such extensibility techniques into their standard products and projects. The detailed insight into the individual components in such a framework, which we gained in the last chapter, enables you to build your own extensibility concept according to your individual use-case(s). In general, using interceptors as the technical enabler of implicit extensibility bears tremendous potential because it allows keeping all of the technical details (and the resulting complexity) separated from the actual source code (see Figure 7.4). We have also learned that such a framework can easily be incorporated into existing applications with minimal effort and necessary modifications.

WD/VC

ejb-jar.xml Service Façades Java EE Appl. DC



EJB Service

* Interceptor

EJB Service Impl.



Interceptors

Hard reference Weak reference

Figure 7.4 Componentization for Implicit Extensibility Based on Interceptors

For software vendors that either develop standard applications or frequently implement custom solutions, developing such a reusable extensibility framework may be considered a worthy investment (especially in the long run).

170

Comparison

7.5

7.5

Comparison

The preceding sections briefly summarized the essential key features of the individual extensibility techniques we explored during the course of this book and stated the most commonly found usage scenarios for each of them. To round off this examination, we compiled a comparison matrix as shown in Figure 7.5, which presents all of the essential technical information on a single page for reference purposes.

Plain Java

Web Service

EJB

Interceptor

Interface

Java Interface

WSDL

EJB Interface

EJB Interface

Binding

Classname

Endpoint (URL)

JNDI name

ejb-jar.xml/ Annotations

Provisioning

Classloader

WS Runtime

EJB Container

EJB Container

Explicit

(Explicit)

Explicit

Explicit/Implicit

Strengths

Works on any Java class with interface

Universal

Build-in EJB feature

Minimal-invasive

Weaknesses

Complex DC model

Performance loss (XML Serialization)

-

(Based on Reflection API)

Extension call

Build-in Concept Required

Ext. framework

Figure 7.5 Comparison Matrix

On the left side of the matrix, some key characteristics of extensibility techniques from a technical perspective are listed and then mapped to the individual extensibility mechanisms. To avoid any confusion, a short description of the attributes and their meaning is provided: 왘

Interface

The interface that is used to define the technical contract between the definition and implementation of a service. When using a technique based on Java class loading, the interface is the fully qualified classname of the Java interface that comprises the extension. In a scenario based on EJBs, the interface is

171

7

Summary

either the local or the remote interface of the session bean. When using Web services, the interface is defined within the WSDL file. 왘

Binding The mechanism used to bind the implementation to the interface during runtime. The class loading approach uses the fully qualified classname to load and instantiate a simple JavaBean (POJO), EJB lookups use the JNDI name, and in scenarios based on Web services, the binding is achieved by specifying the endpoint URL of the implementing Web service (provider).

왘

Provisioning This attribute defines who is responsible for the provisioning of the implementation. Depending on the scenario, the implementation is provided either by class loaders, the EJB container, or the Web service runtime environment.

왘

Extension call This attribute declares whether or not the individual technique qualifies as being either of explicit or implicit type.

왘

Build-in Concept Required This attribute indicates whether or not the underlying concept is required to be built-in to an application by the OSP to be used in a modification-free manner. This is certainly the case for the two scenarios using plain Java class loading and dynamic EJB invocation. If the OSP did not implement such extensibility options, there is no other way than to modify the original coding to make it extensible. As Web service binding ports are maintained in a dedicated repository in SAP NetWeaver CE (residing within the SOA management tab of the SAP NetWeaver Administration), statically changing the binding port to point to an alternative implementation is regarded as a configuration task rather than a modification ().

As shown in Chapter 6, Introducing an Extensibility Framework, the extensibility framework presented only requires a few modifications to metadata artifacts to plug into a formerly non-extensible application, which classifies as a minimal-invasive modification (). 왘

Strengths Lists the most important aspect of an extensibility technique that speaks in favor of using it.

왘

Weaknesses This attribute addresses potential drawbacks or other negative side effects that may influence the decision to use the technique or not.

172

Comparison

This concludes our venture into the broad area of extensibility. Now it is up to you to take what you have learned and apply it to real-world solutions. I hope that the provided information helped you acquire a thorough understanding of extensibility in particular and the development of composite applications in general. Some of the presented material may be hard to digest at the beginning because some of the technologies include advanced topics, but by gaining a solid understanding of all the covered concepts and technologies and how to leverage them, you’ve taken your development skills to the next level. I hope you were able to not only pick up the essentials of extensibility but also learn a thing or two about other aspects of application development.

173

7.5

A

Further Reading

A.1

Books

Ganz, Bertram; Gürtler, Jochen; Lakner, Timo: Maximizing Web Dynpro for Java. Bonn: SAP PRESS 2006. Rauscher, Jan; Stiehl, Volker: The Developer’s Guide to the SAP NetWeaver Composition Environment. Bonn: SAP PRESS, 2008.

A.2

Internet Sources

Business Process Management (BPM): http://www.sdn.sap.com/irj/sdn/nw-bpm?rid=/ webcontent/uuid/90f7e38f-1169-2a10-d2bb-e3fbdd283a5a CAF roles: https://forums.sdn.sap.com/thread.jspa?threadID=1269626 Enterprise Service Manage

Customer In: http://esworkplace.sap.com/socoview (bD1lbiZjPTAwMSZkPW1pbg==)/reder.asp?packageid=DE0426DD9B0249F1951500 1A64D3F462&id=445BCE82AAED11DB2B24000F20DAC9EF Enterprise Services on SDN: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs /

library/uuid/f0763dbc-abd3-2910-4686-ab7adfc8ed92 GDT catalog: http://www.sdn.sap.com/irj/sdn/explore-es?rid=/library/uuid/303fd1

92-1db2-2a10-59b9-9dfd93f4b10f Java 5 Enterprise Edition application server: https://www.sdn.sap.com/irj/scn/go/por-

tal/prtroot/docs/library/uuid/f98c731d-0e01-0010-dfa5-dfb8f49dac6e?overridelayout=true SAP Component Model: http://www.sdn.sap.com/irj/sdn/explore-es?rid=/library/

uuid/303fd192-1db2-2a10-59b9-9dfd93f4b10f SAP Guided Procedures (GP): http://help.sap.com/saphelp_nw04s/helpdata/en/33/

198141f906040de10000000a1550b0/frameset.htm Providing Web Services: http://help.sap.com/saphelp_nwce10/helpdata/en/46/9357

326110581de10000000a1553f7/content.htm “The New SOA Configuration Approach” by Alexander Zubev published on SDN:

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/40dabb46-dd66-2b10-1a9 a-81aa620098b3 Singleton Pattern: http://javaboutique.internet.com/tutorials/singleton/

175

B

The Author Matthias Steiner is a Solution Architect for SAP Custom Development. Using the potential of SOA and composite applications, his role is to evaluate SAP's cutting-edge technologies and transform them into real solutions for SAP customers. He began his career with SAP in 2002 and has gathered significant experience in numerous enterprise-scaled development projects in both the ABAP and the Java world. He actively contributes to the SAP Community Network (SDN): https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/u/5263.

177

Index A Access Control List (ACL) 36 Adobe Interactive Forms 25, 26 Annotation 98, 106, 128, 129, 135, 144, 146, 147, 149, 167 AOP 98 API 18, 32, 36, 44, 108, 144, 162 Application architecture 17 componentization 43 configuration 111, 113 design 27 extensible 113 layering 19, 43, 165 Application Programming Interface 씮 API Application service 82, 91, 92, 96, 97, 101 exposing as Web service 95, 96 Around-Invoke 149 Aspect 98 Aspect-Oriented Programming 98 Assembly 57 container 112 unit 108 Association 90 ATP 32 Authentication 129, 136 Available to promise 32

B Backend abstraction layer 씮 BAL connectivity layer 씮 BCL connector 45, 46 system 20 Backwards-compatible 32, 63, 99 BAdI 41, 44 BAL 45, 46, 130 BAPI 121 BAPIRET2 121 BCL 45, 46, 130 Behavior, transactional 40

Best practice 19, 99, 162, 166 Binding 35, 105, 143, 147, 151, 152, 167 port 98, 138, 168, 172 Black box 23, 24, 121 BO 20, 23, 82, 85, 86, 93, 95, 97, 99, 101 attribute 87 composite 102 Bottom-up 116, 126, 141 BPM 26 BPMN 27 Building block 43, 63 Business Add-In 41 Business Application Programming Interface 121 Business logic layer 46, 130, 138 Business object 씮 BO Business process 25 extensible 115 platform 9 Business Process Management 26 Business Process Modeling Notation 27

C CAF 23, 82, 96, 97, 98, 100, 106, 107 Service Browser 114, 163 Cardinality 87 Class Entity 85 Classloading 35, 36, 47, 48, 49, 65, 68, 74, 76, 81, 143, 154, 165, 167, 171, 172 Code-first 116 Coding convention 156 Compensate service 40, 102 Compensation scenario 40 Complex structure 88, 90 Complex type 92 Component model 34, 43, 115, 143, 167 Componentization 43, 108 Composite 44, 45, 99, 102 Composite application 9, 37, 39, 82, 97, 100 explorer 87, 88 Composite Application Framework 씮 CAF Composite business object 31, 102

179

Index

Composition 45 Configuration 42 by Exception 146 Connectivity layer 21 Consumer proxy 131, 136 Context data 32 transactional 39 Contract-first 116, 138, 141 Create Project 61 Cross-cutting concern 23, 98, 151 CRUD 39, 85, 91, 93 Custom implementation 77, 78, 81, 82, 106, 107, 109, 110, 163, 167 Cyclic dependency 76

D Data composition 31 integrity 39 layer 20 Data Access Object 22, 23 Data Transfer Object 22 DC 35, 52, 66, 69, 116, 144 Dependency 35, 49, 57, 66, 74, 76, 93, 106, 107, 112, 117, 158 injection 105, 115, 135, 167 Deploy 69, 78, 101 Deployment unit 158 Design pattern 19, 155, 161 Design principle 17, 162 Destination configuration 98 Development component 씮 DC configuration 49, 51, 75, 82, 109, 116, 158 distributed 43 Distributed transaction 40, 103 Documentation 42 Domain model, system-specific 45 DU 158 Dynamic endpoint 138

180

E EAI 22, 168 EAR 108 EJB 22, 34, 81, 106, 167 EJB session bean 104, 106, 135 Endpoint 116 dynamic 138 Enhancement 30 Enterprise application 128, 144 Enterprise Application Integration 22, 168 Enterprise Archive 108 Enterprise JavaBean 씮 EJB Enterprise Resource Planning 120 Enterprise Service 92, 118, 124 Enterprise Service Bus 21, 45 Enterprise Services Repository 22, 141 Entity forwarding 108 service 85, 91 Enumeration 87, 88 ERP 120 ESB 21, 45 ESR 22, 141 Explicit extensibility 31, 32, 39, 144, 146 Export framework 48 functionality 47 SCA 58 Exposing session bean as Web service 126 Extensibility 29, 43, 48, 81, 143, 165, 167, 169, 172 concept 47, 116, 158 explicit 31, 32, 39, 144 framework 44, 144, 155, 156, 157, 161, 162, 163, 169, 172 implicit 31, 33, 39, 41, 144, 146, 150, 169 mechanism 171 structural 30 technique 35 Extensible application 113 Extensible business process 115 Extension point 32, 36, 37, 39, 41, 42, 44, 82, 102, 104, 105, 106, 107, 109, 111, 113, 143, 145, 149, 154, 155, 156, 160, 166 explicit 32

Index

Extension point (cont.) predefined 33, 41 provider 32 Extension type 148, 155 External facing portal 24 External service 23, 31

F Façade 46, 95, 130 Fault message 121, 122, 124 Field extensibility 30 File application-j2ee-engine.xml 75 ejb-jar.xml 151 sap.application.global.properties 65, 79, 111, 157, 160 Flexibility 41 Flow logic 44 Functionality ApplicationPropertiesAccess 65 Future enhancement 91

G GDT 20, 119 catalog 124 log 121 Global data type 씮 GDT Governance 122 process 118

H Heterogeneous system landscape 20, 21, 45, 115, 168 Hook 82, 145, 155

I IDE 42 Implicit extensibility 31, 33, 39, 41, 144, 146, 150, 157, 169 Import SCA 58, 61, 74 Independent software vendor 40, 48 Integrated Development Environment 42 Interceptor 33, 98, 145, 150, 153, 167, 170

Interface local 104 stability 32 InvocationContext 153 ISV 40, 48

J Java Architecture for XML Binding 100 Java development infrastructure 59 Java Naming Directory Interface 씮 JNDI Java Persistence API 22, 85, 97 Java Reflection API 151, 153, 166 Java system property 79, 113 JavaBean 62, 65, 115 JAXB 100 JNDI 46, 65, 106, 130, 143, 146, 160, 163, 167 JPA 22, 85, 97

L Language dependent 87 Lifecycle management 30, 85, 120 method 102 operation 44, 82, 95, 97 Local development component 14, 75 Local interface 104 Local project 75 Log Viewer 114 Loose coupling 25, 34, 106, 143, 166 Luhn algorithm 129

M Mail message template 112 Mail server 111, 114 Mail session 112 Maintenance effort 43 Malicious code 36 Message broker 45 Meta Model Repository 씮 MMR Metadata 58 Metamodel data 91 Method signature 98, 118, 122, 155

181

Index

Minimal-invasive modification 172 MMR 83, 86, 100 Model-driven development tool 27, 97 Modification 77, 151, 161, 170 free of 29, 31, 44, 172 minimal-invasive 172 Multitier architecture 17, 20, 27

N Namespace 40 Naming convention 54, 117, 119, 120, 122, 146 Non-functional aspect 29, 35, 150 Non-interruptive operation 42 NWA 78, 113 NWDI 75

O Offshoring 43 Open source 48 Operation, non-interruptive 42 Option Manage Entities 57 Original solution provider 씮 OSP OSGi Alliance 34 OSP 40, 42, 48 Outsourcing 43

P Parent-child relationship 37 Performance 37, 39 Permission 75, 91, 109 Personal Information Management 80 PI 22 PIM 80 Plain Old Java Object (POJO) 115, 149 Port 126 Post-processing 148, 155 PP 55, 57, 58, 66, 67, 106 Predefined extension point 33, 41 Pre-processing 148, 155 Presentation layer 24 Procedural enhancement 30

182

Process centric 39 component 20, 119, 131, 132 context 26 driven 24 extensibility 30 layer 25 Productivity 97, 99 Prototyping 99 Proxy 106, 135 Public Part 씮 PP Push scenario 39

Q Query-response 120

R Rapid development 99 Refactoring 91, 99 Reflection API 143, 146, 149, 153 Release version information 59 Request-confirmation 120 Required software component 50, 51 Requirement, non-functional 29 Reusability 43 Rich client 24 Roll back 102

S SAP Component Model 34, 36, 47, 54, 55, 76 SAP Developer Network 12 SAP ERP 120 SAP Exchange Infrastructure 22 SAP Guided Procedures 26 SAP NetWeaver Administrator 78 SAP NetWeaver CE 12, 18, 115 SAP NetWeaver Composite Application Framework 씮 CAF SAP NetWeaver Composition Environment 씮 SAP NetWeaver CE SAP NetWeaver Development Infrastructure 75 SAP NetWeaver Process Integration 22

Index

SAP NetWeaver Visual Composer 25 SC 35, 49, 81 dependency 52 description 52, 59 ENGFACADE 50 required 50, 51 SAP_BUILDT 50 SCA 14, 58 export 58 import 58, 61, 74 SCRUM 99 SDN 12, 124 Security 36 SEI 98, 126 Semantic contract 34, 39, 151, 169 Semantic definition 33 Separation of Concerns 씮 SoC Serializable 122 Service browser 96, 101 definition 131, 141 enabling 20, 26, 45 group 131 interface 98, 119, 129 operation 98, 119, 122 provisioning 23 Service Endpoint Interface 98, 126 Service Registry 22 Service-Oriented Architecture 씮 SOA Session bean exposing as Web service 126 Single service administration 131 Singleton 153 Skeleton 135, 138 coding 95, 97 SLSB 82, 97, 98, 128 SMTP 112, 114 SOA 20, 22, 40, 118 SOAP 116 SoC 18, 25, 34, 43 Software component archive 씮 SCA Software component 씮 SC Source code 13 Source Version Control 씮 SVC 59 Spreadsheet format 48 Sprint 99 SR 22

StandardMessageFault 122 Stateless 40 Stateless Session Bean 씮 SLSB Structural extensibility 30 Substitution 148 Supportability 40, 43 SVC 59 System property 113 System-specific domain model 45

T TCO 29 Technical documentation 42 Test stub 138 Test workbench 96, 101 Three-tier architecture 17, 19 TOC 29 Top-down 116, 141 Total cost of ownership 29 Transaction bracket 102 demarcation 39 distributed 40 Type 94 Transactional behavior 40 Transactional context 39 Two-phased commit 40 Tx Type 94

U UDDI server 128 Unrestricted access 77 Use-case 44 User-centric 24

V VC 25 vCard 72, 80 Visual Composer 25

183

Index

W Waterfall approach 99 Weak reference 76, 167 Web Dynpro Java 25 Web service 115, 116, 168 annotation 96 client 130, 134 client proxy 134 configuration 130 consumer proxy 115 creation wizard 127, 139 customization level 133 engineering 116 implementation 130 operation 116 port configuration 137 provider 138

184

Web service (cont.) proxy 135 restriction 128 security settings 137 Web Service Definition, URL Schema 132 Web Service Description Language 116 Web Services Navigator 64, 70, 114, 128, 138, 162 Web Services Reliable Messaging 136 Workflow 25 WSDL 116, 168 WS-RM 136

X XI 22 XML 48, 116 XSD 89