jump to navigation

SDP(Service Delivery Platform) Intro-from SOA perspective September 15, 2009

Posted by Terry.Cho in Architecture, SDP.
Tags: , , , ,
2 comments

Initiative

Common Telecom trend is Service Delivery Platform (SDP).

Telecom system has two challenges. Their business and technical platforms are changing very quickly. During few years they have been have a lot of platforms like Google Android, Microsoft Windows Mobile, Apple IPhone,Black berry,Symbian platforms. And service is extended from simple voice call & SMS to Multimedia service, application, Location based service etc. Following these business change they have to develop new application and integrate with legacy applications. Because telco has a lot of protocols and network layers (SIP,Paray-X,VoIP etc). Integration is getting more harder and complex. So they now need integrated and unified service platform to adopt business change quickly. This is the reason why SDP is required.

SDP is “Telco specific version of SOA”.

Concept of SDP is very simple. It exposes capability of system with unified interface. It reduces integration costs and let telco company to adopt new requirement quickly.

In addition by providing common services like billing,charging,logging, it removes duplication in implementation. This concept is exactly matched with SOA. So we can call SDP to “Telco specific version of SOA”. Only difference of SDP between traditional SOA is SDP requires network abstraction layer. In traditional SOA we had service enablement layer. It changes legacy protocol (SAP,MQ,Sieble) to unified SOA platform(Webservice etc.). It has been implemented with Adapters (JCA) or Other service enablement layers. In same way SDP has same abstraction layer. If traditional SOA communicated with legacy APPLICATION, SDP communicated with legacy NETWORK APPLICATION (SIP application, SMSC application, Paray-X based Application etc.). So in SDP there is network abstraction layer with network adapters.

Another difference between SDP and traditional SOA is SDP is B2C system (Service system). Traditional SOA is commonly designed for internal enterprise. SDP provides service to end user device (Mobile device, IP TV, Voip phone etc). So SDP covers more number of users than enterprise system and requires more faster response time. And message flow is more simpler than enterprise. As a result SDP has to have simple architecture to support fast response time, huge scalability.

Common architecture of SDP

Let’s think about common SDP architecture. SDP has 3 layers in the internal.

sdp

Ÿ   Service enablement layer

Network based application like SMS,VOIP has own protocol. Service enablement layer abstracts this network application and expose the capabilities with unified message protocol. By doing this user easily can use network based application without telco specific technology.

Service enablement layer also covers legacy integration. SDP can be integrated with legacy business system. For example Billing and Charging system in SDP can be integrated with Financial modules in ERP system. So Service enablement layer expose capability of legacy business system.

As a result the service enablement layer abstracts all of technical differences and let user can see the legacy components with same way.

Ÿ   Service component

Service component is software system that provides capabilities. Like SOA services. In SDP we have common services for telco system.

For example Contents Management, Billing, Charging & Rating, User Profile Management, Location Based Management. These components are implemented over specific vendor solution.

Commonly customer already has the service components. In that case abstract legacy service component and delegate the service in this service component layer.

Ÿ   Service exposure

Service components are exposed by this layer. This layer provides infrastructure of service.

For example it orchestrates existing services and make a new function. Mediate existing service. I will not describe this layer detail because this layer is same as traditional SOA concept (Orchestration with BPM, Mediation & single entry point with ESB etc)

Oracle solution mapping

Oracle has products that implements SDP.

SOA suite

For service exposure and service component development SOA suite is right for the requirements.

Oracle Service Bus is positioned for single entry point of SDP. And it enables service mediation. Complex service orchestration and long running process is implemented with Oracle BPEL/PM.

Oracle BPEL/PM also used for legacy system integration with various legacy adapters.

Oracle Coherence is used for storing & caching data. It is useful to manage & caching user profile data.

ODI is used for data provisioning between service components. And also can be used in contents provisioning.

Oracle WebLogic Server is used for component implementation with middleware features. It hosts component.

OCSG

It is used as network adapter in SDP. It supports specific telco protocol and expose the service to SOA platform. It also supports partner management and billing etc. Some capability can be duplicated with SOA platform or legacy business application. In that case based on business scenario, design should be considered.

OAAS

Like OCSG it enables network abstraction. But it just support SIP based application.

Conclusion

Common problem in SDP project is nobody can define SDP. SDP is de-facto standard. There is no standard reference architecture. So definition of SDP is different depends on industry. (Mobile, IPTV, VoIP etc.)

Think about SDP simple. SDP is telco specific SOA. It needs network adapter in addition to traditional SOA. And it is B2C system. It means it requires more concurrent user , faster response time and more simple architecture (message exchange format) than enterprise system. After understanding these characteristics of SDP, SDP is not hard to understand anymore.

New J2EE Architecture with Oracle Coherence. July 24, 2009

Posted by Terry.Cho in Architecture.
Tags: , , ,
add a comment

Intro

In case of Korea success rate of JEE based SI projects are getting lower. A one of the reason we can think about is framework. Most JEE projects are using framework like spring,hibernate,JAX-WS,XML framework etc. It helps us to leverage efficiency of implementation and provide more higher quality of architecture. In contrast it makes our system to more complicate. It causes a trouble in production system. Makes system hang, bring high cpu usage, memory usage etc
In this document, I will introduce WAS and coherence based architecture to raise up quality of JEE architecture.

Pain point of traditional JEE architecture
Traditional JEE architecture is like below.

1All of business logics are packaged into one application (1 WAR or 1 EAR file) including user interface. BIZ logic is implemented with EJB or POJO (Spring etc. POJO is current trend). UI is implemented Servlet/JSP of MVC framework.

This traditional JEE architecture has weak points.

Requires lots of redundant memory.
Current requirement for IT is being increased and complex is increased. So size of application and memory usage of application is being increased. The problem is JVM has a limitation in memory size. In 32bit JVM, Java can use usually maximum 1~1.5 GB Heap memory. Even if we can use 64bit JVM. We still have the problem in Garbage collection (GC) time. In full GC time, JVM suddenly stopped. If we increased the java heap size, the full GC time also increased. From JVM 1.4 there are many GC tuning options like Concurrent GC (CMS), Parallel GC. We are not free from the GC time.
In the traditional architecture all of biz logics are packaged into one application. Memory usage is getting increased. Especially it makes a burden in JVM permanent memory area. (The area that classes are loaded.)

Trouble affects other business Logic
Another problem of traditional JEE architecture is trouble propagation. Because all of business logics are running over same WAS instance, if some business logic makes a problem like high CPU usage, high memory usage affects the other business logic. It means if only one business logic has a problem, whole system can be stopped. Even if our weblogic server provides workmanager and clustering feature which prevent problem propagation, the problem from business logic can not be prevented

How to solve this pain point?
So how can we solve this problem? Answer is easy. Separate the business logics to separate WAS instance.

 2
It helps us by
Effective memory usage
Because only one business logic is deployed to one instance. Memory utilization is became low.

Prevent affection of problem between different business logic
Business logic is separated, so if one business logic has a problem, only the business WAS instance (or cluster) has a trouble. It doesn’t provide any effect to other business.

Efficient resource allocation
In addition separating business by WAS instance can make us to use hardware resource efficiently .
In Hard ware platform which supports CPU partitioning, system administrator can assign CPU to specific business logic. In traditional JEE architecture, it is hard to assign the resource to business. Because all business logics are running over same WAS instance, so cannot select process which CPU is assigned to.

So, even if the separation of business logic by WAS instance has a lot of architectural, why the traditional JEE architecture doesn’t implement it?
Problem comes from shared data & state information management. 3
In JEE architecture needs to share business data across the business logics or keep user state data by using Http Session. But if we separate business logic by WAS instance, it cannot share the session data and shared information across the WAS instances.
 It is a reason why our suggested architecture cannot be realized.

Separate business logic across WAS instance with Oracle coherence.
Finally with Oracle Coherence solution we can realize the architecture.
Coherence is Data Grid Solution which is not just Caching solution but is extendible, high performance, high availability large shared memory with multiple interface.
 Basically Coherence support HTTP session replication. It gives us more Http session capacity and solves the problem to sharing user state data. 4
By using coherence we can solve all of the pain point in traditional JEE architecture.
We get additional advantage from this architecture. We can plan a capacity based on business logic. (Assign WAS instance to specific biz logic based on capacity.)
 And it also give us freedom of redeployment. We don’t have to redeploy whole of WAS instance and don’t have to restart whole instances.

Conclusion
It is hard to win a deal with only WebLogic server in JEE application market. We need a approach to suggest integrated package of our product and especially with ARCHITECTURE which can solve pain point of our customers.
WebLogic and Coherence are very excellent product from before acquired by Oracle. Acquisition should provide advantage with chemical interactions. This is the case that can make the chemical interactions and will provide a higher position in biding with other vendors.