Installing Weblogic 10.3.2 on Fedora 11 is painless. All one has to do is the following -

• Download the jar (use with 64-bit JVM) or the pre-compiled binary (for 32-bit JVM)
• If you downloaded the pre-compiled binary, then install with the command -

chmod +x oepe111130_wls1032_linux32.bin && ./oepe111130_wls1032_linux32.bin

• If you downloaded the jar, then install with the command -

java -jar wls1032_generic.jar

After 5-10 minutes (depending on the speed of the machine) you should have Weblogic Server installed on the machine. However, there is one small quirk in the installation. If you were like me (chances of which are slim), and you opted for Custom install type, and selected Server Examples and your JVM with which launched the jar file happens to be one of Sun’s, then you get to enjoy the wrath of the JVM as it melts down while installing the server.

WLS 10.3.2 - Custom Install

WLS 10.3.2 - Choosing Components

WLS 10.3.2 - PermGen Error

I hated it when I saw the error. To further exacerbate the situation, the so called cleanup action built into the installer doesn’t do a good job of *undoing* whatever it had done till that point of time.

WLS 10.3.2 - Installation Fails here!

By the time it crashes, which happens exactly at 75% when the installer reports Creating Sample Domains… it has already installed the WL Server. Hence, before retrying the installation again, you have to uninstall the product first.

The solution is pretty simple. Start the JVM with a bit more of PermGen Space, say, 128M (instead of the default, which happens to be a maximum of 84M in 1.6.0_18 JVM in Linux)

java -XX:MaxPermSize=128m -jar wls1032_generic.jar

I tried the installation with JRockit and tried to see how much of PermGen the installation requires and it turns out to be around ~100M.

WLS 10.3.2 - Non-Heap Usage

Oracle’s documentation (which is improving these days!) has no information (so far) on the PermGen requirement. However, I’m just wondering – “Is it so difficult to actually check before the installer starts and figure out how much is the Max. PermGen size?”. Shouldn’t the following piece of code suffice to avoid the suffering?

...
/* acquire runtime information using the JMX API */
Iterator mPoolMXBeans =
	ManagementFactory.getMemoryPoolMXBeans().iterator();

while(mPoolMXBeans.hasNext()) {
	MemoryPoolMXBean mPoolMXBean = mPoolMXBeans.next();

	System.out.format("%18s  %20s  %5.2f MB\n",
			mPoolMXBean.getType(),
			mPoolMXBean.getName(),
			(mPoolMXBean.getUsage().getMax() / (1024.0*1024.0)));

	if (mPoolMXBean.getName().equalsIgnoreCase("CMS Perm Gen"))
		if (mPoolMXBean.getUsage().getMax() < 104857600)
			System.out.println("\nWarning: " +
					"Current size for MaxPermGen is less than " +
					"the recommended size of 100M");
...


       Heap memory        Par Eden Space  15.63 MB
       Heap memory    Par Survivor Space   2.56 MB
       Heap memory           CMS Old Gen  63.25 MB
   Non-heap memory          CMS Perm Gen  84.00 MB

Warning: Current size for MaxPermGen is less than the recommended size of 100M

Found a really interesting post from Kotaku today about a procedural city tech demo. It seems like they hit a lot of the high points: procedural city interior and exteriors, destruction, and instanced object placement. What is unclear to me (their website is down) is if they plan to license this as middleware or if it is purely a tech demo for a new game. It appears to be middleware, since it has its own name and company associated with it. If so, the real key is how easy it is to create content and tweak the parameters. Most of the existing procedural city middleware engines fall down on this account. Admittedly this is a really complex problem, but procedural rulesets do not come easily to most artists and designers and to be useful to games you have to get them involved. A completely procedural ghost town city is only cool for a tech demo, not a game.

Kotaku: Will Crysis2 Be Able To Render NYC Like This?

If you’re interested in procedural city generation, Digital Urban is a great resource.
Some procedural city middleware:
CityEngine
CityScape

I spent a couple of hours today listening to Oracle talk about the long-awaited integration with Sun Microsystems. A real end of an era and beginning of a new one. What does this mean for Oracle? Whatever you might think about Oracle, you have to give the company credit for successfully integrating the 60 companies it has purchased over the past few years. Having watched hundreds and perhaps thousands of acquisitions over the last few decades, it is clear that integration is hard. There are overlapping technologies, teams, cultures, and egos. Oracle has successfully managed to leverage the IP from its acquisitions to support its business goals. For example, it has kept packaged software customers happy by improving the software. Peoplesoft customers, for example, were able to continue to use the software they had become dependent on in primarily the same way as before the acquisition. In some cases, the quality of the software actually improved dramatically. The path has been more complicated with the various middleware and infrastructure platforms the company has acquired over the years because of overlapping functionality.

The acquisition of Sun Microsystems is the biggest game changer for Oracle since the acquisition of PeopleSoft. There is little doubt that Sun has significant software and hardware IP that will be very important in defining Oracle in the 21st century. But I don’t expect this to be a simple journey. Here are the five key issues that I think will be tricky for Oracle to navigate. Obviously, this is not a complete list but it is a start.

Issue One: Can Oracle recreate the mainframe world? The mainframe is dead — long live the mainframe. Oracle has a new fondness for the mainframe and what that model could represent. So, if you combine Sun’s hardware, networking layer, storage, security, packaged applications, middleware into a package do you get to own total share of a customer’s wallet? That is the idea. Oracle management has determined that IBM had the right ideas in the 1960s — everything was nicely integrated and the customer never had to worry about the pieces working together.
Issue Two: Can you package everything together and still be an open platform? To its credit, Oracle has build its software on standards such as Unix/Linux, XML, Java, etc. So, can you have it both ways? Can you claim openness when the platform itself is hermetically sealed? I think it may be a stretch. In order to accomplish this goal, Oracle would have to have well-defined and published APIs. It would have to be able to certify that with these APIs the integrated platform won’t be broken. Not an easy task.
Issue Three: Can you manage a complex computing environment? Computing environments get complicated because there are so many moving parts. There are configurations that change; software gets patched; new operating system versions are introduced; emerging technology enters and messes up the well established environment. Oracle would like to automate the process of managing this process for customers. It is an appealing idea since configuration problems, missing links, and poor testing are often responsible for many of the outages in computing environments today. Will customers be willing to have this type of integrated environment controlled and managed by a single vendor? Some customers will be happy to turn over these headaches. Others may have too much legacy or want to work with a variety of vendors. This is not a new dilemma for customers. Customers have long had to rationalize the benefits of a single source of technology against the risks of being locked in.
Issue Four: Can you teach an old dog new tricks? Can Oracle really be a hardware vendor? Clearly, Sun continues to be a leader in hardware despite its diminished fortunes. But as anyone who has ventured into the hardware world knows, hardware is a tough, brutal game. In fact, it is the inverse of software. Software takes many cycles to reach maturation. It needs to be tweaked and finessed. However, once it is in place it has a long, long life. The old saying goes, old software never dies. The same cannot be said for hardware. Hardware has a much straighter line to maturity. It is developed, designed, and delivered to the market. Sometimes it leapfrogs the competition enough that it has a long and very profitable life. Other times, it hits the market at the end of a cycle when a new more innovative player enters the market. The culmination of all the work and effort can be short as something new comes along at the right place at the right time. It is often a lot easier to get rid of hardware than software. The computer industry is littered with the corpses of failed hardware platforms that started with great fanfare and then faded away quickly. Will Oracle be successful with hardware? It will depend on how really good the company is in transforming its DNA.
Issue Five. Are customers ready to embrace Oracle’s brave new world? Oracle’s strategy is a good one — if you are Oracle. But what about for customers? And what about for partners? Customers need to understand the long-term implication and tradeoffs in buying into Oracle’s integrated approach to its platform. It will clearly mean fewer moving parts to worry about. It will mean one phone call and no finger pointing. However, customers have to understand the type of leverage that single company will have in terms of contract terms and conditions. And what about partners? How does an independent software vendor or a channel partner participate within the new Oracle? Is there room? What type of testing and preparation will be required to play?

Deployment of JBoss Enterprise BRMS improves scalability, efficiency and risk management for investment company

Raleigh, NC – January 20, 2010 – Red Hat (NYSE: RHT), the world’s leading provider of open source solutions, today announced that Millennium Global Investments (MGI), a specialist in developing and managing alternative investment products for institutional investors, has selected JBoss Enterprise BRMS (Business Rules Management System) for its mission-critical business rules repository.

London-based MGI wanted to improve the flexibility of its compliance system so that its business and trade rules could be revised and adjusted rapidly within a managed environment. MGI selected JBoss Enterprise BRMS to bring business rules into a managed environment, standardise business rules and support the scalability of the business.

The transparency of the new repository enables MGI business users to gain access to detailed information about why certain rules may prevent trading. This access improves business users’ efficiency and reduces the number of queries sent to MGI’s IT organisation. The transparent business rules repository is also an essential part of MGI’s risk management strategy

“Red Hat’s flexible subscription terms for JBoss Enterprise Middleware allowed us to deploy only the components needed for the new platform and to avoid vendor lock-in. Unlike other vendors, Red Hat offers the ability to support other applications of the rules engine, be it market signal monitoring or algorithmic trading,” said Richard Macaskill, managing director, IT & Systems Development, MGI. “We were very pleased with the level of support Red Hat provided during the new business rules repository’s development. We are extremely satisfied to have deployed an integrated business rules platform that has improved our efficiency and ability to manage risk.”

JBoss Enterprise Business Rules Management System (BRMS) is an open source business rules solution that enables easy business policy and rules development, access, and management. JBoss Enterprise BRMS allows customers to reduce development time to update applications and processes with the latest business rules and policies.

“We are delighted with the positive feedback from MGI on its deployment of JBoss Enterprise BRMS. We are seeing further momentum of JBoss Enterprise BRMS as the enterprise continues to drive innovation through open source middleware,” said Pierre Fricke, Director, SOA Products, Red Hat. “Automating business decisions with JBoss Enterprise BRMS can help a business run faster and enable business process stakeholders to rapidly implement change. This is the kind of agility that enterprise deployments demand in today’s marketplace.”

For more information about Red Hat, visit www.redhat.com. For more news, more often, visit www.press.redhat.com.

About Red Hat, Inc.
Red Hat, the world’s leading provider of open source solutions and a component of the S&P 500, is headquartered in Raleigh, NC with over 65 offices spanning the globe. CIOs ranked Red Hat as one of the top vendors delivering value in Enterprise Software for six consecutive years in the CIO Insight Magazine Vendor Value survey. Red Hat provides high-quality, affordable technology with its operating system platform, Red Hat Enterprise Linux, together with virtualization, applications, management and Services Oriented Architecture (SOA) solutions, including Red Hat Enterprise Virtualization and JBoss Enterprise Middleware. Red Hat also offers support, training and consulting services to its customers worldwide. Learn more: http://www.redhat.com.

Forward-Looking Statements
Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to delays or reductions in information technology spending, the integration of acquisitions and the ability to market successfully acquired technologies and products; the ability of the Company to effectively compete; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; uncertainty and adverse results in litigation and related settlements, and changes in and a dependence on key personnel, as well as other factors contained in our most recent Quarterly Report on Form 10-Q (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations”. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic conditions, and governmental and public policy changes. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of the press release.

© 2009 Red Hat, Inc. Red Hat, the Shadowman logo and JBoss are registered trademarks of Red Hat, Inc. in the U.S. and other countries. Linux is a registered trademark of Linus Torvalds.

MOBILWARE 2010
Third International Conference on MOBILe Wireless MiddleWARE, Operating Systems, and Applications

Sponsored by ICST, technically co-sponsored by Create-Net
Proceedings published in the Springer LNICST Series
Chicago, USA, June 30-July 2, 2010 – http://www.mobilware.org

Extended versions of selected best papers will be published in the Springer Mobile Networks and Applications (MONET) Journal
and in the Springer Journal of Network and Systems Management.

Deadline for workshop proposal submission: February 1, 2010
Deadline for paper submission: February 1, 2010

The advances in wireless communication technologies and the
proliferation of mobile devices have enabled the realization of intelligent environments for people to communicate with each other, interact with information-processing devices, and receive a wide range of mobile wireless services through various types of networks and systems everywhere, anytime. A key enabler of this pervasive and ubiquitous connectivity environment is the advancement of software technology in various communication sectors, ranging from communication middleware and operating systems to networking protocols and applications.
The 2010 edition of MOBILWARE will be the first time to move out of Europe. We plan to further diversify the representation of key organizers and expand the community of industrial and academic researchers fruitfully exchanging novel ideas and operational experiences in the field. MOBILWARE is dedicated to addressing emerging topics and challenges in various mobile wireless software-related areas. The scope of the conference is the design, implementation, deployment, and evaluation of middleware, operating systems, and applications for computing and communications in mobile wireless systems. It aims to provide a high profile, leading edge forum for researchers, engineers, and standards developers to present their latest research activities, techniques, and experiences in the area of software technology for mobile wireless systems.

PAPERS: Original and unpublished research achievements in various aspects of middleware/operating systems/applications for mobile computing and networking are solicited. Areas of interest include, but are not limited to:
* Integration of heterogeneous wired and wireless networks
* QoS awareness, adaptation, and fault-tolerance of mobile services * Opportunistic and delay-tolerant mobile and wireless networking * Location-aware and context-aware networking and computing
* Energy-efficient applications and services
* Mobility and handoff management
* Location and tracking supports and services
* Mobility-aware service discovery, management, and delivery * Agent technologies for mobile systems and services
* Human-computer interface and portable 3D graphics for mobile devices * Novel applications and communication protocols for wireless sensor networks, vehicular networks, and home networks
* Modeling, simulation, and performance evaluation of mobile wireless systems and services
* Trustworthiness, security, and privacy of mobile and wireless systems

WORKSHOPS/TUTORIALS:
Proposals for workshops/tutorials are solicited. Potential organizers are requested to submit a proposal of at most 5 pages, including a biographical sketch of each proponent, to the Workshop/Tutorial Chair by February 1, 2010 (form deadline). Proposal evaluation will be based on proponents’ expertise and relevance of the subject matter. Workshop proceedings will be published in the Springer LNICST series, as the proceedings of the main conf.

SUBMISSION INSTRUCTIONS:
All papers and workshop/tutorial proposal submissions will be handled electronically. Please visit the MyReview paper submission server at < http://rs.cs.iastate.edu/MobilWare2010/
> or the conference Website at < http://www.mobilware.org > for detailed submission requirements and procedures.

PUBLICATION:
All submitted papers will be rigorously reviewed by TPC members and invited reviewers. All accepted papers will be published in the novel Springer Lecture Notes of ICST (LNICST) series and be included in major article indexing services. Extended versions of selected best papers from MOBILWARE’10 will be published in a dedicated special issue of the Springer Mobile Networks and Applications (MONET) Journal and recommended for publication (fast review track) in the Springer Journal of Network and Systems Management.

IMPORTANT DATES:
Workshop/Tutorial Proposal Due Date: February 1, 2010
Paper Submission Due Date: February 1, 2010
Notification of Acceptance: April 1, 2010
Camera Ready Versions Due: April 20, 2010

STEERING COMMITTEE
Imrich Chlamtac (Chair), Create-Net, Italy
Paolo Bellavista, Univ. Bologna, Italy
Carl K. Chang, Iowa State Univ., USA

GENERAL CHAIRS
Paolo Bellavista, Univ. Bologna, Italy
Carl K. Chang, Iowa State Univ., USA

TECH. PROGRAM COMMITTEE CHAIRS
Ying Cai, Iowa State Univ.., USA
Minglu Li, Shanghai Jiaotong Univ., China
Thomas Magedanz, Fraunhofer FOKUS, Germany

WORKSHOP/TUTORIAL CHAIR
Jinchun Xia, San Jose State Univ., USA

LOCAL CHAIRS
Jennifer Juehring, Iowa State Univ., USA
Laurel Tweed, Iowa State Univ., USA

WEB AND PROCEEDINGS CHAIR
Carlo Giannelli, Univ. Bologna, Italy

TECHNICAL PROGRAM COMMITTEE (to be confirmed and extended)
J.M. Bonnin, Inst. Telecom/Telecom Bretagne, France
C. Borcea, NJIT Univ., USA
J.J. Bu , Zhejiang Univ., China
R.H. Campbell, UIUC, USA
J. Cao, Polyt. Univ., Hong Kong
Z. Chen, Florida Int. Univ., USA
L. Cheng, Lehigh Univ. Bethlehem, USA
A. Chibani, Paris 12 Univ., France
I. Demeure, ENST, Telecom ParisTech, France
A. Fasbender, Ericsson GmbH, Germany
X. Fu, Univ. of Massachusetts Lowell, USA
A. Gavras, Eurescom, Germany
M. Gerla, Univ. California at Los Angeles, USA
R. Glitho, Concordia Univ. Montreal, Canada
J. Govil, CISCO, USA
M. Gunes, FU Berlin, Germany
C. Hesselman, Novay, the Netherlands
R. Hill, Indiana University, USA
S. Holtel, Vodafone Group R&D, Germany
F. Hong, Ocean Univ. of China, P. R. China
C.-L. Hu, National Central Univ., Taiwan
L. Iftode, Rutgers Univ., USA
A. Jaokar, Futuretext, UK
W. Jiang, Huazhong Univ. of Sci. & Tech., China
C. Julien, Univ. of Texas at Austin, USA
T.G. Kanter, Mid Sweden Univ., Sweden
P.J. Keleher, Univ. Maryland, USA
W.-S. Ku, Auburn Univ., USA
Y. Lan, Northeastern Univ., China
P. Langendoerfer, IHP, Germany
X. (Cindy) Li, Univ. N. Carolina Pembroke, USA
X. Li, Oklahoma State Univ., USA
D. Maggiorini, Univ. of Milano, Italy
R. Minerva, Telecom Italia, Italy
P. Nixon, Univ. College Dublin, Ireland
J.K. Nurminen, Nokia, Finland
H. Ohsaki, Osaka Univ., Japan
G. Ormazabal, Verizon Laboratories, USA
J. Payton, Univ. North Carolina at Charlotte, USA
S. Pandey, CISCO Systems Inc., USA
F. Ren, Tsinghua Univ., China
K. (Quinn) Ren, Illinois Inst. Technology, USA
R. Schwaiger, Deutsche Telekom Labs, Germany
J. Song, KAIST, Korea
L. Sun, Chinese Academy of Sciences, China
W. Sun, Fudan Univ., China
J. Taheri, Univ. Sydney, Australia
X. Tao, Nanjing Univ., China
A. Tripathi, Univ. Minnesota, USA
N. Ventura, Univ. Cape Town, South Africa
Xiaodong Wang, Nat. Univ. Defense Tech., China
Xinbing Wang, Shanghai Jiaotong Univ., China
B. Xu, Tsinghua Univ., China
G. Xue, Shanghai Jiaotong Univ., China
W. Xue, Tsinghua Univ., China
M.A. Youssef, Nile Univ., Egypt
F. Zambonelli, Univ. Modena e R. Emilia, Italy
L. Zhang, Indiana Univ. S. Bend, USA
Q. Zheng, Xian Jiaotong Univ., China
Y. Zhu, Shanghai Jiaotong Univ., China

Internet of Things (IOT) is one of the emerging technology trends. Some indications of useful applications of IOT are given by the Hydra project team.

This article describes many areas including Agriculture which can benefit from this initiative. Hydra opens up several possibilities, especially for innovative social applications, a ripe area for student projects. You can get more information on such exciting projects from ICT Results.

Posted via email from Dorai’s LinkLog

The market (ka-ching!, ka-ching!) for transaction-centric enterprise IT (Information Technology) systems dwarfs that for real-time, data-centric sensor control systems. Because of this market disparity, the lion’s share of investment dollars is naturally and rightfully allocated to creating new software technologies that facilitate the efficient development of behemoth enterprise IT systems.

I work in an industry that develops and sells distributed, real-time, data-centric sensor systems and it frustrates me to no end when people don’t “see” (or are ignorant of) the difference between the domains. With innocence, and unfortunately, ignorance embedded in their psyche, these people try to jam-fit risky, transaction-centric technologies into data-centric sensor system designs. By risky, I mean an elevated chance of failing to meet scalability, real-time throughput and latency requirements that are much more stringent for data-centric systems than they are for most transaction-centric systems. Attributes like scalability, latency, capacity, and throughput are usually only measurable after a large investment has been made in the system development. To add salt to the wound, re-architecting a system after the mistake is discovered and ( more  importantly) acknowledged, delays release and consumes resources by amounts that can seriously damage a company’s long term viability.

As an example, consider the  CORBA and DDS OMG standard middleware technologies. CORBA was initially designed (by committee) from scratch to accommodate the development of big, distributed, client-server, transaction-centric systems. Thus, minimizing latency and maximizing throughout were not the major design drivers in its definition and development. DDS was designed to accommodate the development of big, distributed, publisher-subscriber, data-centric systems. It was not designed by a committee of competing vendors each eager to throw their pet features into a fragmented, overly complex quagmire. DDS was derived from the merger of two fielded and proven implementations, one by Thales (distributed naval shipboard sensor control systems) and the other by RTI (distributed robotic sensor and control systems). In contrast, as a well meaning attempt to be all things to all people, publish-subscribe capability was tacked on to the CORBA beast after the fact. Meanwhile, DDS has remained leaned and mean and because of the architecture busting risk for the types of applications it targets, no client-server capability has been back-fitted into its design.

Consider the example distributed, data-centric, sensor system application layer design below. If this application sits on top of a DDS middleware layer, there is no “intrusion” of a (single point of failure) CORBA ORB into the application layer. Each application layer system component simply boots up, subscribes to the topic (message) streams it needs, starts crunching them with it’s app-specific algorithms, and publishes its own topic instances (messages) to the other system components that have subscribed to the topic in order to do their own crunching and publishing.

Now consider a CORBA-based instantiation of this application example (refer to the figure below). Because of the CORBA requirement for each system component to register with an all knowing centralized ORB (Object Request Broker) authority, CORBA “leaks” into the application layer. After registration, and after each service has found (via post-registration ORB lookup) the other services it needs to subscribe to, the ORB can disappear from the application layer – until a crash occurs and the system gets hosed. DDS avoids leakage into the value-added application layer by avoiding the centralized ORB concept and providing for fully distributed, under-the-covers, “auto-discovery” of publishers and subscribers. No DDS application service has to interact with a registrar at startup to find other components – it only has to tell DDS which topics it will publish which topics that it needs to subscribe to. Each CORBA component has to know about the topics it needs and it needs to find the services it needs to subscribe to.

The more a system is required to accommodate future growth, the more inapplicable an ORB-based architecture is. Relative to a fully distributed coordination  auto-discovery mechanism that’s transparent to each application component, attempting to jam fit a single, centralized coordinator into a large scale distributed system so that the components can find each other reduces robustness and increases long term maintenance costs .  It’s a bummer when the leadership at a company that is trying to increase profitability lets that happen.

In the previous post, I have told you how to make a counter server in C and then call its functionalities through RPC calls.

In Erlang it is defined a module called rpc. It provides services which are similar to remote procedure calls. It also contains broadcast facilities and parallel evaluators. As I told you also in the previous blog a remote procedure call is a method to call a function on a remote node and collect the answer.

The most important function in this module is rpc:call(Node, Module, Function, Arguments), it executes the specific function defined in the specific module, with the specified arguments on the node Node and returns the corresponding that can be either the return value, or a tupla of the form {badrpc, Reason}.

Sounds easy! Thus let’s start by coding our counter server:

%%%-------------------------------------------------------------------
%%% File    : counter_svr.erl
%%% Author  : XXXXX
%%% Description : A counter server
%%%
%%% Created : 19 Dec 2009 by XXXXX
%%%-------------------------------------------------------------------
-module(counter_svr).

-behaviour(gen_server).

%% API
-export([start_link/0,count/0]).

%% gen_server callbacks
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
	 terminate/2, code_change/3]).

-record(state, {counter=0}).

%%====================================================================
%% API
%%====================================================================
%%--------------------------------------------------------------------
%% Function: start_link() -> {ok,Pid} | ignore | {error,Error}
%% Description: Starts the server
%%--------------------------------------------------------------------
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

%%====================================================================
%% gen_server callbacks
%%====================================================================

%%--------------------------------------------------------------------
%% Function: init(Args) -> {ok, State} |
%%                         {ok, State, Timeout} |
%%                         ignore               |
%%                         {stop, Reason}
%% Description: Initiates the server
%%--------------------------------------------------------------------
init([]) ->
    {ok, #state{}}.

%%--------------------------------------------------------------------
%% Function: %% handle_call(Request, From, State) -> {reply, Reply, State} |
%%                                      {reply, Reply, State, Timeout} |
%%                                      {noreply, State} |
%%                                      {noreply, State, Timeout} |
%%                                      {stop, Reason, Reply, State} |
%%                                      {stop, Reason, State}
%% Description: Handling call messages
%%--------------------------------------------------------------------
handle_call(count, _From, State) ->
    Reply = State#state.counter + 1,
    NewState = #state{counter=Reply},
    {reply, Reply, NewState};

handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.

%%--------------------------------------------------------------------
%% Function: handle_cast(Msg, State) -> {noreply, State} |
%%                                      {noreply, State, Timeout} |
%%                                      {stop, Reason, State}
%% Description: Handling cast messages
%%--------------------------------------------------------------------
handle_cast(_Msg, State) ->
    {noreply, State}.

%%--------------------------------------------------------------------
%% Function: handle_info(Info, State) -> {noreply, State} |
%%                                       {noreply, State, Timeout} |
%%                                       {stop, Reason, State}
%% Description: Handling all non call/cast messages
%%--------------------------------------------------------------------
handle_info(_Info, State) ->
    {noreply, State}.

%%--------------------------------------------------------------------
%% Function: terminate(Reason, State) -> void()
%% Description: This function is called by a gen_server when it is about to
%% terminate. It should be the opposite of Module:init/1 and do any necessary
%% cleaning up. When it returns, the gen_server terminates with Reason.
%% The return value is ignored.
%%--------------------------------------------------------------------
terminate(_Reason, _State) ->
    ok.

%%--------------------------------------------------------------------
%% Func: code_change(OldVsn, State, Extra) -> {ok, NewState}
%% Description: Convert process state when code is changed
%%--------------------------------------------------------------------
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

%%--------------------------------------------------------------------
%%% Internal functions
%%--------------------------------------------------------------------
count() ->
    gen_server:call(?MODULE, count).

As you can see I used the template of a gen_server for my implementation of the counter server. The value of the counter is stored inside its state, and it starts with the value of 0. The server handles a specific call that is aimed to retrieve the counter from the server, increment it by one and return that value to the client.  In the internal functions space, I defined a function named count that performs the specific call to the gen_server.

Easy, isn’t it?

Now we have only to start the server in a Erlang node (we name it server@ourlocalhost).

bellerofonte@pegaso:~$ erl -sname server@pegaso
Erlang R13B02 (erts-5.7.3)
Eshell V5.7.3  (abort with ^G)
(server@pegaso)1> counter_svr:start_link().
{ok,<0.40.0>}

At this point the server is up an running on our Erlang node, so the only thing left is to start another Erlang node (or many nodes) and perform some RPC from these. First of all we start the second node, you should know that this node must be connected to the previous one and share with it the same cookie, if you don’t see Erlang User Guide for more info. In brief I can tell you that you can check whether two nodes are connected by calling in one node the function net:ping(‘othernode@host’) that gives back a ‘pong’ if they are connected, or a ‘pang’ if they are not…..moreover you can check if the nodes have the same cookie by calling in both nodes the function erlang:get_cookie() (otherwise you can set the cookie with erlang:set_cookie(Cookie). Coming back to our discussion on rpc, inside the second node we call the function through RPC by using as stated above rpc:call(Node, Module, Function, Arguments)…in our specific case Node is the node where the server is running, Module is the module implementing the server, Function is the function that retrieves the counter and increments it and Arguments is an empty list, since the function takes no arguments.

bellerofonte@pegaso:~$ erl -sname client@pegaso
Erlang R13B02 (erts-5.7.3)
Eshell V5.7.3  (abort with ^G)
(client@pegaso)1> rpc:call('server@pegaso', counter_svr, count, []).
1
(client@pegaso)2> rpc:call('server@pegaso', counter_svr, count, []).
2
(client@pegaso)3> rpc:call('server@pegaso', counter_svr, count, []).
3
(client@pegaso)4> rpc:call('server@pegaso', counter_svr, count, []).
4

As you may see in the example I posted above, multiple RPCs to our server, give back the result expected…..

In my opinion this comparison explains why I still prefer using Erlang when talking or coding distributed systems!

In the last weeks I have been geeking a while with Remote Procedure Calls.

RPCs were invented at Sun Microsystems in the 80s, and can be seen as “normal” procedure calls on a distributed system. The concept behind RPCs is the following: you don’t have to declare the function you want to use in your client, you can declare that function on a server and than if you invoke it, a so-called “middleware” is going to forward the request from the client to the server, where the function is executed and the result is returned back to the client.

Since I’m still confident that Erlang is much more better than C for distributed systems I’ll try to code in both languages a server that keeps a counter in it, each time a client calls via RPC a function it will increment that value.

In C I could do it coding three files. Let’s start with the first: a file (counter.x) with the specifications of the service provided by the functions that can be called remotely. The specifications must be converted to stubs and header files for the middleware using the tool rpcgen (we will se it later).

When you write the specifications, you must identify the functions that are going to be called remotely. The functions must specify the return type and arguments. For every function (called RPC), you must assign an ID and must include it in a program that must be uniquely referred to by an ID and a version.

Our counter.x may look like this:

program COUNTERPROG {
  version COUNTERVERS {
    int COUNTER() = 1;
  } = 1;
} = 0x20000001;

where the remote procedure COUNTER has ID 1 and is included in the version 1 of the program COUNTERPROG. The ID of the program is 0×20000001.

After that you must write the procedure code as if you would write it locally, but with slight changes. The procedure must use a conventional name PROGRAM_VERSION_svc (in our case counter_1_svc). The procedure uses pointers to return the result and receive the arguments.
One more argument is required to identify the execution context.

Thus in our case we can create a file named counter_proc.c of the following form:

#include <stdio.h>
#include "counter.h"
int *counter_1_svc(void *msg, struct svc_req *req)
{
  static int result = 0;
  result++;
  return (&result);
}

The header file counter.h is one of the files generated by rpcgen. As you can see we create a STATIC variable result that lives in the space allocated for static variables so that it can survive when the execution of the fuction ends. Whenever the function is called we increment that value and return the address of that static variable.

Now we have to write to client! This client, before performing the remote call to the server, must connect to it. Then, after the call it can disconnect. The connection is done using the function clnt_create(server address, program id, program version, transport protocol). The disconnection is done using the function clnt_destroy().

Let’s create a file called rcounter.c of the following form:

#include <stdio.h>
#include <string.h>
#include "counter.h"
int main(int argc, char **argv)
{
  CLIENT *clnt;
  int *result;
  char *server;
  // try to get the server address from command line
  if (argc != 2) {
    fprintf(stderr, "Usage is the following: %s server\n", argv[0]);
    return -1;
  }
  server = argv[1];
  // create the client
  clnt = clnt_create(server, COUNTERPROG, COUNTERVERS, "udp"); //udp may be set to tcp
  if (clnt == NULL) {
    clnt_pcreateerror(server);
    return -1;
  }
  // call the function
  result = counter_1(NULL, clnt);
  if (result == NULL) {
    clnt_perror(clnt, server);
    return -1;
  }
  // print the value obtained from the call
  printf("The value of the counter is %d\n", *result);
  // destroy the client
  clnt_destroy(clnt);
  return 0;
}

Now let’s compile all the files:

bellerofonte@pegaso:~$ rpcgen counter.x

This generates: counter.h counter_svc.c counter_clnt.c

bellerofonte@pegaso:~$ gcc counter_svc.c counter_proc.c -o counter_svr -lnsl
bellerofonte@pegaso:~$ gcc counter_clnt.c rcounter.c -o counter_clt -lnsl

and execute them:

bellerofonte@pegaso:~$ ./counter_svr &
[1] 4898
bellerofonte@pegaso:~$ ./counter_clt localhost
Counter is 1
bellerofonte@pegaso:~$ ./counter_clt localhost
Counter is 2
bellerofonte@pegaso:~$ kill -9 4898

As you can see at every call the value returned is the previous one plus 1 (starting from zero).

I killed the server in the end because I started it in background mode…if you want you can run the two files in different shells to avoid this.

Ok, this post starts being long…so for the Erlang code I will open a new one

This is my old blog on the JBoss Matrix…

http://blogs.jboss.org/blog/pfricke/

I embarked on an adventure last month, leaving my old job after eighteen months to re-enter the world of consulting.

When I started at the old firm, I thought of myself as just a computer programmer. I had reached a plateau at the home-building firm where I’d cut my teeth and had arrived at that position ready for a new challenge.

The first week, I was asked to add an enhancement to an application I hadn’t seen before. They wanted the capability to alter an HTML control’s text via an XML configuration file. I turned it around quickly, and developed a good reputation.

It turned out that the department had just started using agile and were having trouble getting over the hump. At my prior position, we’d been doing Scrum for a while and I said I could get it going there. They gave me a team of eager people and we were wildly successful. We got the rest of the department on Scrum, and our department managed to nearly double our output. I became a key part of the team, someone whom management and fellow developers looked to for leadership.

Sadly, it was not to last. We sold our product to a large customer overseas, and we were not ready to support that customer as though the product were a custom application. Meanwhile, the company I worked for had been acquired just as I hired on, and this overseas deployment brought scrutiny and change from the main office. As their culture and decisions supplanted our office, our agile ways and product vision met with more resistance.

I believe that friction led to some key leadership departures, and the magic that dwelt in that place dwindled away. I was even given the role of lead architect, but I quickly came to realize it was a quixotic quest and one not to be combined with a promotion. So, I sought my fortunes elsewhere.

My current position is a stark contrast to my architect position. My sphere of influence went from office-wide to cubicle-wide overnight. Most of my co-workers work in another state, and I feel isolated from the people I work beside.

The work is somewhat different from what I expected, too. I imagined technical challenges in decommissioning a certain piece of legacy middleware and replacing it with an adapter web service. We started by building a mapper service that can convert a type to an arbitrary type driven by an XML specification, for use on request and response objects.

A week in, I realized I was building something akin to ObjectBuilder or an IoC container. The constraints of the project hampered some tasks. For example, I had to fight to use unit tests, and I was asked to deliver a solution without any third-party libraries such as MbUnit. I was limited to VS 2005, C# 2.0, and ASMX web services.

I did have some latitude, though. I architected the whole solution. In the beginning, I though I was going to have to implement my own version of LinqBridge, but I found that the Composite and Decorator patterns led to some simple structures with powerful functionality.

I used TDD and ReSharper to amaze my co-worker with my quick delivery and robust code. My tests are in MbUnit, and I’m glad to report that during the development effort, the solution never dipped below 90% coverage as reported by PartCover. Initially, I didn’t have access to their source control (VSS), so I installed Subversion locally and used Tortoise SVN to write to a repository on my network drive, which is where my tests still safely reside.

Sadly, though, I did not run into the kind of design challenges I was hungry for in building this component. However, I must say that I’ve leveraged the Reflection library much deeper than I had before. The most interesting piece was conditional mappings, which I implemented as delegates.

Going forward, it looks like I will be doing analysis of their legacy Java systems, detailing their old object and data models. Once done, systems analysts will be able to map the legacy application to the new infrastructure, and we can create an adapter web service with the help of that mapper component we wrote.

Just as I was about to start figuring out my next six predictions for 2010 I had to stop the presses and focus on IBM’s latest acquisition. IBM just announced this morning that it has purchased Lombardi which focuses on Business Process Management software. Lombardi is one of the independent leaders in the market as well as a strong IBM business partner. The obvious question is why would IBM need yet another business process management platform? After all, IBM has a large portfolio of business process management software — some homegrown and some from various acquisitions such as Filenet, ILOG, and Webify. I think that the answer is actually quite straight forward. Lombardi’s offerings are used extensively in business units, by business management to codify complex processes that are at the heart of streamlining how businesses are able to differentiate themselves. Clearly, IBM has recognized the importance of Lombardi to its customers since it has had a long standing partnership with the company.  I think there are two reasons that this acquisition are significant beyond the need to provide direct support for business management. The ability to use Lombardi’s technology to sell more WebSphere offerings and the connection of business process to IBM’s Smarter Planet initiative are the two issues that stand out in my mind.

Selling more WebSphere products. There is no question that the WebSphere brand within IBM’s Software business unit includes a lot of products such as its registry/repository, applications integration, security, and various middleware offerings. IBM likes to sell its products by focusing on entry points — the immediate problem that the customer is trying to solve. The opportunity to gain direct access to business buyers who start with business process management and then may be see the value of adding new capabilities to that platform.

Supporting the Smarter Planet strategy. Business transformaton often starts by reconstructing process. IBM’s smarter planet strategy is based on the premise that customers want to be able to transform their businesses utilizing sophisticated technology. Therefore, it is important to look at how business innovation can be supported by IBM’s huge hardware, software, and services portfolio. The fact that Lombardi’s technology is the starting point for business units looking at transformational process changes is an important marker in IBM’s evolution as a company.

Jim Webber has recently coined the term “Guerrilla SOA” to describe a lightweight approach to SOA that does not rely on big middleware products. Here is some abstracts:

http://www.infoq.com/news/2009/12/SOA_Gorilla

I have been thinking about Clouds. There is lots of noise (but hardly thunder). One area particularly attracts….

Assume that you have several (or many) separate applications running in your cloud. You want some or all of these applications to communicate. How do you do this?

From what I can see (and I do not see Amazon’s lightweight queuing as sufficient) there is a need for a memory based, inter-system messaging solution. This has to be able to be fast yet also be made transaction-friendly (there should be a demonstrable trade-off/choice – within the one solution – between reliability and speed which the user can select rather than have imposed).

Too me MQSeries is simply too plodding to be broad-based in a cloud. JMS is also probably too heavyweight. Something like RV might be more applicable.

There is an opportunity, in my assessment for someone to act and satisfy an opportunity that seems likely to grow and grow – and be applicable within private clouds, public clouds and especially hybrid public/private clouds.

Suggestions and/or comments are welcome.

In this blog , I will explain with simple example how to design Master/Detail BPEL Flow .For aurdience who has working knowledge of workflow it is very easy to understand and visualize the process, but Oracle BPEL has made it so simple …
For complete details Refer BPEL

This week’s great announcement revolves around Allianz’s $1M saving going Open-Source. The theaustralian.com.au article not only mention huge cost reductions by moving to Linux, but Alllianz’s substential savings are also coming from their move from IBM’s Websphere Application Server to JBoss Enterprise Application Platform.

Encouraged by the economic conditions and the growing mindshare around middleware Opensource, we see this trend accelerating accross the world and especially in Asia/Pacific, Japan.

There is 2 ways to start a migration to JBoss middleware.

1. Outsource – Contact our experts and services team, they offer migration assessment and pilot services
2. DIY – JBoss is contributing back the tools and methodology to assist you when migrating.

Resources: Migration Guide(PDF), JBoss Migration assistance project

If you want to read about success stories in your region or your industry, please check Red Hat Success Stories here.