Exploring the WebSphere Application Server Feature Pack for SCA, Part 7: Using Atom and JSON-RPC for Web 2.0 support

The IBM® WebSphere® Application Server V7.0 Feature Pack for Service Component Architecture (SCA) provides Web 2.0 support for SCA by enabling Atom and JSON-RPC access protocol to SCA services. The feature pack also enables the SCA programming model in HTML and JavaScript™ so that that HTML can access SCA services through SCA references using Web 2.0 connectivity. Part 1 of this series provides an overview of SCA bindings within the SCA assembly model.

Share:

Chao M Beck, Software Engineer, IBM

Chao Beck is a technical lead for the feature pack for Service Component Architecture (SCA) early program. She has long been a member of the Application Integration Middleware early programs team responsible for the execution of early programs for IBM WebSphere Application Server products. She handles the development and delivery of education for new product functions and the provision of customer support during pre-GA (early) programs and post-GA (customer acceleration) programs.



Vijai Kalathur (kalathur@us.ibm.com), Software Engineer, IBM

Vijai Kalathur is part of the SCA Feature Pack QoS team. Since joining IBM in 2005 he has worked on the WebSphere Application Server for z/OS security team and the SCA Feature Pack team. He has worked on various components of the SCA Feature Pack including admin, security, transactions, and JMS binding.



20 January 2010

Introduction

Web 2.0 is a trend in the use of World Wide Web technology and Web design that aims to facilitate creativity, information sharing, and, most notably, collaboration among users. These concepts have led to the development and evolution of Web-based communities and hosted services, such as social networking sites, wikis, and blogs, to name a few. Web 2.0 is about connecting people and encouraging collaboration in ways not previously possible.

Web 2.0 technologies include JavaScript Object Notation (JSON), eXtensible Markup language (XML), Atom, and Representational state transfer (REST), but the primary instigator of this new way of looking at the Web is a set of technologies commonly referred to as Asynchronous JavaScript and XML (Ajax). Ajax provides a way of building Web pages that, rather than mixing content and presentation together, separates the two into a basic page that contains the presentation (lists, trees, and so on) and a set of XML or JSON files that are asynchronously fetched using a JavaScript object called the XML HTTP request object.

There is a spectrum of Rich Internet Applications to consider. On the business end, there are mashups, which can often be assembled by business users. Mashup tools use syndication formats such as RSS and Atom. On the other end, developers can build full applications that can have mashups within them, but require a lot more rich logic, like a consumer application. Typically, these applications use protocols like JSON and XML, which can be consumed by Ajax-based toolkits like Dojo. Many times, these applications can require pieces of data locked up in the enterprise. Being able to expose those assets by way of Web 2.0 protocols is key. Other times, these assets can already be Web 2.0 widgets and data that can be included using scripting languages.


Web 2.0 support in the SCA feature pack

The IBM WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA) addresses these high level user stories:

  • As a service developer, you might want to use SCA to compose and assemble a service from new and existing services that are available by way of Web 2.0 technology, such as Atom and JSON-RPC. You might want to make the newly assembled service available over Web 2.0 technology to enable creating an open, implementation-neutral, service-oriented description of the newly created service assembly and composition. You can create this such that the services you provide or refer to reside on Web 2.0 technology.
  • As an SCA developer, you might want to use the SCA programming model in HTML by defining references and properties.

The Feature Pack for SCA provides Web 2.0 support for SCA by enabling Atom and JSON-RPC access protocol to SCA services. The feature pack uses libraries such as JSON4J and Abdera from the WebSphere Application Server V7.0 Feature Pack for Web 2.0. It also includes vendor JAR files and the service assembly to support Web 2.0 connectivity. Specifically:

  • Atom support is provided by Abdera libraries.
  • JSON-RPC uses JSON4J.
  • HTML and JavaScript use the Dojo client library. Dojo is not provided with the Feature Pack for SCA, but you can easily get the IBM Dojo Toolkit from the Feature Pack for Web 2.0.

The Feature Pack for SCA also includes support for widget implementation (implementation.widget), which extends the SCA programming model to HTML applications, and enables you to model your HTML as an SCA component. The implementation artifact is an HTML resource with which you can define SCA references that can be wired to server side services. Currently, you can define references to remote services using an Atom binding and HTTP binding with JSON-RPC wire format.

Figure 1 is an example of an Apache Tuscany sample composite file with a component store containing the implementation.widget. This example defines a "store" component that uses the Tuscany implementation.widget in an HTML file at user interface/store.html. The store html file might look like Figure 2.

Figure 1. HTML as SCA implementation (implementation.widget)
Figure 1. HTML as SCA implementation (implementation.widget)
Figure 2. store.html
Figure 2. store.html

The implementation.widget component type enables you to model your HTML as an SCA component. The implementation artifact is an HTML resource, and above you can see how you can then define SCA references that can be wired to server-side services. There are two references for the store component:

  • catalog is an HTTP binding with a wire format of JSON RPC.
  • shoppingCart is a Atom binding.

When your Web client application is defined as an SCA component utilizing widgets, a JavaScript file is generated that can be included within an HTML document. The JavaScript properly injects service references to SCA references defined on the same HTML document. The client application needs to include the generated JavaScript that contains the necessary client proxy used to access the server-side services. The name of the generated JavaScript is the same as the HTML resource being specified as the implementation artifact.

Following the earlier example, in which the component name was store, add the generated JavaScript file to your HTML resource:

<script type="text/javascript" src="store.js"></script>

The JavaScript is transformed into Dojo Toolkit calls that are binding specific. The generated JavaScript initializes the proxys for the SCA services, which can then be injected into SCA references to make requests to the server-side components. The widget implementation introduces SCA annotations to the JavaScript code. Continuing the example, you can define the references as:

Listing 1
//@Reference 
var catalog = new Reference("catalog"); 
//@Reference
var shoppingCart = new Reference("shoppingCart");

These references will get properly introspected by the implementation.widget and wired to the proper server-side services. If the catalog had a get() method, the script in the HTML page can now easily invoke the method by calling catalog.get(args).


JSON-RPC

As an SCA assembler, you might want to have the ability to enable an HTTP protocol with JSON-RPC style access to an SCA service. This will enable a consumer to use the JSON-RPC style protocol to access your service without rewriting your server-side implementations. The Feature Pack for SCA supports JSON-RPC as a protocol for use with SCA services by using <binding.http> with <wireFormat.jsonrpc>. This enables remote Web browser clients to easily make RPC style calls to server-side SCA components. You can use this binding without any configuration, or by providing a specific service URI:

Listing 2
<t:binding.http><wireFormat.jsonrpc/></t:binding.http>
<t:binding.http uri="http://localhost:9080/Catalog"> 
<wireFormat.jsonrpc/></t:binding.http>

The t: above represents the Tuscany namespace. Any JSON-RPC client can be used to access the SCA services which use the <binding.http> with <wireFormat.jsonrpc>.

Ways to consume JSON-RPC

There are two ways to consume JSON-RPC services on the client application:

  • implementation.widget

    One way is to use the implementation.widget, described earlier. The implementation.widget extends the SCA programming model to HTML or Web 2.0 client applications. Using this for JSON-RPC enables you to model your HTML or Web 2.0 application as an SCA component. The implementation artifact is an HTML resource in which you can define a JSON-RPC reference that can be wired to server-side services. Figure 3 shows an example of a sample composite showing JSON-RPC style access in a widget.

    Figure 3. JSON-RPC style access in widget
    Figure 3. JSON-RPC style access in widget

    In this composite, the component store contains the implementation.widget. The implementation.widget component type enables you to model your HTML as an SCA component. The implementation artifact is an HTML resource. A catalog reference is defined for the store component which contains an HTTP binding with JSON-RPC wire format. This catalog reference can be wired through an HTTP binding with JSON-RPC wire format to server-side services.

    Figure 4 shows another example of the complete programming model: JSON-RPC using SCA enhanced JavaScript.

    Figure 4. JSON-RPC using SCA enhanced JavaScript
    Figure 4. JSON-RPC using SCA enhanced JavaScript

    This example shows how the catalog reference can be wired through an HTTP binding with wire format JSON-RPC to server-side services using implementation.widget. From the top-left corner, you have a composite file with a component that uses the implementation widget. A reference named catalog is then defined using an HTTP binding with JSON-RPC wire format. This reference targets an existing service called Catalog. That service is defined to the top-right in a composite file with a component name of MyCatalog. This component contains the service named Catalog, which is defined with an HTTP binding with wire format JSON-RPC. This component defines its Java implementation to be FruitsCatalogImpl.java. Notice on the lower-right the FruitsCatalogImpl.java file contains a get() method, and also notice the SCA enhanced JavaScript code. Since widget implementation was used, you can now introduce SCA annotations to the JavaScript code. You can introduce the catalog reference and easily call the get() method that was defined in FruitsCatalogImpl.java.

  • SCA JSON-RPC services with Dojo

    The other way to consume JSON-RPC services on the client application is to use SCA JSON-RPC services with Dojo. Dojo provides a basic RPC client class that has been extended to provide access to JSON-RPC services. It was designed so that it is easy to implement custom RPC services. Dojo's RPC clients simplify this process by taking a simple definition of the remote methods and application needs and generating client-side functions to call these methods. The definition file, called a Simple Method Description (SMD) file, is a simple JSON string that defines a URL to process the RPC requests. It also processes any methods available at that URL and the parameters those methods take. The Feature Pack for SCA provides built-in support for Dojo’s RPC and generates the SMD file. You then need to initialize an RPC client object and the remote methods will be available for you to use as usual.

    The SCA services that use <binding.http> with <wireFormat.jsonrpc> will support the SMD protocol by default. SMD is similar to ?wsdl for Web services; entering a service endpoint appended with ?smd will return an SMD descriptor for the service. Using SCA services with Dojo can therefore be as simple as:

    var myService = new dojo.rpc.JsonService("myService?smd");

    Figure 5 shows an example of JSON RPC, directly using Dojo JSON-RPC.

    Figure 5. JSON RPC using Dojo JSON-RPC
    Figure 5. JSON RPC using Dojo JSON-RPC

    This example shows how the catalog reference can be wired through an HTTP binding with JSON-RPC wire format to server-side services using SCA JSON-RPC services with Dojo. The composite file has a reference named catalog defined with an HTTP binding with JSON-RPC wire format. This reference targets an existing service called Catalog, which is defined with a component name of MyCatalog. This component contains the service named Catalog that is defined with an HTTP binding with JSON-RPC wire format. This component defines its Java implementation to be FruitsCatalogImpl.java. Notice on the lower-right the FruitsCatalogImpl.java file containing a get() method, and on the lower-left side, the direct use of Dojo JSON-RPC code. You first have to define the proper Dojo requirements, and then you can define your catalog service using SCA services with Dojo by entering a service endpoint appended with ?smd to return an SMD descriptor for the service. You can then call the get() method that was defined in FruitsCatalogImpl.java.

    Once you have completed an HTTP binding with JSON-RPC wire format, you can use JSON formats. The parameters are passed in JSON format name/value pairs. JSON data binding is used to transform JSON input arguments into Java types, and to transform Java results into JSON. For example, input and output parameters are passed in JSON format:

    Listing 3
    { string : value }
    { "method" : "get" }
    { "result" : "12345" }

Data conversion through JSON databinding

As mentioned earlier, data conversion is handled automatically by JSON databinding. When you access an HTTP binding service with a JSON-RPC wire format, input data must be passed in JSON format name/value pairs. However, the Java implementation method that is called by the JSON-RPC runtime will require input in the form of Java types, and will return data in Java types rather than in JSON format. The JSON databinding will perform the transformation on both sides. It can handle conversions back and forth from primitive types, arrays, Java beans, lists, maps, and sets.

As an example, consider the supported data types for the JSON conversion. Parameters for JSON-RPC requests are sent to the server in JSON format, and must be transformed by the SCA runtime for use in the Java implementation. The response to the client is also in JSON format, so the SCA runtime converts the value returned from a method like EchoComponentImpl.echo() back into JSON. For example:

echo("Testing...")

might submit the following data to the server:

{"params":["Testing..."],"method":"echo","id":1}

The Java method EchoComponentImpl.echo(String message) is invoked with the string parameter Testing... and returns the string object:

"echo: Testing..."

The JSON response returned to the Web client might look like:

{"id":1,"result":"echo: Testing..."}


Atom

As an SCA developer, you might want to be able to define a reference to an external Atom feed or expose your data collection as an Atom feed. The Feature Pack for SCA enables services to become available as data feeds through the Atom binding <binding.atom> and simplifies consuming and aggregating external feeds. With the Feature Pack for SCA, you can communicate with services that provide or consume items described in the Atom Syndication Format and Atom Publishing Protocol.

You can use this binding without any configuration, or by providing a specific service URI:

Listing 4
<t:binding.atom/>
<t:binding.atom uri="http://www.oreillynet.com/pub/feed/35"/>

To access the feed directly, use the uniform resource indicator (URI).

The Atom Publishing Protocol provides REST style access to data collections. The Atom binding provides support for collections. The collection of items can be added, retrieved, updated, and deleted using the four basic actions of the HTTP protocol:

  • POST (create or add)
  • GET (retrieve or query)
  • PUT (update)
  • DELETE (destroy or remove)

A collection that uses the Atom binding typically implements the Collection interface given in the package org.apache.tuscany.sca.data.collection. This interface declares the basic access methods, above. For example, you can view the collection as an Atom feed and manipulate items in the feed as Atom entries. It is up to you to provide the code that implements the Collection interface. You also need to provide the code that translates from your business objects to the Atom model objects Feed and Entry.

Ways to consume Atom services

Any Atom client can be used to access SCA services that use the <binding.atom>. There are three ways to consume Atom services on the client application:

  • implementation.widget

    One way is to use the implementation.widget, described earlier. Using the implementation.widget for Atom, the implementation artifact can be an HTML resource that represents the application. You can then define an Atom reference that can be wired to server-side services. Figure 6 shows an example of Atom style in a widget.

    Figure 6. Atom style access in a widget (binding.atom)
    Figure 6. Atom style access in a widget (binding.atom)

    Again, this is a sample composite file. The component store contains the implementation.widget. A shoppingCart reference is defined for the store component, which contains an Atom binding. This shoppingCart reference can be wired through Atom binding to server-side services. Figure 7 shows a comprehensive example of Atom using an SCA-enhanced JavaScript.

    Figure 7. Atom using SCA-enhanced JavaScript
    Figure 7. Atom using SCA-enhanced JavaScript

    This example shows a more complete picture of how the shoppingCart reference can be wired through Atom binding to server-side services using the implementation.widget. You have a composite file (upper-left) with a component that uses the implementation widget. A reference named shoppingCart is then defined using an Atom binding. This reference targets an existing service called Cart, which is defined to the top-right in a composite file with a component name of ShoppingCart. This component contains the service named Cart that is defined with an Atom binding, and defines its Java implementation to be ShoppingCartImpl.java. Notice on the lower-right the ShoppingCartImpl.java file that contains REST data collection methods, such as getAll(), query(), post(), get(), put(), and delete(). Also, notice the SCA enhanced JavaScript code: since widget implementation was used, you can now introduce SCA annotations to the JavaScript code. You can introduce the shoppingCart reference and easily call the get() method that was defined in ShoppingCartImpl.java.

  • SCA Atom services with Dojo

    Another way to consume Atom services on the client application is to use SCA Atom services with Dojo. Figure 8 shows an example of this scenario.

    Figure 8. Atom using Dojo Atom
    Figure 8. Atom using Dojo Atom

    This example shows how the shoppingCart reference can be wired through Atom binding to server-side services using SCA Atom services with Dojo. From the upper-left, you have a composite file that has a reference named shoppingCart defined with an Atom binding. This reference targets an existing service called Cart. That service is defined to the top right in a composite file with a component name of ShoppingCart. This component contains the service named Cart that is defined with an Atom binding. This component defines its Java implementation to be ShoppingCartImpl.java. Notice on the lower-right the ShoppingCartImpl.java file which contains REST data collection methods, such as getAll(), query(), post(), get(), put(), and delete(). Also on the lower-left side, notice the use of Dojo Atom directly code. You first have to define the proper Dojo requirement and then, using the proper Dojo code, you can get your feed by using the get() method that was defined in ShoppingCartImpl.java.

  • Atom services directly

    Atom services can be accessed directly from a browser or other feed client. To access the feed directly, you can use the uniform resource indicator (URI) that the service specifies.


Security

You can secure collections of data that are exposed over Atom and HTTP bindings in an SCA application. An Atom binding can expose data as an Atom feed, or it can reference existing external Atom feeds. As a service developer, you might want to define a service using SCA and make it available over HTTP channels using Web 2.0 connectivity. You can do so such that a client must authenticate itself in order to use the SCA service, or to ensure that the transport between sender and receiver is secure. Authorization policy is enforced by using SCA policy sets on implementation.java components. You cannot apply an authorization policy to the implementation.widget components. For more information on authorization policy, refer to documentation on SCA authorization and security identity policies in the IBM Education Assistant (see Resources).

Securing the service

You can secure services that are exposed over Atom or HTTP binding using intents. Administrative and application security must be enabled for the intents to be enforced. The three intents listed below are valid options for the requires attribute on the binding.atom elements on the service side:

  • authentication.transport requires any client invoking the service to provide valid authentication information.
  • confidentiality.transport requires any client invoking the service to do so over a secure transport that provides confidentiality of the transport.
  • integrity.transport requires any client invoking the service to do so over a secure transport that provides integrity of the transport.

For example, if you want to edit a composite definition that exposes a Java service over the Atom binding so that the exposed service requires a client to authenticate and communicate over a secure transport, you can do this:

Listing 5
<service name="NewsService">
    <t:binding.atom uri="https://localhost:9443/newsService"
        requires="authentication.transport confidentiality.transport"/>
</service>

Invoking a secure Atom service

If you want to invoke a secure service that is exposed over an Atom binding, you can access the service directly from a browser or a client that supports Atom feeds. To access the feed directly, you can use the URI that the service specifies. If the service requires confidentiality or integrity, use HTTPS protocol. If the service requires authentication, you will be prompted by the browser to enter valid credentials.

For example, assume you want to invoke a service using a reference URI. If the service being referenced requires confidentiality or integrity, use the https protocol:

Listing 6
<reference name="atomFeed">
    <t:binding.atom uri="https://localhost:9443/newsService"/>
    </reference>

You can also invoke the service using a reference target:

Listing 7
<reference name="atomFeed" target="NewsServiceComponent/NewsService">
    <t:binding.atom/>
    </reference>

The invocation will be made over HTTPS if the service specifies the confidentiality.transport or integrity.transport intent.

If the service requires authentication and a browser is being used to access the feed directly, you will be prompted to enter valid credentials. If a Java client is used to access the service, the authentication information should be included in the HTTP header. If Single Sign-On is enabled, the credentials from a previous login will be propagated in the request to the secure feed.

A specific username/password pair can also be sent with the request by configuring an authentication-alias. First, create a J2C authentication-alias using either the WebSphere Application Server administrative console or wsadmin commands. In the composite file, specify the alias name on the binding.atom element using the authentication-alias attribute. The WebSphere Application Server SCA namespace needs to be defined in the composite file:

Listing 8
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"            
...    xmlns:qos="http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06" ...
<reference name="atomFeed" target="NewsServiceComponent/NewsService">
    <tuscany:binding.atom qos:authentication-alias=”AtomAlias”/>
</reference>

Invoking a secure HTTP service

The service can be accessed from a JSP or HTML page using Dojo Toolkit application programming interfaces from a Web browser. If the service requires confidentiality or integrity, the https protocol should be used. If the service requires authentication, the client application should be configured to require the user to provide a valid username and password. Default WebSphere Application Server settings will propagate these credentials in the request to the service.

There are no specific run time tools required to deploy services provided or referred to over Web 2.0 bindings. There are no specific run time tools required to deploy HTML that is enhanced with SCA. As of this writing, IBM Rational® Application Developer visual and textual composite editors do not yet support Atom binding, HTTP binding with wire format JSON-RPC, or widget component implementation access styles, but you can easily edit the composite file directly to add these new Web 2.0 features.


Summary

The WebSphere Application Server V7.0 Feature Pack for SCA provides Web 2.0 support for SCA by enabling Atom and the JSON-RPC access protocol to SCA services. It enables the SCA programming model to HTML and JavaScript so that HTML can access services through SCA references using Web 2.0 connectivity.

The feature pack supports JSON-RPC as a protocol for use with SCA services by using <binding.http> with <wireFormat.jsonrpc>. This enables remote Web browser clients to easily make RPC-style calls to server-side SCA components. The Feature Pack for SCA enables services to become available as data feeds through an Atom binding and simplifies consuming and aggregating external feeds.

You can secure collections of data that are exposed by an Atom binding in an SCA application, and you can secure services that are exposed over an Atom and HTTP binding using intents. The SCA authorization and security identity declarative policies can be used to protect SCA components and operations, and to declare the security identity under which the SCA components or operations are executed.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=461212
ArticleTitle=Exploring the WebSphere Application Server Feature Pack for SCA, Part 7: Using Atom and JSON-RPC for Web 2.0 support
publish-date=01202010