ServiceTechMag.com > Archive > Issue LXX, February 2013

Download Issue
Download Full Service Technology Magazine PDF

Big Data as a Service

Philip Wik

Philip Wik

The various ways in which SOA design principles can be synergized with Big Data are explored. Complex event processing, Apache Hadoop metadata management, scalable Infrastructure-as-a-Service (IaaS), and front-end analytics are among the methods that can render Big Data-as-a-Service (BDaaS). "The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents." - H.P. Lovecraft, "The Call of Cthulhu," 1928. The domain of information fueled not only by enterprise data such as general ledger accounting, Big Data is also propelled by sensor data, call data records, radio-frequency identification tracking, digital exhaust, and social media. Big Data is stored in NoSQL databases. NoSQL, and by implication Big Data, is typically non-relational, distributed, open source, horizontally scalable, schema-free, eventually consistent, and massive in terms of data volume, velocity, and variety. Big Data is realizing its promise. Load processing time can now be reduced by loading raw data into Hadoop. Sears, for example, shrunk its ETL time from 20 hours to 17 minutes. Insurance companies are tailoring premiums using data collected by sensors that record driving patterns, breaking abruptness, and milage. Retailers are embracing dynamic pricing models. Pricing is no longer tied to the manufacturer's suggested retail price (MSRP), but is now more sensitive to supply and demand based on inventory levels, item sales velocity, advertising channels, and competitor's pricing. The price displayed on a light-emitting diode for each item will fluctuate with the variability of gasoline prices or wheat futures, increasing both the margin for the seller and competitive opportunities for the buyer. This realtime price jiggling can be seen in the sale of sports and airline tickets. That Target's IT figured out a teen girl was pregnant before her father did is a mildly unsettling reminder that Big Data is typically non-relational, distributed, open source, horizontally scalable, schema-free, eventually consistent, and massive in terms of data volume, velocity, and variety. Big Data is realizing its promise. Load processing time can now be reduced by loading raw data into Hadoop. Sears, for example, shrunk its ETL time from 20 hours to 17 minutes [REF-1]. Insurance companies are tailoring premiums using data collected by sensors that record driving patterns, breaking abruptness, and milage. Retailers are embracing dynamic pricing models. Pricing is no longer tied to the manufacturer’s suggested retail price (MSRP), but is now more sensitive to...


Service-Orientation with Oracle SOA Tools

Glauco Castro, Yuri Marx Pereira Gomes

Glauco Castro

Yuri Marx Pereira Gomes

The Oracle SOA Suite is a middleware offering that can be implemented in compliance with service-orientation principles. Conversely, the features provided by this platform can help optimize the application of these principles to facilitate the connectivity and reuse of shared services and service-oriented solutions. This article explores the marriage of service-orientation with the tools and technologies of the Oracle SOA Suite. Preliminary consultation with experienced industry professionals and identification of the market's best practices can help decrease the high potential for error that accompanies first-time, independently executed SOA implementations. The objective of applying the eight SOA principles as identified by Erl is to propagate the best practices of service development, through uniting practices with mature, service-oriented technology. Let's first recap Erl's eight de-facto principles of service-orientation: Standardized Service Contract - Services within the same service inventory are in compliance with the same contract design standards. Service Loose Coupling - Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment. Service Abstraction - Service contracts only contain essential information and information about services is limited to what is published in service contracts. Service Reusability - Services contain and express agnostic logic and can be positioned as reusable enterprise resources. Service Autonomy - Services exercise a high level of control over their underlying runtime execution environment. Service Statelessness - Services minimize resource consumption by deferring the management of state information when necessary. Service Discoverability - Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted. Service Composability - Services are effective composition participants, regardless of the size and complexity of the composition. Oracle has a portfolio of tools for the SOA development lifecycle and its governance. These tools can be used to help SOA implementation teams apply service-orientation principles, and are commercialized by Oracle into three...


Service Performance Optimization Techniques for .NET - Part II

Christoph Schittko

Christoph Schittko

The capability granularity and constraint granularity of a service contract can greatly impact performance of the service architecture. A service consumer communicating over a network connection can experience significant latency between request and response when exchanging large messages over poor network connections. Network latency is often beyond your control, especially when you consume third party services over a public network. Nevertheless you can architect your services to minimize the performance impact of remote service interactions. The key consideration to keep in mind is to "make it worth the trip across the network". In other words, keep the ratio of processing time greater than the time it takes to establish the network connection and transmit the data. The impact of the message transmission increases relative to the execution time the consumer observes for invoking a service capability. In the next scenario, the service is architected to reduce the number of calls across the network. Fewer calls reduce the overhead of managing network connections and should produce capabilities that take longer to process than the message transmission. The choice of a service’s hosting model can greatly impact its performance because of the differences in the processing that occur for incoming and outgoing messages. Usually you see a trade-off between robustness and a rich feature set on one hand and high performance on the other. Many features require additional layers of processing between the service endpoint and the service implementation. Each layer adds time and decreases performance.Let's take a look at four specific hosting models: BizTalk Server, WAS + IIS + AppFabric Application Server Extensions, self-hosted services, in-process hosted services. BizTalk Server offers numerous features to increase reliability, availability and scalability. Unfortunately, many of these features require a fair amount of additional processing and thus, decrease performance because each extra processing step adds to the duration of the execution of a service capability. Figure 15 shows the processing steps of a standard BizTalk request....


2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006