|
David develops a Microsoft PocketPC client implemented as a set of web services across .NET and J2EE/Axis.
July 01, 2004
URL:http://www.drdobbs.com/jvm/a-service-oriented-architecture-for-mobi/184405730
David is an infrastructure architect at TRC. He can be contacted at david.houldingps.net.
Service-Oriented Architectures (SOAs) have seen rapid growth in enterprise systems, driven largely by integration and consolidation needs. These needs are particularly acute in heterogeneous computing environments with a variety of applications, operating systems, and hardware. In SOAs, services are published using a common interface description language and protocol, most often the Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP). For example, .NET and J2EE/Axis are two enterprise application server platforms with radically different implementations (Axis is a SOAP implementation from the Apache Project). However, both enable services they host to be published as web services with WSDL, providing interoperability in heterogeneous SOAs. This uniformity in the publication and accessibility of services facilitates effective reuse, thereby accelerating development and reducing costs associated with redundancy, maintenance, and administration. Given the WSDL for a service, you can utilize that service without knowing the details of how that service is implemented or hosted. Concurrently, enterprises have also seen greater penetration of PDAs and short-range wireless—in particular the 802.11 family of protocols that has paved the way for short-range wireless mobile applications. The unique combination of characteristics associated with SOAs and mobile applications has presented new challenges for enterprise architects, designers, and developers, including integration across heterogeneous environments and partial wireless connectivity.
In this article, I explore SOAs, mobile applications, and the combination of them. Most of the concepts I discuss here are generally applicable to the use of thin application clients in SOAs, including web browsers and voice interfaces. To illustrate, I present a customer-search mobile application (available electronically; see "Resource Center," page 3) client using Microsoft PocketPC, and the associated SOA implemented as a set of web services across .NET and J2EE/Axis.
Figure 1 shows the architecture for the customer search example mobile app and SOA. The static view of the architecture presents the actors, services, and components—that is, the "what" aspect of the architecture.
The actor is the sales agent using the customer search mobile app to retrieve information about customers by the category of products they have purchased in their order history, their rank in terms of total sales, and their geographical region.
Services are the coarse-grained "objects" in the SOA and may be broadly classified as business, infrastructure, and data services, as in the rightmost tiers in Figure 1.
Business services in complex SOAs hosting multiple applications may also be further subclassified as primary or secondary, where each of the former has a one-to-one relationship with an application client and the latter is a family of secondary, supporting business services used across applications. In this case, a good rule of thumb for application developers using services in an SOA is if a given "use-case" scenario demands interaction from the application client with more than one service, the client should make one request to the associated primary business service and have the business service delegate subrequests to other services in the SOA, aggregating and returning the result to the client. This is not only important in terms of minimizing client requests to the SOA (especially over wireless), but also in consolidating business logic in the SOA rather than on the application client where it is not available for other clients or business-to-business (B2B). This, in turn, enables rapid development, B2B, and minimal redundancy.
Services share characteristics with finer grained objects. This includes encapsulation, where a service has methods and may have hidden state or integration with third-party frameworks or external products. This essentially wraps that entity, thereby retaining architectural flexibility to change its implementation as enterprise needs evolve. For example, a data service may wrap a particular object-relational mapping and database. Care must be paid to the definition of the interfaces of services to effectively realize integration and facilitate evolution. Good rules of thumb in defining service interfaces are to be minimal in exposing only required functionality, and maintain strict encapsulation (for example, in avoiding exposing third-party framework or product types through the interface).
The customer service is the business service for the application where you implement the business logic. This includes interaction with the configuration infrastructure service on startup to retrieve configuration information, and interaction with customer data services at runtime to retrieve, then process customer information requested by the client. Responsibilities also include aggregation, sorting, and filtering of customer data. This service is implemented in C#, hosted on .NET, and published using web services.
The configuration service is an infrastructure service responsible for providing configuration information used to initialize other services, including (for example) properties defining the availability of customer data services. Other infrastructure services typical in an SOA but not in my example include security, logging, audit, event, business rules, and workflow services. This service is implemented in Java, hosted on J2EE, and published using web services with the Axis framework.
The two customer data services for the customer search application provide customer data to support the customer service. There are two instances of this service, each published with the same WSDL web service interface, but one implemented in C# on .NET and the other in Java on J2EE/Axis.
Business objects and their interrelationships have real-world counterparts in the associated business domain. For example, Figure 2 shows the Customer business object graph, consisting of the top-level Customer object and the child objects on which it depends.
In an SOA, business logic exists in service implementations rather than in methods of the business objects themselves, as is often the case in smaller scale component-based applications. Business objects appear as the data types in the interfaces of business services in the SOA, so services depend on business objects but business objects don't depend on services. It is also typical in SOAs to have a unified business object model (BOM), where one consolidated set of business objects is defined, to be utilized across all business services. This enables new business services to be written that reuse the existing BOM without rewriting common types, and also avoids data mapping issues going between redundant duplicate data types wherever possible. Business objects need to be flexible in their implementation to enable existence as either shallow or deep object graphs. For example, the Customer object by itself constitutes a shallow object graph with no children, while the Customer object with all the types in Figure 2 constitutes a deep object graph. For example, avoiding default construction of child types in Customer lets Customer exist as a top-level object that may be passed efficiently between services without unnecessary child baggage. Of course, the full Customer object graph may also be passed between services where necessary.
Sometimes neither the full business object graph nor the top-level object meets the need, as a particular user interface or database request may need information across business objects that is a small subset of the overall information in the graph, but not contained (for example) in just one object of the graph. In this case, view objects are appropriate; for instance, in Figure 3 where the CustomerSummary consists of information from the top-level Customer object, but also orderTotal summary information from the Order child objects.
View objects let information be efficiently retrieved from databases, displayed on user interfaces, or passed between services by minimizing redundancy. This is particularly important where web services middleware is used in the SOA because of the relatively high cost of marshaling/unmarshaling to/from SOAP XML, and the propagation of this text information over HTTP or even slower HTTPS. Redundancy of data may also be minimized and performance improved through carefully constraining queries to limit information retrieved and paging so as not to retrieve a full data set when only the first page or subset is sufficient. A natural reaction by developers to a relatively slow middleware (such as SOAP) is to do aggressive caching to have all information on-hand locally—for example, on the client in case it is needed, thereby avoiding runtime middleware interactions. However, in practice, this strategy seldom works as the time taken to fill the cache precipitates the exact performance issues it is intended to mitigate, especially when done on a main UI thread or on a device with limited capabilities (such as a mobile client). Caching may be appropriate in some exceptional cases where done carefully so as to ensure a high cache hit rate and minimal impact to the application; for example, where caches are populated using secondary lower priority background threads. However, you should use it with caution. A better general strategy is to reduce data redundancy. Only if this does not meet your performance needs should you turn to other strategies, such as caching.
The customer search application client in Figure 4 was implemented in C# on the .NET Compact Framework to run on a Microsoft PocketPC mobile device with IEEE 802.11b WiFi short-range wireless connectivity with the SOA.
With wireless connectivity, one of the challenges is accommodating partial connectivity where the network is not always available. Figure 4 shows how this is handled from a user-interface standpoint. Mobile clients also have relatively limited screen and other input/output capabilities and resources (such as memory and CPU) when compared to desktop PCs. As such, care must be paid to UI design for mobile clients to maximize use of the device capabilities, while staying within its bounds to make the client usable. In general, trying to apply desktop UI design to devices does not work well, even if it is technically possible.
In Figure 4(a), the sales agent enters the category of product, rank of customers (for example, top 1, top 5, or all), and geographical region of interest (central, east, or west). The sales agent then clicks the Search button to initiate the search. At this point, the mobile client tests to see if the customer service is available via short-range wireless. If so, customer information is retrieved from the SOA and you proceed to Figure 4(c) for a summary list of customers. If, on the other hand, wireless connectivity is not available, the client displays the warning to the user as in Figure 4(b), then uses the latest information in its local memory cache to display the filtered list in Figure 4(c). The sales agent can then page through the customer summary list in Figure 4(c) to find a customer of interest. The agent then selects the customer with the associated radio button on the left, and clicks Detail to view the detailed customer information, as in Figure 4(d). The views in Figures 4(c) and 4(d) may then be closed using the Close button to return to Figure 4(a) for another search.
Building on the static view, I now turn to the collaborations that occur in the example SOA and customer search application to realize the use cases in Figure 5.
When wireless connectivity is established, the mobile client reaches the services in the SOA and the use case named "Search Customers in Central Databases" applies, for which the normal end-to-end scenario is shown in the sequence diagram in Figure 6. Note in particular how after users click the search button on Figure 4(a), the customer search client tests connectivity by calling a ping method on the customer service in the SOA. In this case, the method call succeeds since connectivity is established, and the client proceeds to use the services to retrieve the most up to date customer information. After the information is retrieved to the client, it is cached—keyed by the database ID and customer ID—for later use when the client is disconnected.
Data redundancy is minimized in the interactions between the customer service and customer data services in using CustomerSummary view objects rather than full Customer object graphs.
Once the customer service has aggregated and limited CustomerSummary results from all customer data services, it retrieves full customer information with a single call to each customer data service only for required customers it owns. This minimizes the number of network request/responses, thereby improving performance. Given the sophisticated rapid development features of many IDEs, it is easy to overlook what methods result in network interactions and which methods are just local calls. However, if care is not paid to minimizing calls that result in network interactions, the response time of the client can become unbearably slow. In the queryCustomer calls to the customer data services, an array of customer IDs is passed so that multiple customers may be retrieved by the customer service with a single request/response. While technically possible, retrieving each customer separately with a single request/response would result in much slower response time from end-user perspectives.
When no wireless connectivity is available, the use case in Figure 5 ("Search Customers in Local Cache") applies for which the normal end-to-end scenario is shown in the sequence diagram in Figure 7. In this case, the ping method call from the client to the customer service fails, so the client uses its local cache, filtering and displaying the latest information from the memory cache of the mobile device that is available to the sales agent.
Enterprises are moving toward SOAs, meeting integration and consolidation needs. Concurrently, mobile applications are being put to use in mission-critical business applications, driven by the penetration of more sophisticated mobile devices in the enterprise, and the rapid growth of short-range wireless, particularly wireless networks based on IEEE 802.11 WiFi Standards. The SOA for mobile applications I present here provides a baseline framework for a successful architecture and development of mobile applications in SOAs.
DDJ
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.