Thursday, December 27, 2007

A Cellular Service company's SOA implementation

A leading Cellular network company in Israel, Partner Communications Company Ltd., provider of the Orange network in Israel, presented its SOA implementation in December 26th meeting of the SOA Forum of the Israeli Association of Information Processing.
I am moderating the forum since its imitation on March 2005. The forum meetings take place once in a month. The forum is opened for anyone involved or interested in SOA activities. Most of the meetings included presentations and discussions. The 16th meeting was exceptional: experts' panel on SOA Governance.

The presenter was Iddo Rachlewski (Infrastructure Applications Development Manager). Aharon Winder Partner's CTO, who joined us, answered the toughest questions asked by forum members.

The Telecom service industry business model and technological infrastructure is changing due to Web based IP phone services, Wireless & Cellular communication and the need to transfer new types of data in addition to voice.
The trends may be summarized in the following highlights:

The traditional Telco services are the leading candidates for reduced revenues. , as result of this threat they are forced to innovate. SOA is a key innovation enabler.
The new Telco companies (e.g. cellular services companies) are relatively new companies therefore their computing environments are relatively new so the technical difficulties of SOA transformation are less severe in comparison to Banks, Insurance Companies and the traditional Telcom services providers. These companies should innovate and work more efficiently due to the increasing competition.
No wonder that Telephone suppliers sector is one of the leaders in SOA implementation including some successful implementations (e.g. Verizon, Sprint-Nextel).

Partner's Service Bus Implementation

Partner's implementation is named Information framework (IF).
It is a Service Bus. The SOA implementation includes other complementary components.

The following bullets highlight the key elements describing the Service Bus:

  • Current version is based upon Tibco's EMS (JMS/RV) components with proprietary services developed in-house.

  • The IF is an evolving framework. Current version is 5.1 in production since April 2006. The first version was entirely proprietary and originated in 2001.

  • Approximately 400 services are using the IF

  • The Bus supports Synchronous interaction (Send-Receive) and Asynchronous interaction (Send and afterwards Receive). Most of the interactions are Synchronous. Asynchronous services are used for multiple requests.

Service Bus Architecture
The following image, included in the presentation depicts the Enterprise Service Bus (ESB) architecture

  • Every application (in-house Legacy applications, Oracle ERP, Oracle's Seibel CRM, Billing, oracle's Vantive, etc.) could consume and provide services via the Service Bus.

  • Consumers interface is by proprietary Wrappers. For each service there is dedicated wrapper written in the same technology as the service (Java, DotNet's C#, COM, C, PL/SQL) Tibco BusinessWorks is also a Service provider and Service Consumer. A Wrapper is a collection of code libraries. An encrypted configuration file is also included in each Wrapper. The configuration file identifies the consumer.

  • A SOAP interface and HTTP interface were added for standard based integration. Currently it is used by Application Packages using technologies for which no wrapper exists.

  • The internal architecture of IF includes "Application Server", DB Server and Management Server.

  • The DB Server includes two Oracle DB Engines. A proprietary mechanism is used for updating and synchronizing both databases. Oracle RAC was not an option when IF implemented due to unavailability or immaturity.

  • The internal architecture of the "Application Server" includes: Service Broker (SRB), Dynamic Service Interface (DSI) and a Token Manager (TM).
    Service Broker is responsible for registering service consumer requests, parsing inbound and outgoing parameters (if needed).
    SRB transfers the request to DSI. A limited prioritization is achieved by deciding which DSI instance will take care of the Consumer request, based on Encrypted Configuration file identifying the Consumer.
    DSI pass the request to the Service Provider.
    The TM is responsible for workload control. In case of no available token the Consumer request waits until another Consumer request release its token upon completion.

  • Management Server Components: Monitoring (Performance, Response Time, Load partially monitored by Tibco and in-house developed components and the information is passed to HP OpenView), Administration (e.g. defining new service), Statistics (by a Dashboard of Microsoft SQL Server 2005) and Logging (e.g. errors recording) connected to the company's central Log.
  • Multiple instances of each component are Deployed in order to avoid Single Point of Failure and for Workload Balancing (additional instances invoking or suspension of instances is dynamic, with no need to stopping IF).

  • Multiple Logical TEST environments are invoked in one Physical TEST environment by assigning different Configuration Files to different DSIs

  • Transferring definitions from TEST environment to Production environment is by pressing single key.

    Other Components
  • The process of defining new Service or changing a Service is based on a form filled by the applicant and approved by IF Administrator. It is possible to define relations between entities.
    The form is inserted in a company wide repository for asset management build in Visual Basic and Oracle database.

  • Run Time Service definitions are part of IF. It is an application developed in JSP under Tomcat Web Server


  • Data feeds to both Repositories are manual

  • Usually not all Service Users are registered in the Inventory (the first user identity is fed during service definition)

    My take:

  • SOA is not a one time project it is a journey. Expect for a gradual evolution.
    In Partner's case the evolution is manifested by the large number of versions (approximately one version each year). Each version enhancing the previous by functionality and some versions also improve Scalability and Performance.
    Partner is planning architectural, technological and functional changes for next versions.
    The evolutionary journey is not unique to Partner. For example, Standard Life one of IBM's noted SOA success stories architecture was changes significantly during different stage of their SOA implementation.

  • Leading Age is also Bleeding Age
    Early Adopters may not be able to use standard products because they were not mature enough. It is a trade off between gaining competitive advantage by using the new architecture versus more resources allocated for development and maintenance and a possible conversion to standard tools after they mature.
    In Partner's example planned next steps includes implementing additional Tibco's EMS components as well as a standard Repository or Registry.
    A known SOA Early Adopter is Credit Swiss, which deployed a CORBA based SOA in the 1990s. Credit Swiss is converting its Repository to a standard UDDI based and extended registry: Centrasite co-developed by Software AG and Fujitsu.

  • The implementation is technical with no Business people involvement. One consequence is Technical Services instead of Business Services.
    The services granularity could be less coarse granularity then needed. Due to the low granularity the number of services is high; there is more Complexity and management overhead increased.
    More importantly, Business and IT alignment is limited.
    Partner is in the beginning of a process of deploying tools for supporting Business Services and possibly Business Processes. Currently a limited function of supporting Composite services (termed IFBL) is implemented. Expended IFBL functionality could enable definition of Business Services.

  • The architecture is mainly SOA Integration architecture
    Mapping current applications functionality to Business SOA Services and gradually implementing Service Applications Architecture is an important missing part.

  • Enterprise Wide Processes deployment support by current Partner's technology is limited
    Addressing this issue is a future direction planned by Partner.

  • Application Server (in Partner If's terms) is an Integration Broker
    The term Application Server is not used for an infrastructure applications components container (e.g. IBM WebSphere, BEA WebLogic) but for Integration Broker). That the reason why I wrote "Application Server" and not Application Server in describing it.
    No wonder that Tibco tools were selected for SOA Integration, because Integration is Tibco's focus and strength. Tibco, the largest of the three EAI dedicated leading solutions (the other two WebMethods and SeeBeyond where acquired by other companies because of their SOA tools and capabilities) developed new generation of integration solutions which are SOA Integration tools and not a complete SOA framework.

  • I suspect that Reuse rate is not high
    My first impression is that Reuse rate probably is not high due to lack of dedicated SOA Registry and due to low Services Granularity.

  • Proprietary DB engine Fault Tolerance is not a preferred solution
    The tradeoffs between Oracle's RAC and the proprietary mechanism are more resources needed for maintaining the proprietary solution vs. the total independence between the two DB Engine instances in the proprietary solution. In my opinion database reliability is high and it will be higher in the future, so the trade off is in favor of the standard solution.

  • Despite the Considerations the implementation is impressive
    The technical architecture and implementation is impressive, especially if we take into account that it was originated in 2001 and based on In-House development. As far as the organizational maturity is concerned definition of Service management roles, Processes and culture is a significant milestone in the long road towards complete SOA implementation.

No comments:

Public Cloud Core Banking: Hype or Reality? - Revisited

  More than 4 years ago I was asked if Public Cloud Core Banking is a Hype or a Short Term Reality? If you had read the post, you would prob...