Glen Mazza's Weblog

« Previous page | Main | Next page » Sunday April 16, 2017

Deploying and Using a CXF Security Token Service (STS)

Summary: In this tutorial we'll be creating a CXF Security Token Service (STS) and show how to access the STS using a CXF web service client (WSC). The client will authenticate with the STS to obtain SAML tokens that will subsequently be used to authenticate/authorize SOAP requests to a CXF web service provider (WSP) that trusts the STS.

[Read More] Sunday April 09, 2017

Using X.509 security with Apache CXF

This article shows how Apache CXF SOAP requests and responses can be encrypted using WS-Security's X.509 Token Profile (mutual certificates).

[Read More] Sunday April 02, 2017

Using UsernameToken security with Apache CXF

Summary: Learn how to use the WS-Security UsernameToken profile with Apache CXF-based web services.[Read More] Sunday March 26, 2017

Activating Transport Layer Security (SSL) for CXF web services

This tutorial shows how to deploy and call a Tomcat-hosted Apache CXF web service that uses SSL.[Read More] Sunday March 19, 2017

Using Apache CXF to access Salesforce Marketing Cloud SOAP API

I've created a SOAP client using Apache CXF 3.1.x and Maven to access Salesforce Marketing Cloud's SOAP Web Services API, in particular the more generic Partner API. Salesforce's CXF sample, while it contains useful examples that go beyond my tutorial, uses the decade-old CXF 2.0.2 with Apache Ant, so I decided to post a more modern sample. The SOAP client in this tutorial creates a DataFolder with two subfolders in Email Studio of your Marketing Cloud account, something simple to confirm ability to make SOAP calls as well as use for starting boilerplate for your own projects. The tutorial source code can be obtained from GitHub by using either the download ZIP button or git clone -v git:// command.

If you're new to SOAP, you may wish to review my intro web service tutorial.

The project has the following submodules, please take note of the changes needed for the code to work in your environment:

  • exacttarget-jaxws - This submodule primarily contains just the ExactTarget WSDL. The pom for this project uses CXF's wsdl-to-java generator to read the WSDL and from that generate the 300+ JAX-WS and JAXB Java classes used for accessing the Salesforce SOAP endpoint. This submodule in turn gets included as a dependency by the other two modules. The sample project does not contain the WSDL, as it is dependent on the instance (S1, S4, S6, S7, etc.) that you're using -- Salesforce support can help you if you're unsure which one. If wishing to run the sample, view the appropriate WSDL link in a browser, save it as text, and place it as "etframework.wsdl" in the src/main/resources folder of this submodule.

  • salesforce-access-lib - This is (the beginnings of) a library you can include in your application to make the Salesforce SOAP API calls, as stated earlier it just creates three data folders. You'll see that most SOAP actions in Salesforce involve repetitive configuration calls (for example, creating a DataFolder requires specifying several properties for it before saving) so that's it advantageous to factor out this configuration into service methods that you can efficiently call as needed.

  • testapp - This is a simple command-line application that calls a method in salesforce-access-lib to create the data folder. It uses Spring configuration to handle the UsernameToken (username and password) security requirements. To run the testapp:

    • You'll need to know the MID (Member ID) of the Business Unit of your Salesforce instance that you wish to have the SOAP client access, usually (?) a 7-digit number. That can normally be found in the upper-right portion of Email Studio, in the Business Unit dropdown, or contact Salesforce for this information. This value needs to go in the specified location in the testapp's pom.xml where it is read while running the application.
    • You'll need to populate the included file with your Salesforce login and password while running the testapp. If you include this project in your own source control, for security you will probably want to exclude this file from your repo (for example, can use a .gitignore file to block its saving if you're using a Git-based version control system.)

After you've made the above-specified modifications, from the root folder run the Maven mvn clean install from a command-line prompt to build all the submodules. You may then navigate to the testapp folder and run mvn exec:exec to run the testapp and create the sample data folders that you'll be able to see once you log into Email Studio (Contents -> My Emails section). They can be deleted by right-clicking on them within Email Studio.

For further help on accessing the SOAP API and working with its objects and methods the Salesforce StackExchange is a good place to post questions. Sunday March 12, 2017

Creating a WSDL-first web service with Apache CXF

This tutorial shows how to create a start-from-WSDL web service using Apache CXF along with a SOAP client to call that web service. Apache Maven is used as the build and run tool for this sample.[Read More] Saturday February 18, 2017

Using AppleScript to quickly configure your work environment

At work, I use Mac OS' Script Editor to create and compile AppleScript scripts to quickly configure my desktop depending on the programming task at hand. Each compiled script, or application, I place in the desktop folder so it appears on my desktop and can be activated with a simple double-click.

Three tasks I commonly have that I include and adjust as needed depending on the task:

  • Activating a terminal window with tabs pre-opened to various directories and running various commands. A script that opens up three terminal windows in the specified directories, and optionally runs any commands in those directories, would look as follows (see here for more info):
    tell application "Terminal"
    	do script
    	do script "cd /Users/gmazza/mydir1" in tab 1 of front window
    	my makeTab()
    	do script "cd /Users/gmazza/mydir2" in tab 2 of front window
    	my makeTab()
    	do script "cd /Users/gmazza/mydir3" in tab 3 of front window
    end tell
    on makeTab()
    	tell application "System Events" to keystroke "t" using {command down}
    	delay 0.2
    end makeTab
  • Running IntelliJ IDEA. Simple:
    activate application "IntelliJ IDEA"
  • Opening Chrome with a desired number of tabs to certain webpages:
    tell application "Google Chrome"
    	open location ""
    	open location ""
    	open location ""
    end tell

Script editor has a "run" button allowing me to test the scripts as I develop them. Once done, I save the script both standalone (so I can edit it later if desired), but also export it as an application. Exporting it allows for a simple double-click to directly run the task, rather than bringing up the Script Editor and requiring the script to be run via the "run" button. Monday January 02, 2017

TightBlog 2.0 update...

Happy New Year! I added a new tag management tab to the upcoming TightBlog 2.0 UI, it provides a pageable listing of all tags currently used by a blog, number of entries having that tag, as well as the following functionality:

  • View entries -- see the entries having a given tag
  • Delete tag -- remove a given tag from all blog entries having it
  • Add tag -- add a new tag (or an already existing one) to all blog entries having a given tag (sample use case: wanting to tag all blog entries currently tagged "Java" with the tag "Programming" for those entries not already having that tag)
  • Rename tag -- change the name of a tag to either a new tag or an already existing tag (sample use case: on the basis of a "Java7" tag no longer worth highlighting due to its age, switching the tag to the generic "Java" for blog entries having the former but not yet the latter and just deleting the "Java7" tag for those entries already having the latter.)

I also pulled out the "Planet" functionality in 2.0 (ability to read in, merge and display external RSS feeds) -- not to be mistaken for a home site page such as Oracle Blogs Aquarium or JRoller, that ability will still remain. I'm aware of only one of the fifty or so Roller users currently using planets, and that lone user very halfheartedly. While on the Roller team we simplified the planet functionality about 50%, and in developing TightBlog 1.0 I pulled out about another 50%, but it was still needing 3 database tables and about 3500 lines of code. I felt the effort spent maintaining it would be more productively spent elsewhere in the application. (By way of comparison, the much more utilizable Tag management page requires no extra tables and only about 600 extra lines of code.)

So far, TightBlog 2.0 has fallen to 163 Java class files from the 187 in TightBlog 1.0, making it just under 1/3 the class count of Roller 5.1.2's 493. The removal of the planet functionality dropped the database table count from 17 to 14, nineteen below Roller's 33. My main remaining prerequisite for releasing TightBlog 2.0 is completing the switch from Struts to Spring MVC, as so much of the application is now (Spring) REST API based that including a second web framework as a dependency is increasingly undesirable. Wednesday November 16, 2016

Benefits of Retaining the Electoral College

  1. It respects the Great Compromise between the states - The Great Compromise, meant to protect small states from getting overwhelmed by the larger ones, necessary to get them to agree to form the Union, extended not just to the legislative branch but the executive as well. By adding the equal number of senators to the number of congressmen to determine each state's electoral votes, small states were given additional weighting in the say they would have in choosing the President.

    For example, one state A with twice as much population as B might have 6 representatives to B's 3. However, the number of electoral votes is not 6 to 3 or twice as much say but 8 to 5 due to the addition of the senators, resulting in just 1.6 times as much say, honoring the compromise. Switching to a popular vote would eliminate that weighing benefit, as state A would have roughly twice as many voters as B and hence twice as much say.

    This benefit given to the small states has shrunk by about a third since the country was formed. In the First Congress there were 68 congressmen and 26 senators generating a total of 94 electoral votes, so that a state's population was only a 68/94 = 72.3% factor of its say. Since the number of congressmen was fixed at 435, population now provides 435 / 535 (leaving out D.C.'s 3 electoral votes which aren't based on representation) or 81.3% of the weighting.

  2. States are better protected from voter irregularities occurring in other states - With the Electoral College, any ballot-box stuffing done by one state does not limit the say of others. Take one state with say 10 electoral votes, for example, they could have three, five, ten million falsified ballots for a candidate, they can go to town, it wouldn't matter, only that state's 10 electoral votes would be corrupted. Pennsylvania (20 votes), Iowa (6), Arizona (11), etc., would still have their say and their respective weighting. If we switched to a popular vote, those invalid votes would count to the national total, harming the say of states that run their elections more cleanly. In general:

    • With a national vote election, states which do a better job ensuring valid voting (photo ID, checking to make sure voter registrants are US citizens, alive, etc.) would lose say over states that tend to look the other way in such matters.

    • Conversely, because we use an Electoral College, there is much less incentive for ballot-box stuffing as it doesn't buy one party-dominant states tempted to engage in such activities anything. It results in cleaner elections, and hence a cleaner society, nationwide.

    • A national vote would encourage a race to the bottom in granting suffrage ("State A is now allowing their green card holders to vote, so we should also lest we lose our say...", "State B is now allowing 16 year olds to vote...", etc.)

  3. Close elections are much easier to resolve - The 2000 election between Bush and Gore took about one month to resolve but the focus thankfully was just with Florida and its then-25 electoral votes. Because the Electoral College was all that mattered, the other 49 states could be ignored, 20 inaccurate votes in Idaho for example or 30 missed votes in California could be disregarded. However, if we had a tightly close popular vote election, then every precinct in every county in every state would be subject to re-examination, to grab 5 votes here and 10 votes there because they all count towards the national vote total, not a situation anyone would relish.

  4. With the Electoral College, people are more likely to vote for a candidate based on his/her policies rather than on whether or not he/she has visited their state. - Voters in places like California and Tennessee where the outcome of the vote is not in doubt are perfectly fine with their candidate of choice never visiting their home state during the campaign. More than that, they don't actually want their candidate wasting time in their home states, instead wanting him or her to be in battleground states trying to win them over so their candidate can win. This provides a lot of relief to presidential candidates as it allows them to focus on visiting just 10-15 battleground states, a grueling enough task as it is.

    With a national popular vote, however, it would still make sense to visit vote-rich states regardless of their leanings, causing many voters to get offended if their candidate does not visit them, and possibly switch votes as a result. So the Electoral College is more likely to result in voters casting votes based on the candidate's policies than whether they visited their state, good for the nation as a whole.

  5. The Electoral College makes election night a lot more exciting to watch - A silly argument, but still true. With the Electoral College, viewers see a scoreboard of states that slowly get lit up in red and blue during the evening, for which viewers can celebrate or mourn each time a candidate wins or loses a state. With a national vote you're just waiting for a vote total at the very end, rather dull for all concerned. It would be similar to watching a football game in which all touchdowns and field goals are irrelevant but just the total yards gained within the 60 minutes of play determining the victor.

Finally, it should always be noted that a candidate who wins the popular vote and loses the electoral votes on an election based on the latter wouldn't necessarily have won the popular vote if it were based on the former, as the campaigning done--states visited, TV advertising strategy, issues chosen, voter turnout generated, etc.--is different under the two styles. A skilled candidate who can win with one set of rules quite frequently has the ability to win under another. Wednesday August 31, 2016

TightBlog: August 2016 update

I'm back to work, my summer sabbatical is now complete, so I won't have nearly as much time to spend on TightBlog. The release of TightBlog 1.0 was a mission accomplished for me (similar to my prior time off, which I spent releasing Roller 5.1.) I did get a few simplifications in this month though, removing four more Java source files and 2 JSPs.

I advertised the release of TightBlog 1.0 on the Apache Roller users mailing list and got some more traffic from Roller users who did not yet know of my fork.

I said last month that "talk is cheap" and refrained from mentioning what I'd like to get done. But cheap talk is sometimes still useful: For TightBlog 2.0, I'd like to finish up the REST API for the application, a few more screens still rely on server-side screen generation. Once done, so little Struts code will be remaining that I plan on pulling out the Struts library and replacing it with Struts MVC, whose libraries are already being used for the REST controllers. I hope to get a tag management page in for deleting, renaming, and adding tags. Thymeleaf in addition to or replacing Velocity for the blog templates may also be a good idea. I might remove the Planet functionality as it was seldom used in Roller and the effort spent maintaining it can perhaps better be spent enhancing the rest. Finally, a package renaming and restructuring, replacing the legacy org.apache.roller.* naming with a new org.tightblog.* or similar.

(I still need to convert *this* blog to TightBlog--awaiting the new OpenShift PAAS update before doing so, but maybe I'll switch to Digital Ocean instead...)

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.