Advanced Software Development

Methodology to Deliver Service Oriented Architecture

sadi@dsofttechnologies.com (DSOFT Systems) — Fri, 27 Nov 2009 09:25:27 PST

By Sadi Melbouci
From
DSOFT Technologies

A- Introduction
The technology has become an essential basic capabilities to create value proposition that distinguish the business in the marketplace. Enterprises need to be able to bridge between the business and the technical world. IT infrastructure should be aligned with business structure so that it can easily adapt to meet the business needs. One way of achieving this objective is through Service Oriented Architecture, SOA.
In Order to effectively deliver standardized services, it is recommended that organizations adopt methodology and processes specific to SOA consisting of structured analysis and design.
This article outlines a methodology to deliver service oriented architecture by applying service orientation principles to shape a solution in certain way with certain goals in mind to produce a blueprint of individually distributed unit.

Let's start with some definitions on SOA.

B- SOA Definitions

- What is Service-Oriented Architecture
SOA represents an architectural model that aims to enhance the agility and cost effectiveness of an enterprise while reducing the burden on IT and on the overall organization. It accomplishes this by positioning services as the primary mean by which the solution is represented.

- What is a Service
A service is unit of solution to which service orientation principle has been applied to a meaningful extent. It is the application of service-orientation principles that distinguishes a unit as a service compared to logic that may exist as an object or component.
A Service is comprised of a set of functions and capabilities related to its context.
Service Inventory is an independent standardized and governed collection of services.
A collection of inventories create a Domain Inventory.

- What are the Characteristics of SOA

Business Driven
Vendor Neutral
Enterprise Centric
Composition Centric

- Goals Of Service-Oriented Architecture
stating the common goals and benefits of SOA and these goals must be viewed within strategic context of the organization.

Increase Interoperability
Increased federation
Increase Vendor Diversification
Increase Business and technology Domain Alignment
Increased ROI
Increased Organizational Agility
Reduce IT burden

- Principles of Service Oriented Design

Standard Service Contract
Service Loose Coupling
Service Abstraction
Service Re-Usability
Service Autonomy
Service Statelessness
Service Discoverability
Service Composition

C- How to deliver SOA
Service Oriented Architecture is an architectural style. One of the methods to deliver SOA is explained in details by Thomas Erl in [1]. we will try to summarize this methodology that is simple and can also be integrated with TOGAF, FEA or any other Enterprise Architecture Framework. However, TOGAF failed to address SOA as an architecture style, some adjustments to TOGAF first four phases are required to deliver SOA.
We will explain the delivery of SOA through two main phases:
- Service Oriented Analysis
- Service Oriented Design

Before we start on the details of the analysis and design, let's address what approach to use:

-Delivery Approach
There are two delivery approaches, top down and bottom up. When starting SOA within an organization with an objective of business - IT alignment, we recommend Top-Down approach.
We will list the pros and cons for each method.

Top- Down

PROS
- Advocates the completion of an inventory analysis prior to the physical design, development, and delivery of services.
- Define blueprint Service Inventory
- Reduce the burden of governance
CONS
- Increase Of cost and Effort

Bottom Up

PROS
- Tactically focused in that it makes the fulfilment of immediate business requirements a priority and the prime objective of the project
CONS
- Increase Cost of Maintenance, Refactoring and versioning
- Increase Effort of Governance
- Shorter life span

- Service-Oriented Analysis
Service Oriented Analysis represents the early stage in SOA and the first phase in service delivery cycle. It is a process that often begins with information gathering. This is accomplished iteratively and usually once for each business process.
This phase is accomplished jointly by business architects and technology architects to guarantee a higher degree of business-IT alignment. Iterations through analysis and modelling result in service candidates.
These Services are classified into Service Layers:

Service Entity (Product, Customer, Service, Invoice ...)
Service Task (Order Management, Business processing)
Service Utility (Non Business Centric, )

Analysis

Perform Service Oriented Analysis

Define Analysis Scope to establish the boundary of the analysis
Identify Affected Systems
Perform Service Modelling

Define Enterprise Business Model:

Define the scope
Accurately express the functions to be implemented

Define Technology Architecture

Define initial architecture platform
Identify Architecture Constraints
Refine the architecture for each iteration

Define Service Inventory BluePrint

Identify service inventory boundaries
Produce service candidates for this inventory

Within this step, the service conceptualization starts. It identifies service capability candidates. This phase also identifies service assembled into composed services. Basically, a business process is decomposed into granular functions and then services are assessed into groups of services that are specific or agnostic to the current business process. Below are the steps to perform this phase. This phase results with final version of capabilities of service candidates.

Decompose Business Process
Filter Unsuitable Steps
Identify Agnostic Service Candidates
Identify Process Specific Logic
Apply Service Orientation Principles
Identify Candidate for Service Composition
Analyze Processing Requirements
Identify Utility Service Capability Candidates
Define Utility Service Candidates
Apply Service Orientation
Revise Candidate Service Composition
Revise Capability Candidate Grouping

After applying the above steps, the service capability candidates will results in the following groupings.

Entity Services
Utility Services
Task Services
Orchestrated Task Services

Service Oriented Design
All the work put into the analysis phase resulted in set of service candidates that the design phase will take as input. Every service candidate is considered as starting point for service oriented design. It is recommended that the sequence of the design goes from the most independent service to the least independent:

Design Entity Services
Design Utility Services
Design Task Services
Design Orchestrated Services

During this phase, many considerations are taken into consideration to output a service contract in support to standards, principles and constraints. It is important to remember that a single service can provide a collection of capabilities. They are grouped together because they relate to a functional context established by the service.
When building the services as Web Services, this will require a definition of an XML schema to support the data type and structures to be exchanged. A WSDL is then built around the XML schema adjusted by the application of SOA principles and design patterns.
For Orchestrated services, it involves a composition of services and outputs WS-PBEL process definition.
Service-orientation places an unprecedented emphasis on reuse. I would like to quote Thomas Erl [1] book "By establishing a service inventory with a high percentage of reusable and agnostic services, we are now positioning those services as the primary means by which the solution logic they represent can and should be accessed. we make a very deliberate move away from the silos in which applications previously existed. Because we want to share reusable logic whenever possible, we automate existing, new, and augmented business processes through service composition. This results in a shift where more and more business requirements are fulfilled not by building or extending applications, but by simply composing existing services into new composition configurations. When compositions become more common, the traditional concept of an application or a system or a solution actually begins to fade, along with the silos that contain them".

- Design Challenges
Significant amount of services within the inventory can ultimately be comprised of agnostic services capable of fulfilling requirements for multiple potential service consumers. Although this can establish a highly normalized and streamlined architecture, it can also introduce an increased level of complexity for both the architecture as well as individual service designs. We will list few challenges that the design shall address and there are many other things that should be addressed but we will not address them in this article.
- Performance requirements & scalability
- Single point of failure resulting from excessive use of a service
- Service Contract Versioning
- Authentication
- How can service logic be positioned as enterprise resource
- Service Normalization / denormalization

It is important to position SOA as an architecture model that is Vendor neutral or even Technology neutral. By doing, we position the enterprise to pursue and leverage on-going technology advancements. Many SOA design patterns help address these common issues and for each SOA design principle there are set of patterns that can be applied to successfully achieve the objectives of each principle.
In the beginning of this article we listed a list of Service Orientation Principles, that should be applied to a business capability to shape it as Service. For each of these principles, we will apply a set of SOA design patterns to satisfy it.
We will list a set of design patterns that can be applied to satisfy each principle and produce individual logic units that can be qualified as services. The design pattern are shown in ITALIC. There are off course more design patterns and each project is different, I will list the design patterns we applied in our project at DSOFT SYSTEMS.

Standard Service Contract: Services within the same inventory are in compliance with the same contract design standards. The following design patterns needs to be applied to get a Standard Service Contract: Canonical Protocol, Canonical Schema, Canonical Versioning, Concurrent Contract, Contract Centralization, Contract Normalization, Contract De normalization, Composition Autonomy, Agnostic capability, Proxy Capability

Service Loose Coupling: Service Contract requires a low consumer coupling and themselves decoupled from their surrounding environment. The following dessign pattern help achieve this objective: Asynchronous queuing, Decoupled Contract, Data Format Transformation, Event Driven Messaging, Service Facade, Proxy Capability

Service Abstraction: Information about service is published in the contract. The contract only contains essential information about the service. Utility Abstraction, Service Perimeter Guard, Service Refactoring, Validation Abstraction.
Service Re-Usability: Services contain agnostic logic and are positioned to be re-usable enterprise resources. These design patterns help achieve this requirement: Agnostic Capability and context, Capability Composition, Consurrent Contract, Logic and Rules Centralization, Service Layers.

Service Autonomy: Services shall run in their own environment and exercise a control over the underlying runtime execution environment. Canonical Resource, Distributed Capability, Service Normalization, Capability Recomposition.
Service Statelessness: Services shall optimize resource consumption by deferring the management of state information. Asynchronous queuing, Atomic Service Transaction,Service Grid, Service Instance Routing.

Service Discoverability: Services comes with metadata by which they are be discovered and interpreted. Canonical Expression, Metadata Centralization.

Service Composition: Service composed of sequence of other service to form a new service. The following design patterns help to guide how to achieve this objective. Decomposed capability, Agnostic capability, Brokered Authentication, Capability Composition, Data Confidentiality, Dual Protocol, Reliable Messaging.

Standardization
It can be a straight-forward process to create these standards to support SOA, incorporating them into an IT culture already set in its ways can be demanding to say the least. The introduction of design standards implies a need to enforce them, SOA governance and its challenges addresses how governance of SOA.

How to choose the Technology
As we apply these design patterns to achieve SOA goals expressed in the beginning of this article, we started with a list of technologies that included weblogic/Aqualogic, Mule, Spring, JBoss Enterprises Suite ...etc. We proceeded by elimination and narrowed the choice of tools and technologies to a small set that can help us achieve our objective in optimized and timely manner. For instance, for service composition, there are many vendors offering what we wanted at different costs and we narrowed it to two: Mule ESB and JBOSS ESB. We did choose JBoss ESB because it is well integrated with JBPM and JBoss rules to implement the rules centralization and achieve a higher level of orchestration.
In conlusion, I would like to insist that the choice of technology should be based on the goals that must be achieved and dictated by the business which are:

Increase Interoperability
Increased federation
Increase Vendor Diversification
Increase Business and technology Domain Alignment
Increased ROI
Increased Organizational Agility
Reduce IT burden

References:
[1] Thomas Erl, SOA Principles of Service Design,

SOA Governance and its challenges

sadi@dsofttechnologies.com (DSOFT Systems) — Sat, 14 Nov 2009 09:34:51 PST

By Sadi R Melbouci

From DSOFT Technologies

Introduction

Service Oriented Architecture enables enterprises to pursue business and technical strategies that promote the exposure of business functionality within and between enterprises in consistent, published, secure and contractual fashion.
However, Service Oriented Architecture is not a solution that comes in tidy box. It is more about new way of design, it is more about culture then it is about technology.
To ensure success of any SOA implementation, it is necessary to include some type of governance that define the policies and practices all services should follow.

Why some SOA implementations failed?

SOA Governance is probably the most talked and most delicate topics in SOA nowadays. About 5 to 6 years ago, many organizations approached SOA as implementing a web service. There was no attention to SOA Governance. This may be explained differently, but the situation reminds me of a practice of some IT managers – just get it to work and take a look at the design later. As we all know, any temporal fix becomes a permanent solution with consequences dealt with later at higher cost.
In one of the my consulting jobs, the organization thought that SOA was a new integration technology that will magically integrate all their existing assets. One of the managers asked me to start looking at the code to perform this funny integration. When I told him what SOA meant, he got a chock of his life. Without going into details, many organizations built hundreds of services/components and run into scalability, performance, manageability and integration problems.
One of the main reasons of this type of difficulties is that service-oriented, design, implementation was not governed at all or governed with traditional software development without any clues on service orientation [1] methodologies.
In this article, we will present SOA and its Governance policies to address these problems.

What is SOA?
Multiple definitions of SOA were presented in the literature, I will summarize some of them in here. SOA is architectural style who's goal is to achieve re-usability and loosely coupling paradigm among interacting agents. Within SOA, services are mechanisms by which needs and capabilities are brought together.
SOA operates in an integrated business-technical context as opposed to traditional business-IT separation.
Anne Thomas Manes from Burton Group said, “SOA is a style of systems architecture, not integration architecture. It’s about refactoring capabilities into services, not about integrating application silos”.

What is SOA Governance?
Governance is set of rules, policies and regulations under which an organization functions as well as the processes that ensure compliance. SOA governance refers to processes that ensures that services and applications are developed so that they are aligned with :

Best practices
Business requirements
Laws
SLAs

SOA Governance has two main component:

Design Time Governance also called "SOA governance framework", captures information about the services and policies.
Runtime Governance or sometimes called as "Service life cycle management", enforces the policies during the execution, management and service discovery.

The need for enterprise governance is business oriented to integrate business initiatives (supply chain, order management,...) with IT initiatives (EAI, Web service, ...). The companies needs to move from "develop now and integrate later" to "develop for integration". To ensure business continuity, reduce cost and complexity and limit corporate liability, the companies shall define the policies and procedures early in project life cycle to allow:

Prevention of service proliferation and promote reuse
Define Services with the right granularity
Utilize a formal service description model with appropriate metadata
Develop and implement best practices for interoperability
Approach SOA on how it will be deployed and consumed
Manage and monitor service health, performance and Quality of service
Audit and measure compliance
Define and manage Policies and contracts centrally
Central registry-repository to describe all services and associated metadata
Service mediation and discovery

Design Time Governance (Governance Framework)
There are mainly four phases to SOA governance framework: Plan, define, Enable and Measure.

Plan Phase, the overall business and IT requirements are understood and documented
Define Phase, the SOA governance approach is established based on corporate, enterprise and IT governance environments
Deploy Phase, governance mechanisms are put into place, the organization is educated, and governance policies are deployed.
Measure Phase, policy compliance and effectiveness are monitored and audited.

Runtime Governance Compliance (Service Lifecyle management)
The runtime governance encapsulate the phases to model, assemble and deploy. These 3 phases are broken into two separate facets:

Service Development and Delivery Management
Support Infrastructure and Management

Service Development and Delivery Management
Service Development and Delivery addresses the essential needs to govern the services development through the established governance framework. The areas of focus are mostly:

Change and release management - What, When and by whom a service can be changed
Requirements and Quality Management - Ensure services are developed in compliances with business requirements and compliance.
Design and Construction - Ensure the best practices and design principles are appied for maximum.
Asset reuse.
Service Versioning
Service Retirement
Process Management - Continual auditing to make sure that the process is followed

Support Infrastructure and Management

Environment

Distributed, cross-boundary services and access present security risks
Rapid deployment and loose coupling of services
Performance and prioritization of services

Service Security

Need to manage identities and access control cross multiple platform, applications, business partners and entities
Need for E2E security architecture that can be deployed and integrated with existing and disparate security models
Need to define encryption policies
Need to consistently enforce security policies

Service Management

Federate identity and access control
Secure services and applications
Consistently enforce security policy

Service Virtualization

Support scaling infrastructure resources
Prioritize infrastructure across multiple services and/or business processes (composite/dynamic applications)
Accelerate application performance by distributing the composites across multiple infrastructure resources.

Service Registry and Repository
Service Registry contains the policies, description and metadata for each service present in the enterprise. It provides a mechanism to find services and their metadata.

Conclusion
SOA governance requires policy control and audit framework that spans the security, service definition, identity domain, service consumption and people. A SOA governance framework requires some means to consistently define some policy and managing it through its lifecycle and provisioning from central accessible policy registry and enforcing its execution across distributed systems.
Enterprises will only benefit and further improve their competitive advantage and quality of service by utilizing an automated policy governance. By doing so, the organizations will be able to leverage both their IT assets and human capital.

References:
[1] SOA Design Patterns, Thomas Erl, 2009
[2] SOA-RA public Review
[3] Reference Model Service Oriented Architecture
[4] Does web service make a service for SOA

Page Rank 4 in 60 days

sadi@dsofttechnologies.com (DSOFT Systems) — Sun, 04 Jan 2009 00:07:53 PST

How to accomplish google page rank 4 in 60 days?

By Sadi Melbouci

At the end of this year - 2008, I got a nice christmas surprise. My site went from google rank 0 "zero" to 4 in 60 days.

My web site, Practice Management Software, was first crawled sometime in the end of October. I decided to increase the rank of my site and traffic with a minimum budget. I laid out a plan and below, I will discuss the tasks that I executed in the sequence that they appear.

Page Header Elements

Designed the pages to be SEO friendly with modern web page build design. Paid attention to the following:

- Page title

The name of web page has the name of the title

- Page header

The title has the first H1 header in the page

- Meta description

The page description has the title in it as the first sentence.

- Meta tag keyword

3 to 4 keywords per page.

Page Design

- Usage of CSS

Take advantage of modern web page design. Styles should be defined in a CSS document that references the elements, IDs, and classes in the XHTML document.

- Page size

Google only crawls the first 100k. Kept the page to less then 50k

- Eliminate Obsolete or deprecated HTML

Use modern design techniques and used proper combination of XHTML and CSS

Link popularity

- Submitted the site to the major search engines including Yahoo, Google, Altavista, ...etc

- Submitted the site to web directories: Yahoo, DMOZ, Allweb, BOTW ...etc, submitted the site to the correct caegories. This will provide one way link to your site.

- Started a blog and wrote articles on the subject related to my site.

- I commented on other blogs related to my site

- Added an RSS feed to my site

- Made the keywords as the anchors

- Finally, I have exchanged links with other sites on the same subject domain as my site. Making sure that the anchor in the link is one of my keywords.

Keyword Density

- I focused on 3 to 4 keywords per page that were defined in the keyword meta data header element.

- I wrote the text in the body for the potential customers describing my product without repeating too much the same keywords and used bold where needed.

- Put one keyword in alt image attribute and title

- Put one keyword in name and title of the link attribute

Advertising

I have noticed that some of the ads from Google and Yahoo advertised as content (This type of ad appear on some articles related to subject described in the ad). When these sites get crawled, The search engine counted it as one way link.

I guess this might be a temporal link but counts to increase both the organic and advertised traffic.

That's all. It worked like charm.

Medical Practice Software

Download Medical Practice Software

HIPAA Compliance

sadi@dsofttechnologies.com (DSOFT Systems) — Wed, 14 Jan 2009 22:28:21 PST

In this article, I will address HIPAA as it relates to the software and tools used by clinicians to manage their practice. The congress has put a set of rules under the HIPAA law, we will explain what's this law is about and how it applies to medical software.

What is HIPAA?

The Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA, Title II) required the Department of Health and Human Services (HHS) to establish national standards for electronic health care transactions and national identifiers for providers, health plans, and employers. It also addressed the security and privacy of health data. As the industry adopts these standards for the efficiency and effectiveness of the nation's health care system will improve the use of electronic data interchange.

The Entities covered by HIPAA law are:

Health Plans
Health Care Providers who use certain electronic transactions
Health Care Clearinghouses

The HIPAA provisions are summarized as:

Transaction Standards and Code Sets
Privacy
Security
National Standard Identifiers for the Provider, Employer, Health Plan and Individual

HIPAA in Practical terms

Administrative Simplification is a method of making medical practice (the billing, claims, computer systems and communication) uniform in order for providers and payers to interact with each other through each other's proprietary systems. The changes will affect such activities as:

Enrolling an individual in a health plan

Paying health insurance premiums

Checking eligibility

Obtaining authorization to refer a patient to a specialist

Processing claims

Notifying a provider about the payment of a claim

HIPAA Privacy Right and Security

HIPAA contains a provision that is related to Electronic Data Transactions to standardize the exchange of the data between trading partners. These transactions are mandated to be in the ANSI ASC X12 version 4010 format.
In Addition to the transactions, Software industry has introduced Electronic Medical Records. To guarantee the privacy rights and secure the access to the medical records, HIPAA provided guidlines to protect the patient's privacy.

Privacy rights

The HIPAA regulations establish standards for protecting individually identifiable health information and for guaranteeing the rights of individuals to have more control over such information. Here is the summary of these regulations:

1- Right to ask and see a copy of your records
2- Have Correction made to you records
3- Receive a notice that your information will be shared
4- Decide whether to accept that your information can be shared
5- Get a report of when and why your record is shared
6- Ask that your information shall not be shared
7- File a complaint

Security 101

The HIPAA regulations have establish standards for all health plans, clearing houses, and storage of health care information to ensure the integrity, confidentially, and availability of electronic protected health information.
The Security Rule covers only protected health information that is in electronic form and we can summarize the security standard into the following requirements.

- Administrative Safeguard
These are administrative functions that should be implemented to meet the security standards. These include assignment or delegation of security responsibility to an individual and security
training requirements.

More details on Administrative Safeguard Reference

- Physical Safeguard
These are the mechanisms required to protect electronic systems, equipment and the data they hold, from threats, environmental hazards and unauthorized intrusion.

More details on Physical Safeguard and recovery

- Technical Safeguard
These are primarily the automated processesused to protect data and control access to data. They include using authentication controls to verify that the person signing onto a computer is authorized to access that.

More details on on Technical Safeguard who has accesses what information?

Is X12 technology right for healthcare

sadi@dsofttechnologies.com (DSOFT Systems) — Wed, 14 Jan 2009 19:37:53 PST

Is X12 Format right for Healthcare.

In every corner, we hear about the rise of healthcare costs and how to reduce them. I would like to add one area where the cost can be reduced significantly.
We all agree that the cost can be reduced by automating certain procedures, such as the medical billing, electronic medical records, scheduling, reporting and so on.
The first question I asked was, what if the cost of automation is so huge that it will raise even more the costs of healthcare.
So, how can we reduce the cost of the automation.
The scheduling, automation can be accomplished at very minimal cost.
The Electronic Medical Records is specialty dependent, but there is some common data that can be defined as "standard" for each practice.
The medical billing is the big elephant in the room. The cost of its automation is significant and its implementation is complex. We will look at two aspects:

Medical Coding
Claim Processing

Medical Coding specialists are in high demand because of rapid growth in the number of medical tests, treatments, and procedures that will be increasingly scrutinized by health insurance companies, regulators, courts, and consumers." (See U.S. Department of Labor, Bureau of Labor Statistics.) , It is probably the fastest growing profession withing the healthcare industry. The 2005 statistics from the United States Department of Labor and Bureau of Statistics, showed the healthcare information industry is expected to grow faster than normal through 2014.

In practical terms, the medical coder adds cost to the clinician and that cost will be transferred to the patient. But this is required position that we may not be able to cut. So, where can we cut costs ?
We will look at how to reduce the cost HIPAA transactions processing.

HIPAA Transactions.
HIPAA defined a set of transactions to support Electronic data exchange:

Health Care Claims or equivalent encounter information (837);
Eligibility for a Health Plan (270/271);
Referral Certification and Authorization (278 or NCPDP for retail pharmacy);
Health Care Claim Status (276/277);
Enrollment and Disenrollment in a Health Plan (834);
Health Care Payment and Remittance Advice (835);
Health Plan Premium Payments (20); and
Coordination of Benefits (837 or NCPDP for retail pharmacy).

While many entities in the health sector have developed, or are in the process of developing, electronic data interchange (EDI) format standards, the lack of common, industry-wide standards is a major obstacle to realizing potential efficiency and savings.

The problem starts with the choice of EDI format, X12. For those who had some experience with X12, they know what I'm talking about. It is a complex format that is very hard to maintain and terribly complex to implement.

Today, the software industry offers other technologies that can actually reduce the cost of the implementation of the HIPAA transactions and HIPAA specifications. One of these technologies is XML Web services (Dont confuse it with a web site) that operates under SOAP (Simple Object Adapter Protocol) or REST.
The data for each transaction can be defined with an interface called WSDL (Web Service Definition Language) and the companies can implement the business behind each transaction independently.
This protocol is platform independent (Windows, Mac, Unix, Linux, MVS ...etc) and it can reduce the implementation costs by 500% and increase efficiency at every level of claim processing because this technology provides hooks to validate, secure, transport data. This reduction of cost in claim processing will imply reduction in insurance premiums as well as the reduction of the cost of billing systems.
Compared to EDI where the claims are submitted in batch format, the Web Service technology can submit the claims in realtime or immediate send or in batch mode. The number of errors will be reduced to under 1%.

The combination of efficient medical coding along with web services technology as the protocol of choice for HIPAA transactions will reduce the cost of claim processing by at 200%.

Conclusion

The ultimate goal is to take care of the patient at reduced cost. Many things need to come together in order to accomplish this goal. One of them is Medical Practice Management Systems implemented at reasonable cost that offers the functions that will optimize the provider time and costs. I believe that it start by applying the right technology that can help the business.

Medical Practice Management Software - EzMedPro

sadi@dsofttechnologies.com (DSOFT Systems) — Tue, 14 Apr 2009 19:31:33 PDT

Introduction

With today's rising healthcare costs and the baby boomers needing care, it is important to automate medical records, billing, ...etc in the everyday provider's tasks. For patients, they want the best care. They want to get an appointment with a doctor when they are not feeling well and not wait few days for a possible care. And when they show up at the doctor's office, they want the best care.
The best care comes when the provider knows our medical history and can be accessed quickly on each visit.

How do we make the provider more efficient?
Well, we need to look at how to optimize the time the provider spends in tasks other then seeing patients.
I will try to list some that every patient may have seen:

1- Medical Records are on paper and hard to find, the doctor does not go through every pages of our record. He looks at the last visit. We need to have a way to show the medical history summary of the patient that can be seen by the provider without going through 30 pages.
2- Medical Coding is another area of headache. To put it in simple words, a visit to doctor has a code (that's a CPT code) and diagnosis is another code (that's the ICD code). These codes are used to submit the claim to the insurance company.
3- Billing is critical to raise revenue for a practice. Having a system that generates a bill for each visit and manage the receivable accounts will help the providers save time. However, I have seen that these two functions are usually managed by two different systems. EzMedPro
is a software that integrates these 2 functions.
4- Insurance Claims , this is an area I believe needs the most improvement. The Insurance companies make it hard for both the provider and the patient when it comes to pay a claim. Today there are two way to get a claim processed:
- HCFA form and send it by mail
- Electronic Claims
5- Scheduling is not really an issue but need to be mentioned for large practices to run reports and send reminders to the patients prior to their appointment.

The potential solution
The solution is to automate the daily tasks as much as possible. Basically we need to automate at the least the 5 tasks I listed above: Scheduling, billing, insurance claims, medical coding and medical records.
Not only do these task need automation but they need to be integrated within one system in compliance with HIPAA.

There are certain number of systems that provide some type of solution. However, for most of the providers, affordability is an issue, until now. EzMedPro is a Medical Practice Management Software that integrates all the tasks I listed above and is available for a price under $300.

The Objective is to make the provider focus on the patient. EzMedPro Software from DSOFT Systems provides the lead way for affordable software with efficiency for providers.

Add to Technorati Favorites

JCA Connector for SSH and SFTP

sadi@dsofttechnologies.com (DSOFT Systems) — Sun, 07 Dec 2008 17:21:05 PST

By Sadi Melbouci

The Enterprise Architecture Integration (EAI) provides a common framework for integrating incompatible systems running on different platforms. Many legacy applications and custom databases are still being used and run well that there is no need to re-invent the wheel. The aim of EAI is to reduce the complexity of the IT infrastructure and improve reliability, scalability and flexibility.

This article provide a brief description of a technology that is a key in integrating the databases and legacy systems with J2EE technology. Java 1.4 came with JCA 1.5 (Java Connector Architecture) that provide the standard mechanism to store, retrieve data from EIS (Enterprise Information System). To understand how JCA fits into EAI, refer to Connect the Enterprise with JCA.

Why JCA?
J2EE container is responsible for managing the security, threading, resource pooling and so on. In order to ensure the control over their functions, the container put some restrictions on components it manages such as EJB and servlets.
One of the restrictions is on EJB and IOs in general. An EJB should not manage a file descriptors (Sockets or Files). The communication with EIS is done through Sockets. Sockets are the standard low level communication primitives that appeared in early 1970's for Unix systems. The Sockets are not serializable therefore, EJB cannot passivate them neither the servlet can put them in session. In distributed environment, EJB are distributed at runtime running on separate JVM or machines. More information about EJB restrictions may be found at EJB Restrictions .
But EJB should find a way to communicate with databases and other EIS system. JCA provides the solution where the JCA handles the low level connections with EIS and return a Handle for the connection to the J2EE middle tier components.

Before we start the implementation of a Resource Adapter to provide SSH and Secure FTP functionalities, let's list the main JCA components:

System contracts
Client API
Resource adapter module

System contracts
System contracts define the connection between the application server and the EIS. The EIS side of the system contract is implemented by a resource adapter
-- a system-level software driver specific to the EIS. The application server and the resource adapter collaborate by means of the system contract to provide secure, robust, scalable access to the EIS.
Three types of system contracts are defined:
The connection management contract enables physical connections to the EIS and provides a mechanism for the application server to pool those connections.

The transaction management contract supports access to an EIS in a transactional context. Transactions can be managed by the application server, providing transactions that incorporate other resources besides the EIS, or they can be internal to the EIS resource manager, in which case no transaction manager is required.

The security contract supports secure access to the EIS. How system contracts are implemented on each side (application server and resource adapter) is not specified by JCA; they can be implemented as each vendor sees fit.

Client API

The second element of JCA is the client API. The API can be specific to the resource adapter or it can be the standard Common Client Interface (CCI) as defined by JCA. The CCI is meant to be used by vendors to provide integration tools and frameworks, making it easier for developers to access enterprise systems. It is recommended (but not mandated) that the resource adapter make use of the CCI.

Resource adapter module
The resource adapter module contains all of the elements necessary to provide EIS connectivity to applications. Specifically, the resource adapter module includes the following components:
- The Java classes and interfaces that implement the resource adapter
- Any utility Java classes required by the resource adapter
- Any EIS-specific platform-dependent native libraries
- The deployment descriptor
Application servers make use of the deployment descriptor supplied with a resource adapter to configure it to a specific operational environment.

Handling of Connections
An application component accesses the resource adapter through ConnectionFactory and Connection interfaces, which are provided by the resource adapter implementer. These interfaces can be CCI interfaces (javax.resource.cci.ConnectionFactory and javax.resource.cci.Connection) or they can be specific to the resource adapter. The classes that implement these interfaces are also provided with the resource adapter.
The connection factory is obtained through the Java Naming and Directory Interface (JNDI) so that the application need have no knowledge of the underlying implementation class. Once the connection factory is retrieved, a connection is obtained from the connection factory through the getConnection() method. At least one getConnection() method must be provided by the connection factory, though more may be provided. It is important to note that a Connection is an application-level handle to an underlying physical connection to the EIS, represented by a ManagedConnection. Once the application component is finished with the connection, it calls the close() method on the connection. A resource adapter is required to provide a method on the connection to close the connection. This method must delegate the close to the ManagedConnect ion that created the connection handle. Closing a connection handle should not close the physical connection to the EIS.

Managing Connections
The getConnection() method in the connection factory does not actually create a connection;
it calls the allocateConnection() method on its associated ConnectionManager.
The ConnectionManager interface is implemented by the application server.
It is associated with a connection factory in an implementation-specific manner when the
connection factory is instantiated. The call to the ConnectionManager allows the application
server to "hook in" to the resource adapter functionality to provide pooling, transaction,
and security services. A ConnectionRequestInfo object may be passed to allocateConnection()
to pass connection request-specific information.

The ConnectionManager, in turn, calls on a ManagedConnection to obtain the connection
handle. The connection handle is passed back through the ConnectionManager to the connection
factory and on to the application component.

Connection Pooling

The resource adapter provides a class that implements the ManagedConnectionFactory interface. The ManagedConnectionFactory class acts as a factory for both connection factory instances and ManagedConnection instances. When the application server needs to create a connection factory, it calls the createConnectionFactory() method, passing in an instance of ConnectionManager; this is the instance that is called when the application component calls getConnection() on the connection factory, as discussed previously.

The application server uses one of two ManagedConnectionFactory methods to create or request managed connections. When the server requires a new instance of ManagedConnection, it calls the createManagedConnection() method. When the server wants to re-use an existing ManagedConnection, it calls the matchManagedConnections() method. To find the right match, the server passes in a set of ManagedConnections that could possibly meet the criteria of the requested connection, along with information about the desired connection type. Internally, the matchManagedConnection() method compares this information with the candidate set to determine if a match can be made. If so, it returns the matching ManagedConnection; if not, it returns null.

So far we have talked about the outbound. JCA also supports the inflow and is implemented using ActivationSpec and Inbound Message Driven Bean.

The following depicts the design of the SSH adapter.

The code can be found at http://txconnect.sf.net

References:
Connect the Enterprise with JCA: http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca.html

JBOSS LDAP Integration

sadi@dsofttechnologies.com (DSOFT Systems) — Sun, 07 Dec 2008 17:20:40 PST

By Sadi Melbouci

This article provide a prototype of integration of J2EE applications such as Servlets/JSPs, EJBs, MDBs with LDAP (Lightweight Directory Access Protocol) for application authorization and authentication. This article identifies some key interfaces within JBoss and any J2EE container compliant application server that can be configured to provide a secured access. We will provide a declarative LDAP security model in such a way you can configure it at runtime.

Few things to take in consideration:
- J2EE uses the same authorization model for both web-based components (servlets and JSPs) and enterprise components (EJBs). The specification requires transparent propagation of security credentials within the J2EE environment, so that once a user has authenticated to any J2EE component, the same security information is used by all other components.
- J2EE application programming model insulates developers from mechanism-specific implementation details of application security. J2EE provides this insulation in a way that enhances the portability of applications, allowing them to be deployed in diverse security environments.
- In order to integrate authorization into an unknown authentication mechanism, J2EE specifications define a simple role-based security model for EJBs and Web components. the specification defines a number of terms about security:
- A realm is the J2EE term for the security policy domain that is a definition of the way in which a user is authenticated. In its simplest form, a realm is a list of users and a mechanism for authenticating those users. Basic HTTP authentication is known as the HTTP realm; a public key certificate (PKC) authentication such as SSL is a different realm.
- A principal is the name of a user within the authentication realm. Although the J2EE specification does not require the principal name to be the same as the user's login name, most (if not all) J2EE implementations use the username as the principal name.
- A role is a definition of the way a user will use the system. Typical roles will be user, administrator, manager, developer, researcher, and so on. Outside the J2EE domain, a role is usually implemented by assigning users to one or more authentication groups or granting privileges to user accounts.
- A role reference is the name of a role used within the code of a J2EE application. As part of the J2EE application environment definition (known as the deployment descriptor), every role reference must be mapped onto a real role. The decoupling of the coded role reference from the actual role helps improve portability of a J2EE component.

Before we define the LDAP schema (LDIF file), the following are the LDAP common terms you need to know in order to understand this configuration.
To configure LDAP, refer to LDAP Admin guide

DN: Distinguished Name
A distinguished name uniquely identifies an entry in the directory. A DN is made up of “relative” distinguished names of the entry and each of the entry's parent entries, up to the root of the directory tree. These names are usually separated by commas and optional spaces. For example: 'uid=JohnDoe, ou=People, dc=company, dc=com'.
ObjectClass
An objectclass is a formal definition of a specific kind of objects that can be stored in the directory. An objectclass is a distinct, named set of attributes that represents something concrete, such as a user, a computer, or an application.
LDAP URL
LDAP URL is a string that specifies the location of an LDAP resource. An LDAP URL consists of server host and port, search scope, baseDN, filter, attributes and extensions.
Schema
An LDAP schema defines a set or rules that specifies the types of objects that a directory may contain and the required and optional attributes that entries of different types should have.

More details can be found in LDAP Admin guide.

Now, Let's define our LDAP schema to support the J2EE role-based security. Below is the LDAP structure that defines our LDAP tree:

com
---company
------------People
-------------------admin
-------------------demo
------------Roles
------------------Administrator
------------------Users

This structure is orgonized into 2 main structures, People and Roles. People contain the users and Roles groups the users into group of roles. A role is defined above, it provides the permission level for a user.

The following is the LDIF schema that also defines our LDAP entries.

dn: dc=company,dc=com
dc: company
objectClass: top
objectClass: dcObject
objectClass: domain

dn: ou=Roles,dc=company,dc=com
ou: Roles
objectClass: top
objectClass: organizationalUnit

dn: ou=People,dc=company,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: uid=demo,ou=People,dc=conpany,dc=com
uid: demo
objectclass: person
objectclass: inetOrgPerson
cn: demo
sn: demo

dn: uid=admin,ou=People,dc=company,dc=com
uid: admin
objectClass: person
objectClass: inetOrgPerson
cn: Admin
sn: admin

dn: cn=Administrator,ou=Roles,dc=company,dc=com
cn: Admin
objectClass: top
objectClass: groupOfNames
member: uid=admin,ou=People,dc=company,dc=com

dn: cn=Users,ou=Roles,dc=company,dc=com
cn:Users
objectClass: top
objectClass: groupOfNames
member: uid=demo,ou=People,dc=company,dc=com
member: uid=admin,ou=People,dc=company,dc=com

Save this schema into a file called entries.ldif

You can load this file by running the command :
ldapadd -f entries.ldif -x -D "cn=Manager,dc=company,dc=com" -w secret

Manager is administrator of the LDAP

Check that your entries are loaded by executing the following command:
ldapsearch -x -b 'dc=company,dc=com' '(objectclass=*)'

We are done with LDAP.

This example has been tested with OpenLDAP. It should work with any other LDAP provider.

Now, we need to tell JBoss how to authorize and authenticate against the LDAP entries we have created.
For our example, we will secure the JBoss jmx-console. Similar thing can be applied to any web application.

We need to modify web.xml and add the security constraint.

web.xml

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role Admin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>Administrator</role-name>
</auth-constraint>
</security-constraint>

<security-role>
Administrator
</security-role>

As you can see, we wanted only the users having a role "admin"to access the console.

Now we will tell JBoss what security scheme to use. To do so, we need to add security-domain element into jboss-web.xml. We have called our security scheme "AuthPolicy".

jboss-web.xml

<jboss-web>
<security-domain>java:/jaas/AuthPolicy</security-domain>
</jboss-web>

The "AuthPolicy" security policy shall be defined in login-config.xml located in :
$JBOSS_HOME/server/{config}/conf .
{config} can be one minimal, all, default or you can define your own.

Now let's define an entry in the login-config.xml. Remember, we will to define the LDAP URL defined above.

login-config.xml

<application-policy name="AuthPolicy">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >
<module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
<module-option name="java.naming.provider.url">ldap://localhost:389/</module-option>
<module-option name="java.naming.security.authentication">simple</module-option>
<module-option name="baseCtxDN">ou=People,dc=company,dc=com</module-option>
<module-option name="baseFilter">(uid={0})</module-option>
<module-option name="roleFilter">(member={1})</module-option>
<module-option name="rolesCtxDN">ou=Roles,dc=company,dc=com</module-option>
<module-option name="roleAttributeID">cn</module-option>
<module-option name="roleAttributeIsDN">false</module-option>
</login-module>
</authentication>
</application-policy>

I highlighted some attribute in red. These attribute should be mapped to your LDAP schema definition.

See it in action. Fire up JBoss, and then go to: http://localhost:8080/jmx-console.

References:
Security Trail in the Java tutorial, http://java.sun.com/docs/books/tutorial/security/index.html
Core Security Patterns, http://www.informit.com/bookstore/product.asp?isbn=0131463071&rl=1
JBoss Security Model, http://www.huihoo.com/jboss/online_manual/3.0/ch13s78.html
JBoss Login Module, http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapLoginModule

JAXB and xmlBeans. Pros ad cons

sadi@dsofttechnologies.com (DSOFT Systems) — Sun, 07 Dec 2008 17:19:59 PST

By Sadi Melbouci

I would like to address some differences between JAXB and xmlBeans in processing of XML documents.
JAXB is a part of JavaEE standards and provides a convenient way to bind an XML schema to a set of Java classes. This allowsh an easy way to process data in java technology without having to understand all the ins and outs of te XML technology.
JAXB 2.0, available in in the open-source Java EE 5-compliant application server at Glassfish project is part of the new integrated stack for Web services development. This new version of JAXB includes all the data binding functionality in a single package, while the previous Web services development stack (in Java Web Services Developer Pack 1.6 and previous versions) carried out some data binding in the JAX-RPC 1.x package and some in the JAXB 1.x package. With the integrated stack comprising JAX-WS 2.0, JAXB 2.0, and SAAJ 1.3, the Web services description, data binding, and SOAP attachment processing functionality are more logically architected, enabling you to develop Web services, middle tier and Web applications more easily.

XmlBeans was originally developed by BEA Systems, it is now an open source project. xmlBeans provide similar functionality then JAXB but may require some good knowledge of XML technology.
Prior to this technologies, one way to proccess an XML document, perhaps the most typical way, is through parsers Simple API for XML (SAX) or the Document Object Model (DOM). Both of these parsers are provided by
Java API for XML Processing (JAXP). The developer writes code to invoke a SAX or DOM parser through the JAXP API to parse an XML document -- that is, scan the document and logically break it up into discrete pieces. The parsed content is then made available to the application. In the SAX approach, the parser starts at the beginning of the document and passes each piece of the document to the application in the sequence it finds it. Nothing is saved in memory. The application can take action on the data as it gets it from the parser, but it can't do any in-memory manipulation of the data. For example, it can't update the data in memory and return the updated data to the XML file.
In the DOM approach, the parser creates a tree of objects that represents the content and organization of data in the document. In this case, the tree exists in memory. The application can then navigate through the tree to access the data it needs, and if appropriate, manipulate it.

Now we have 2 technologies that do convert the XML document into java classes. You manipulate the Java object instead. However, JAXB and XmlBeans accomplish the marshalling and unmarshalling of XML document quite differently.

XMLBeans processes an XML document without going through a conversion into Java where integrity of the document can be lost. XMLBeans creates a cursor that can move through the XML document. You can access any element of the document, including comments and schema information because the document is kept in full fidelity. It also creates the opportunity to execute an XQuery on the document. XMLBeans also gives a strongly typed access to the document and a more generic type of access, similar to a reflection API. However, it doesn't always work the way you want it. Many time an error like "Invalid XML character 0x0" by processing the same document where the processing was previously successful.
More importantly, like I previously mentioned it, Using Xml Beans requires you to know XML very well and also SAX and DOM.

JAXB is binded to the XML schema, the first release of JAXB did not answer the development community, mainly because it did not support all XML schema features and only supported DTDs. The first JAXB version suffered mainly of 3 major issues: it prevented support of type substitution and related features, it prevented support for extensibility and versioning, it failed to provide readable bindings in many cases.
JAXB 2.0 was enhanced to fill up the gaps and provides full XML schema support, Java to XML Schema mapping, schema evolution and portability. For ease of development, JAXB has leveraged J2SE 5.0 features: generics for type safe collections enum type for binding of simple type with enumeration facets better support for XML schema types using datatypes in JAXP 1.3 leveraging JAXP 1.3 validation for smaller footprint more compact binding based on constraining facets defined in schema.
JAXB architecture was re-designed to assist with schema evolution and invalid XML content. JAXB has introduced a flexible unmarshalling mode that allows for unmarshalling of invalid XML content. Optional unmarshal time validation can be used by an application to detect invalid XML content and decide whether to terminate unmarshalling.

Let's take an example to illustrate the basic usage of both technologies:

Let say we have a schema:

<xs:complextype name="promotion">
<xs:sequence>
<xs:element name="discount" type="xs:string">
<xs:element name="None" type="xs:string">
</xs:sequence>
</xs:complextype>

With XmlBeans:

PromotionDocument pdoc =
PromotionDocument.Factory.parse(new File (xmlFile));

// Get and print pieces of the XML instance.
Promotion p = pdoc.getPromotion;
with JAXB:
JAXBContext jc = JAXBContext.newInstance("test.jaxb");
Unmarshaller unmarshaller = jc.createUnmarshaller();
Promotion p = (Promotion) unmarshaller(new File(xmlFile) );

The choice between these technology depends on the performance you want to get
and the use of XML features. I will go with XML Beans if:
I would like to access the XML document itself and use XQueries ...etc.
I would like Native DOM representation at the expense of performance and memory management.
Access schema metadata
Use it older JDK versions. 1.4 or older.

If you are looking for simplicity to convert an XML document <--> Java classes,
JAXB is your choice.
If you want binding customization, JAXB allows these declarations to be made "inline" -- that is, in the schema, or in a separate document.
JAXB uses memory efficiently: The tree of content objects produced through JAXB tends
can be more efficient in terms of memory use than DOM-based trees.
JAXB allows you to access XML data without having to unmarshal it. Once a schema is bound you can use the ObjectFactory methods to create the objects and then use set methods in the generated objects to create content.

References:
JAXB Architecture, http://java.sun.com/webservices/jaxb
JSR 31, JAXB specs, http://jcp.org/en/jsr/detail?id=031
XMLBeans, http://xmlbeans.apache.org/
XMLBeans Architecture, http://dev2dev.bea.com/xml/xmlbeans.html